必须在twig.yaml中显式写cache: false，且需配合auto_reload: true；否则即使APP_DEBUG=true、APP_ENV=dev，Twig仍会缓存编译文件导致模板修改不生效。
twig.yaml里必须写cache: false，不是留空也不是注释
很多人以为设了APP_DEBUG=true和APP_ENV=dev就自动关了 Twig 缓存，其实不是。Symfony 3 默认仍会把.twig文件编译成 PHP 存进var/cache/dev/twig/，改完模板不生效，八成是这里卡住了。
真正起效的只有一条：在config/packages/twig.yaml中显式写死cache: false。这个false是 YAML 布尔字面量，不能加引号，也不能写成null或~。
-
cache:（冒号后空格）→ 不生效，Twig 用默认路径 -
cache: "%kernel.cache_dir%/twig"→ 实际启用缓存，且路径可能因环境不同而错乱 -
cache: "false"（字符串）→ Twig 当成一个目录名去尝试创建，报file_put_contents(): Permission denied
别忘了auto_reload: true，否则cache: false也白搭
cache: false只是让 Twig 不写编译文件，但它不会主动监听文件变化。如果auto_reload关了，即使模板改了，Twig 也不会重新读取源文件——它会继续用上次解析结果（存在内存里），看起来就像“没反应”。
检查config/packages/twig.yaml是否包含：
twig:
auto_reload: true
这个选项默认在 dev 环境开启，但如果你覆盖了 twig 配置（比如从 config_dev.yml 导入），它可能被意外覆盖或删掉。
- 运行
php bin/console debug:container --parameter=twig.options，确认输出里auto_reload是true - 改一个
base.html.twig并保存，用curl -I /_profiler看响应头是否有Last-Modified；没有说明auto_reload没生效 - Docker 或 WSL 环境下，
auto_reload可能因文件系统 inotify 限制失效，需加options: ["delegated"]或改用 polling
验证缓存真停写了：盯住var/cache/dev/twig/目录
光看配置不报错没用。最直接的验证方式是观察文件系统行为：
- 清空
var/cache/dev/twig/（rm -rf var/cache/dev/twig/*） - 访问任意含 Twig 的页面（比如
/） - 立刻检查该目录是否新建了 PHP 文件（如
abc123.php）——有就是缓存还在工作，没生成才是真的关掉了 - Windows 下注意杀毒软件可能锁定该目录，导致
file_put_contents()失败，错误信息里常带Permission denied
如果目录始终为空，且页面能随.twig保存实时更新，说明已到位。这时候再遇到模板不刷新，问题大概率出在浏览器缓存、反向代理或前端构建层，而不是 Twig 自身。
多人协作时，CI 必须断言twig.options.cache === false
本地关掉了不等于队友或 CI 也关了。尤其当有人提交了config_dev.yml里漏掉cache: false，或者 Docker Compose 覆盖了APP_ENV，缓存就会悄悄恢复。
在 CI 脚本里加一条硬性检查：
php bin/console debug:container --parameter=twig.options 2>/dev/null | grep -q '"cache":false'
这条命令失败就中断构建。比每次问“你清缓存了吗”靠谱得多。
- 不要只检查
APP_ENV=dev，因为twig.options.cache优先级更高，能绕过环境判断 - 避免用
cache: ~或cache: null，它们在 Symfony 3 中等价于启用默认缓存路径 - 如果项目用了自定义 Twig 扩展或 Bundle，确认它们没在运行时重写
twig.options（比如通过TwigExtension::configureOptions()）
真正麻烦的不是配不配得对，而是有人改了模板却不知道队友的机器正从var/cache/dev/twig/xxx.php里读旧代码——把cache: false写死、CI 断言、目录监控三者缺一不可。
