Ansible模板渲染无运行时缓存，优化重点是减少数据准备开销和提升Jinja2执行效率：精简facts加载、预处理变量、限制gather_subset、避免循环内计算、慎用高阶过滤器、启用ControlPersist与pipelining、优先copy静态内容、封装自定义过滤器。
Ansible 模板渲染本身不涉及运行时缓存机制——Jinja2 模板在每次任务执行时都会重新解析、编译并渲染，但性能瓶颈往往来自外部因素，比如频繁读取变量、重复计算、低效过滤器或未优化的 inventory/facts 加载。真正可优化的不是“模板缓存”，而是**减少模板渲染前的数据准备开销**和**提升 Jinja2 执行效率**。
精简 facts 和变量加载，避免模板中隐式触发收集
模板里若引用 ansible_facts（如 {{ ansible_memtotal_mb }}）或未定义变量，而当前 play 又未显式 gather_facts: yes，Ansible 会自动触发一次 setup 收集——这不仅慢，还绕过 fact caching。实际中常被忽略：
- 确认 play 中已设
gather_facts: yes，且启用了 fact caching（如 jsonfile 或 redis），确保 facts 从缓存毫秒级读取 - 模板中尽量避免直接访问深层嵌套 facts（如
{{ ansible_all_ipv4_addresses[0] | default('') }}），改用预处理变量：在vars:或set_fact:中提前提取并赋值 - 禁用不需要的 facts：通过
gather_subset:限制收集范围，例如只收!all,!min+network,hardware，大幅缩短 setup 时间
优化 Jinja2 模板写法，降低运行时开销
Jinja2 渲染速度受模板结构影响明显。以下实践能显著提速：
- 避免在循环内做重复计算：把
{% set base_url = 'https://' + domain %}提到循环外，而非每次迭代都拼接 - 慎用
selectattr/map等高阶过滤器处理大列表；超 100 项时，先用set_fact过滤好再传入模板 - 用
{%- ... -%}去除空白行，减小输出体积，尤其对生成配置文件类模板有 IO 和传输收益 - 不依赖模板做逻辑判断：复杂条件分支应移到
when:或set_fact:，模板只负责纯渲染
启用 ControlPersist + Pipelining 减少 SSH 层延迟
模板渲染虽在控制节点完成，但若模板内容依赖 lookup 插件（如 file、env、redis），或 task 中使用 template 模块向远端写入，SSH 往返就成为瓶颈：
- 在
ansible.cfg启用连接复用：ssh_args = -C -o ControlMaster=auto -o ControlPersist=600 - 开启 pipelining（需关闭
requiretty或不用 sudo）：pipelining = True，使模块传输走单次 SSH 通道，避免多次建立连接 - 对静态内容（如证书、配置片段），优先用
copy模块+本地文件，而非template模块动态渲染——省去 Jinja2 解析环节
合理使用自定义过滤器替代模板内 Python 表达式
模板中写 {{ item.name | upper | replace(' ', '_') | truncate(32) }} 比手写 {% for c in item.name %}... 更快，因为内置/自定义过滤器是预编译的 C 扩展或高效函数：
- 把常用字符串/日期/数学逻辑封装成轻量 Python 过滤器（放在
filter_plugins/），比模板内嵌复杂{% set %}块更稳定、更易复用 - 避免在模板中调用
from_json或to_nice_yaml处理大结构体；应在set_fact阶段完成转换 - 测试过滤器性能：用
time ansible localhost -m debug -a "msg={{ huge_list | my_filter }}"快速验证
