必须显式配置cache: false并验证auto_reload: true，删var/cache/dev/twig后改模板不生成新文件才说明关闭成功，且需在config/packages/twig.yaml中用yaml布尔字面量写入。
改了 Twig 模板却看不到变化，不是浏览器缓存，是 Symfony 3 的 Twig 缓存没真正关掉。 默认 dev 环境下 debug: true 并不等于模板不缓存，必须显式设 cache: false 并验证 auto_reload: true 生效，否则你保存的修改会被 var/cache/dev/twig/ 里的旧 PHP 文件覆盖。
怎么确认 Twig 缓存真关了
关缓存不是看配置文件里有没有注释掉某行，而是看 var/cache/dev/twig/ 目录是否停写：
- 手动删掉整个
var/cache/dev/twig/目录 - 改一个
base.html.twig里的文字（比如加个[DEBUG]） - 刷新页面，再检查
var/cache/dev/twig/是否生成了新 PHP 文件 - 如果没生成，说明
cache: false生效；如果生成了，说明配置没起作用或被其他配置覆盖
config/packages/twig.yaml 中 cache: false 怎么写才有效
cache: false 必须是 YAML 布尔字面量，不是字符串也不是空值：
twig: cache: false auto_reload: true debug: true
常见无效写法包括：
-
cache: ~→ Symfony 会合并为默认路径%kernel.cache_dir%/twig -
cache: ""或cache: null→ 同样 fallback 到默认路径 -
cache: "false"→ 字符串值，Twig 会尝试把它当目录路径去写，往往报file_put_contents(): Permission denied - 只改
app/config/config_dev.yml却忽略config/packages/twig.yaml→ Symfony 3.4+ 推荐用包配置，后者优先级更高
为什么 auto_reload: true 也得手动确认
auto_reload: true 控制的是“是否监听文件变更”，但它依赖底层 filemtime() 返回值。一旦失效，即使缓存关了，Twig 也不会重新解析模板：
- Docker 环境中宿主机和容器时区不一致 →
filemtime()返回时间戳错乱，Twig 认为文件“没变” - IDE（如 PHPStorm）开启 “safe write” → 先写临时文件再原子替换，Twig 监听的是原文件句柄，收不到变更事件
- Windows 下杀毒软件锁定
.twig文件 → 修改后filemtime()不更新 - 验证方式：访问
/_profiler页面，用curl -s -I http://localhost:8000/_profiler | grep Last-Modified，有该 header 才说明 auto_reload 正在工作
多人协作时最容易漏掉的一环
单人开发时本地配好就完事，但团队里有人用 Docker Compose 启动时没传 --env=dev，或 CI 流水线里跑的是 APP_ENV=prod，cache: false 就完全不加载——因为配置只在 config/packages/dev/twig.yaml 或 config_dev.yml 里。
真正可靠的方案是：把 cache: false 写进主配置 config/packages/twig.yaml，并在 CI 脚本中加入断言：
php bin/console debug:container --parameter=twig.options | grep '"cache":false'
否则，你改完模板提交，队友拉下来一刷新还是旧内容，问题会卡在“谁的环境不一样”上，而不是“哪行配置错了”。
