今天我们要聊的max_bars_back参数，可以说是一个“屠龙之技”——99%的情况下你都用不到它。因为TradingView的自动历史数据检测机制已经非常智能和准确，完全能满足绝大多数脚本的计算需求。但是了解它，能帮助你在那关键的1%的复杂情况下，解决一些棘手的报错问题。
首先max_bars_back的作用是，告诉TradingView你的脚本在进行计算时，需要回溯多少根历史K线的数据。比如一个20移动平均线，至少需要20根历史K线才能计算出第一个值。
在绝大多数需要手动调整历史数据的情况下，使用max_bars_back()函数是比max_bars_back参数更好的选择。因为函数可以只针对某一个需要大量历史数据的特定变量进行“扩容”，而参数则会增加整个脚本所有历史变量的内存消耗，影响更大，也更“浪费”。
max_bars_back参数尽管不常用，但了解其语法还是必要的。
- 指标： 告诉TradingView你的指标需要75根历史K线数据。
indicator(title="我的指标", max_bars_back=75) - 策略： 告诉TradingView你的策略至少需要150根K线数据才开始计算。
strategy(title="我的策略", max_bars_back=150) - 它只是个建议，不是命令。一个非常重要的概念，你设置
max_bars_back=150，并不是在命令TradingView“必须用150根K线”，而更像是在建议它：“如果你的自动检测搞不定了，就参考我这个150的数值吧”，决定权仍然在TradingView手上。 - 尽管TradingView的自动估算很准，但如果你的代码逻辑极其复杂（比如在各种复杂的条件判断中引用了不同周期的历史数据），自动检测就可能蒙圈并报错。这时才是
max_bars_back参数出场的时机。 - 把这个值设得很高，就像是要求服务器为你脚本里的每个历史变量都准备一个超长的记忆抽屉，里面装满了历史数据，抽屉越多越长，占用的内存自然就越大。
- 对于策略开发者来说，设置过高的
max_bars_back会吃掉你图表最左侧的一大段历史数据，导致这些K线不参与计算。这意味着你的策略回测区间会大大缩短，如果你想回测更长的历史周期，反而要非常小心这个参数。 max_bars_back的唯一用途就是解决历史数据引用不足的报错，不要试图用它来限制指标的输出数量、减少策略的订单数量或者限制回测窗口，这些都有其他更合适的方法去实现。- 和其他绘图数量参数一样，
max_bars_back没有图形界面的手动设置选项，只能在代码中配置。
总结
max_bars_back是一个可选的、用于解决复杂脚本中历史数据引用不足问题的专家级参数，在绝大多数情况下，你都应该依赖TradingView强大的自动检测机制，而无需手动设置它。当你确实因为代码过于复杂而遇到历史数据相关的错误时，才需要考虑使用它。但即便如此，也请优先考虑使用更精确、资源消耗更小的max_bars_back()函数来解决问题。尤其对于策略开发者，要警惕max_bars_back参数对回测周期的负面影响。
