生产环境必须启用 Twig 模板缓存，因其将 .twig 文件编译为原生 PHP 类并缓存至 var/cache/prod/twig/，关闭会导致每次请求重复解析，性能下降 5–10 倍；需确保 APP_ENV=prod、APP_DEBUG=false、缓存目录可写且已预热。
关闭模板缓存会让 Symfony 3 在每次请求时重新解析 Twig 文件，这在生产环境会直接拖慢响应速度、增加 CPU 消耗，**不能关闭**。
为什么生产环境必须启用 Twig 模板缓存
Twig 编译缓存不是可选优化项，而是生产环境的硬性依赖。它把 .twig 模板文件编译成原生 PHP 类并缓存到 var/cache/prod/twig/ 目录下。一旦关闭，每次请求都要经历：读取模板 → 词法分析 → 语法树构建 → 生成 PHP 代码 → include 执行，这个过程比直接执行缓存后的 PHP 类慢 5–10 倍。
常见误操作包括：
- 在
config/packages/twig.yaml中设cache: false或cache: null - 忘记设置
debug: false，导致 Twig 自动降级为无缓存模式 - 部署后没运行
cache:warmup，首次请求才触发编译，造成“雪崩式”延迟
如何确认模板缓存是否真正生效
别只看配置，要验证实际行为：
- 检查
var/cache/prod/twig/目录是否存在且非空（有大量以哈希命名的.php文件） - 修改一个模板后不清理缓存，刷新页面——如果内容没变，说明缓存命中；如果立即更新，说明缓存被绕过或未启用
- 用
php bin/console debug:container --env=prod | grep twig查看twig服务是否绑定到Twig\Environment实例，且其getCache()返回非NullCache
debug=false 是模板缓存的开关前提
Symfony 3 的 Twig 缓存逻辑和 debug 标志强耦合：
-
debug: true→ 强制使用ArrayCache（内存缓存），且每次请求校验模板修改时间，实际等效于“伪缓存” -
debug: false→ 启用文件系统缓存，默认路径为var/cache/prod/twig/，且跳过模板时间戳检查 - 即使你手动设了
cache: '%kernel.cache_dir%/twig'，只要debug=true，它依然不会落地为文件
所以，.env 文件里必须同时满足：APP_ENV=prod 和 APP_DEBUG=false，缺一不可。
缓存目录权限问题常被忽略
模板缓存写入失败不会报错，只会静默退化为无缓存模式：
- 确认
var/cache/和var/cache/prod/可写（Web 用户如www-data或nginx需有写权限） - 不要用
chmod -R 777 var/cache上线，应设为chown -R www-data:www-data var/cache+chmod -R 755 var/cache - 若用 Docker，确保 volume 挂载时 uid/gid 匹配容器内 Web 进程用户
最隐蔽的问题是：缓存目录存在、配置正确、debug 关闭，但因权限不足导致 Twig 编译文件无法写入，结果就是“看起来开了缓存，实际每次都在重编译”。
