Jinja2 中 {% set %} 变量声明的执行时机与条件控制逻辑详解

Jinja2 模板中的 {% set %} 语句并非全局预执行，而是严格遵循 Python 式的运行时控制流：仅当所在代码块被实际执行（如 if 条件为真、for 迭代发生）时，set 才会求值；条件不满足时，其内部的函数调用（含副作用）完全不会触发。

在 Jinja2 模板里，`{% set %}` 并不会像“全局预先执行”那样先跑一遍，它走的其实是非常标准的 Python 式运行时控制流：只有当它所在的代码块真的被执行时——比如 `if` 条件成立，或者 `for` 循环确实进入了某次迭代——这个 `set` 才会开始求值；反过来说，只要条件没满足，那么其中的函数调用，包括那些带副作用的调用，也都不会被触发。

在 Jinja2 模板引擎中，{% set %} 并非声明式“变量定义”，而是一个运行时赋值操作——它会被编译为等效的 Python 字节码片段，并嵌入模板渲染生成的抽象语法树（AST）中。这意味着它的执行完全服从于标准程序控制流规则，与你在 .py 文件中写的 x = func() 行为一致：是否执行，取决于它所处的上下文是否被进入。

例如，以下模板是安全的：

{% if user.is_admin %}
{% set log_entry = log_access_attempt(user.id) %}
Admin access granted.
{% else %}
Access denied.
{% endif %}

只要 user.is_admin 的结果是 False，log_access_attempt() 就根本不会被触发，不管这个函数内部带着数据库写入、日志记录，还是网络请求这类副作用，都一样不会发生。Jinja2 的执行逻辑并不会先把 set 语句“预扫描”一遍，也不存在什么“提前绑定”或因为模板里写了这段结构就强行求值；只有当 AST 对应的那个分支真的走到了，这段代码才会实际执行。

⚠️ 注意事项：

• 无副作用假设不成立：切勿在 set 中调用有状态变更的函数（如 db.session.commit()、send_email()），除非你明确需要其副作用且已确保执行路径受控；
• 作用域限制仍存在：即使 set 被执行，其变量也仅在当前作用域（如 if 块、for 循环体）内有效，外层无法访问（参见 loop.index0 替代循环计数的经典实践）；
• 调试建议：可通过启用 Jinja2 的 undefined=StrictUndefined 模式捕获未定义变量错误，辅助验证 set 是否按预期生效。

✅ 最佳实践总结：
将 {% set %} 视为轻量级、局部、惰性求值的赋值语句，而非配置指令。它应仅用于简化模板表达式（如缓存复杂过滤链结果），而非承载业务逻辑或状态管理。真正的流程控制与副作用操作，请始终移至视图函数（Flask）或任务模块（Ansible）中完成——模板的职责，永远是安全、确定、无副作用地呈现数据。