关闭Twig缓存会导致每次请求重复解析编译模板，性能呈指数级下降；必须在生产环境启用缓存并设debug=false，开发时依赖auto_reload而非禁用缓存。
关闭模板缓存（debug=true 或 twig.debug=true）会导致 Twig 每次请求都重新解析、编译模板，性能损耗不是“慢一点”，而是指数级上升——尤其在嵌套 include、大量 filter 和 macro 的场景下，单次渲染可能多耗 5–10 倍 CPU 时间。这不是配置微调能补回来的，必须回归生产模式本质。
为什么不能在生产环境关掉 Twig 缓存
Twig 缓存不是可选功能，它是 Symfony 生产环境的硬性依赖。关闭后：
• 模板文件每次被读取、词法分析、语法树生成、PHP 代码生成、写入临时文件、include 执行；
• 所有 {% include %}、{% extends %}、{% block %} 都重复解析；
• cache:clear 后首次请求会卡顿数秒，且无法预热（cache:warmup 本身依赖模板缓存）；
• Profiler 中 TwigExtension::loadTemplate 占用 CPU 超过 40%，远高于数据库查询。
真正需要调试时怎么安全绕过缓存
开发阶段要改模板立刻生效，不等于关缓存——而是用开发模式下的缓存刷新机制：
• 确保 APP_ENV=dev 且 APP_DEBUG=true，Twig 默认启用 auto_reload=true 和 cache=var/cache/dev/twig；
• 修改模板后，Twig 会比对文件 mtime 自动失效旧缓存，无需手动清；
• 如果发现修改不生效，检查是否被 opcache 缓存了编译后的 PHP 模板文件（opcache_reset() 或重启 PHP-FPM）；
• 不要用 cache:clear --env=dev 频繁清 Twig 缓存目录，这反而触发全量重编译，更慢。
模板结构本身导致缓存失效频繁怎么办
即使开了缓存，如果模板设计不合理，也会高频失效、反复编译：
• 避免在 {% include %} 路径中使用变量或表达式，如 {% include 'partials/' ~ section ~ '.html.twig' %} —— 这让 Twig 无法静态分析依赖，每次都会跳过缓存；
• 不要在模板里调用 {{ render(controller('...')) }} 并期望主模板缓存生效：子请求是独立生命周期，需单独配置 ESI 或 fragment 缓存；
• 减少深度继承链（{% extends %} 嵌套超过 3 层），每层都会增加缓存 key 计算开销和文件 I/O；
• 把动态内容（如用户权限判断）抽到控制器或自定义 Twig 函数，别塞进模板逻辑里——逻辑越复杂，缓存命中率越低。
模板缓存不是开关，是 Twig 编译模型的必然结果。所谓“关缓存调试”，本质是误用了开发流程。真要验证模板变更效果，靠的是文件时间戳检测 + auto_reload，而不是禁用缓存本身。一旦上了生产，debug=false 和 twig.cache 路径写死到 var/cache/prod/twig 就是铁律，绕不开，也不该绕。
