Twig模板缓存由APP_DEBUG控制，非配置开关；APP_DEBUG=true时强制文件缓存，false时内存缓存；dev环境应保持APP_DEBUG=true并启用auto_reload实现热更新，prod环境不可关闭模板缓存。
dev环境模板缓存关不掉？先确认debug模式是否真关闭
模板缓存不是靠“关配置”就能停的，它直接受APP_DEBUG控制。即使你在config/packages/twig.yaml里删光所有缓存相关项，只要APP_DEBUG=true，Twig仍会把模板编译成PHP文件并缓存到var/cache/dev/twig/——这是设计行为，不是bug。
验证方式很简单：在终端执行php bin/console debug:container --env=dev | grep debug，如果输出里有debug: true，说明环境没切对。检查.env和.env.local，确保APP_ENV=dev且APP_DEBUG=false同时成立（注意：两者必须一致，APP_ENV=dev但APP_DEBUG=false时，Twig会禁用模板缓存）。
- 不要只改
twig.yaml里的cache路径，那只是指定缓存写入位置，不改变是否启用逻辑 -
APP_DEBUG=false时，Twig默认用ArrayAdapter做内存缓存，不落地文件，所以var/cache/dev/twig/下看不到新文件是正常的 - 若确需强制不缓存（比如调试模板语法错误），临时设
APP_DEBUG=true反而更利于报错定位，而不是关缓存
prod环境想关模板缓存？别试了，它根本不该关
生产环境下，Twig模板缓存是性能基石，关掉等于自废武功。Symfony 3 的cache:clear命令会自动重建var/cache/prod/twig/下的编译文件，但这个过程不可跳过——没有缓存，每次请求都要重新解析、编译、加载模板，CPU飙升且首字节延迟翻倍。
如果你发现prod下模板更新不生效，问题几乎肯定不在缓存本身，而是：cache:clear没执行、var/cache/prod/权限不对导致缓存写失败、或部署时漏传了新模板文件。
- 执行
php bin/console cache:clear --env=prod后，立刻检查var/cache/prod/twig/目录是否有新生成的PHP文件（文件名含哈希，非空即生效） - 若清缓存后仍加载旧模板，用
ls -l var/cache/prod/twig/确认文件修改时间是否更新；若没变，说明清缓存命令没真正跑完（常见于部署脚本里漏了--env=prod参数） - 不要手动删
var/cache/prod/twig/子目录，Twig依赖完整目录结构，删一半会导致Class not found错误
怎么让模板变更实时生效（开发阶段）
真正需要的是“改了模板马上看到效果”，不是“关缓存”。Symfony 3 提供了两个轻量级方案，比硬关缓存更可控：
- 保持
APP_DEBUG=true，Twig会自动检测模板文件mtime变化，每次请求前校验，命中则重编译——这已是开箱即用行为，无需额外配置 - 如遇校验失效（比如NFS挂载、Docker volume时间不同步），在
config/packages/dev/twig.yaml中显式开启文件监控：auto_reload: true（该选项默认开启，但某些容器环境需显式声明） - 避免使用
cache:clear来刷新模板——它清的是整个缓存池，包括路由、服务容器等，代价远高于单次模板重编译
示例配置片段（仅dev环境）：
twig:
auto_reload: true
strict_variables: true
缓存键冲突导致模板加载错乱？检查Twig命名空间和路径
Twig缓存键由模板路径+命名空间共同生成。如果你用addPath()或setPaths()动态注册了多个根路径，又用了相同文件名（如base.html.twig），缓存可能命中错误路径下的同名文件——现象是页面突然渲染出老版本或空白，var/cache/dev/twig/里却找不到对应文件。
- 运行
php bin/console twig:debug查看当前所有已注册的命名空间和路径，确认无重复或覆盖 - 避免在不同Bundle里放同名模板，尤其
base.html.twig、layout.html.twig这类全局模板 - 自定义命名空间时，路径末尾加
/（如@App/），否则Twig可能误判相对路径解析顺序
这类问题不会报错，但缓存内容与预期不符，排查时容易忽略路径注册逻辑本身。
