Pine Script v6中request.security条件调用的性能优化疑问

核心结论 #

你没法通过将request.security放入条件代码块来实现仅在条件满足时才执行请求，这是由Pine Script的底层执行机制决定的。

原因说明 #

客服的回复是准确的：request.security这类跨时间框架/跨标的的请求，会在主脚本的核心逻辑执行之前就完成计算，不管你把它嵌套在什么条件判断里。
dynamic_requests=true的作用并非控制请求是否执行，它只是允许脚本在不同K线或实时tick上动态切换请求的标的、时间框架（比如根据条件切换请求15分钟线还是1小时线），但完全不会阻止请求的预执行流程。

性能优化替代方案 #

既然没法实现真正的条件式请求，你可以从以下角度优化计算密集型场景的性能：

• 缓存固定请求的结果：如果请求的标的和时间框架是固定的，提前全局请求一次并缓存结果，后续直接复用即可，避免逻辑上的重复请求（尽管底层还是预执行，但能简化代码并减少重复计算的冗余）。示例代码：

indicator("My script", dynamic_requests = true)
// 提前完成请求并缓存结果
high_tf_close = request.security(syminfo.tickerid, "15", close)
out = 0.
if close % 2 == 0
    out := high_tf_close
plot(out)

• 控制结果的使用频率：如果你的计算不需要实时tick级的更新，可以通过barstate.islast或者时间间隔条件（比如每N根K线才更新一次结果）来复用缓存值，减少不必要的重复计算触发。
• 简化请求内的计算逻辑：如果request.security的第三个参数包含复杂计算，尽量把这部分逻辑移到主脚本中处理（在可行的前提下），或者简化计算步骤，以此降低跨时间框架请求的计算负载。

额外说明 #

Pine Script的执行模型优先保证指标回溯的一致性和准确性，因此跨时间框架的请求必须提前完成计算，才能确保主脚本逻辑在所有历史K线上的结果可复现。这就导致了无法通过条件判断跳过请求执行，只能从其他维度优化性能。

内容的提问来源于stack exchange，提问作者mrsnuffy