必须显式设置twig.cache: false才能真正关闭twig模板缓存，仅debug=true无效；需验证var/cache/dev/twig/停写且响应含last-modified头。
改了 Twig 模板却没反应？不是缓存没关，而是关得不彻底或验证方式错了。Symfony 3 的 debug=true 完全不影响 Twig 缓存行为，必须显式禁用并确认 auto_reload 生效。
如何真正关闭 Twig 模板缓存
Twig 缓存由 twig.cache 配置项控制，它不是布尔开关，而是一个路径值。设为 false（YAML 字面量）才是唯一可靠方式；null、~、空字符串甚至 "false"（字符串）都会被 Symfony 合并回默认路径，实际仍启用缓存。
- 在
config/packages/twig.yaml或config/packages/dev/twig.yaml中写死：twig: cache: false
- 确保
auto_reload: true已启用（默认开启，但若被覆盖则失效） - 避免使用动态路径如
"%kernel.cache_dir%/twig"——该目录在cache:warmup后会被创建，等于变相启用缓存 - 若项目有多个 Twig 实例（如 email_twig），每个都要单独配
cache: false
为什么 APP_ENV=dev 和 debug=true 不够用
Symfony 的环境机制不传导到 Twig 引擎层。常见破环点包括：
- IDE 插件或 Docker Compose 覆盖了
APP_ENV，导致实际运行在prod模式 -
php bin/console server:run未加--env=dev，fallback 到prod（此时cache: true是硬编码） - 有人执行
cache:clear时漏掉--env=dev，清掉了 dev 缓存目录，Twig 回退到内存ArrayCache，表现像“部分生效” - Windows 下杀毒软件或权限锁死
var/cache/dev/twig/，导致缓存无法更新甚至报file_put_contents(): Permission denied
怎么验证模板缓存真关掉了
别只看页面是否刷新，要验证缓存文件是否停写、响应头是否含变更监听信号：
- 手动删掉
var/cache/dev/twig/目录，改一个模板并保存，刷新页面后检查该目录是否**完全无新文件生成** - 用
curl -I http://localhost/_profiler查响应头，必须含Last-Modified—— 若缺失，说明auto_reload失效或缓存仍在工作 - CI 流水线中应断言：
php bin/console debug:container --parameter=twig.options | grep -q '"cache":false' - 注意 IDE 的“safe write”机制（如 PHPStorm 默认开启）：先写临时文件再替换原文件，Twig 监听不到变更，需在设置中关闭
最麻烦的从来不是关不掉缓存，而是你改了 base.html.twig，队友的机器还在读 var/cache/dev/twig/abc123.php 里的旧编译结果。把 cache: false 写死在配置里，再加一条 CI 检查，比每次问“你清缓存了吗”可靠得多。
