前面几篇文章我们一直在讲，如何通过max_labels_count、max_lines_count和max_boxes_count来突破绘图的数量限制，把上限从默认的50提高到500。这时你可能会好奇：为什么TradingView要多此一举设置这么个限制？直接开放无限数量的绘图权限不是更好吗？今天我们就来聊聊这背后的核心原因——服务器的内存管理。
每一个脚本都在云端运行
首先要明白一个大前提,你在TradingView上运行的每一个Pine脚本，都不是在你的本地电脑上计算的，而是在TradingView的云端服务器上运行的 。这意味着，你的脚本每一次执行计算，都在消耗TradingView需要付费的服务器资源，其中最重要的资源之一就是计算机内存 。
为了防止某一个过于复杂的脚本像无底洞一样吃掉海量内存，从而影响到其他所有用户的正常使用，TradingView必须实施一套内存限制机制 。这就像一个公平的资源分配系统，确保没有哪个租户能独占整个大楼的电力。而在众多消耗内存的功能中，通过代码绘制图形（标签、趋势线和方框），被认为是非常占用内存的操作 。
为什么默认限制是50
既然上限是500，为什么TradingView要把默认值设在一个仅有10%水平的50呢 ，这背后的逻辑，和限制绘图总数的原因如出一辙。为了优化服务器的整体资源 ，绝大多数脚本其实并不需要绘制海量的图形，通过设置一个相对较低的默认值（50个），可以确保大部分脚本的内存占用都保持在一个很低的水平，这有助于控制TradingView服务器集群的整体负载和成本 。而对于确实有需要的高级玩家，TradingView又开放了最高500的权限，给予了足够的灵活性。
聊了这么多底层逻辑，回到我们最关心的问题：平时写脚本时，应该怎么处理这个限制？会不会把上限设到500就把服务器搞崩了？
答案是：对于我们绝大多数人来说，大胆地把上限设置为500通常是最佳实践，也是安全的做法 。
虽然绘制图形很耗内存，但单个脚本的内存占用通常并不大 ，绝大多数脚本，即便把标签、趋势线和方框的数量都开到500的上限，也远未达到触发内存警报的程度 。只有当你的脚本极其复杂，使用了海量数据和计算，并且同时绘制了大量图形时，才有可能会收到内存超限的错误提示 。如果你没有收到任何错误，那就完全没必要把绘图数量限制在500以下 ，如果真的不幸遇到了内存超限的错误，你可以考虑以下几种方式来为你的脚本“减负”：
- 降低绘图数量： 最直接的方法，就是适当调低
max_labels_count等参数的值 。 - 让脚本自净： 在代码中加入逻辑，让脚本在运行时主动删除一些不再需要的、过时的旧图形 。
- 优化代码： 检查脚本中是否有其他与绘图无关，但同样消耗大量内存的计算或数据存储方式 。
总结
TradingView上的脚本运行在云端，会消耗服务器内存，其中绘制标签、趋势线和方框等图形，是尤其消耗内存的操作 。为了有效管理内存资源，TradingView为这些绘图行为设定了数量上限 ，不过对于绝大多数脚本来说，内存占用都在一个安全的范围内 。因此在开发需要绘制较多图形的脚本时，直接将max_labels_count、max_lines_count和max_boxes_count设置为500是常规且推荐的做法，只有在收到内存超限的错误时，才有必要考虑去降低这个上限。
