必须显式配置cache: false才能真正关闭Twig模板缓存，因debug=true仅控制错误提示与Profiler，不影响Twig编译缓存；设为null、~或空字符串会回退至默认路径，仍启用缓存。
改了 Twig 模板文件却没变化，不是缓存没清干净，而是 Twig 缓存根本没被真正关闭——debug=true 不等于模板不缓存，必须显式设 cache: false。
为什么 debug=true 还是缓存模板？
Symfony 的 debug 参数控制的是错误提示、Profiler、容器热加载等行为，和 Twig 缓存引擎无关。Twig 默认在 dev 环境下仍会把 .twig 编译成 PHP 文件写入 var/cache/dev/twig/，哪怕 debug=true 也照常缓存。
-
cache: false是唯一能禁用 Twig 编译缓存的配置；设为null、~或留空，Symfony 会 fallback 到默认路径（如%kernel.cache_dir%/twig），实际仍启用 - Windows 下若
var/cache/dev/twig/被杀毒软件锁定或权限不足，file_put_contents()失败，Twig 可能静默回退到内存缓存（ArrayCache），导致“看起来像关了但其实没关” - IDE（如 PHPStorm）开启 “safe write” 时，先写临时文件再原子替换，Twig 的
auto_reload可能监听不到变更事件
怎么确认 cache: false 生效了？
别只看页面是否刷新，要验证缓存目录是否真停写：
- 手动删掉
var/cache/dev/twig/目录 - 改一个模板（比如在
base.html.twig里加一行<!-- test -->） - 刷新页面，检查
var/cache/dev/twig/是否有新 PHP 文件生成 —— 如果没有，说明cache: false已生效 - 同时运行
php bin/console debug:container --parameter=twig.options，输出中cache值必须是false（不是null、字符串或路径）
哪些地方容易漏配导致缓存没关掉？
Twig 配置分散，多个位置都可能覆盖 cache: false：
- 主配置在
config/packages/twig.yaml，但若项目用了环境专用配置（如config/packages/dev/twig.yaml），优先级更高，得在那里也写cache: false - 如果定义了多个 Twig 环境（例如
email_twig），每个都要单独关：在对应配置块里加cache: false - Docker 环境下，
var/cache必须挂载为可写卷；宿主机和容器时区不一致会导致filemtime()返回异常时间戳，Twig 误判文件未更新 - 某些部署脚本或 CI 流程中执行了
cache:warmup，它会强制重建var/cache/dev/twig/，绕过cache: false—— 应禁用 warmup 或确保 warmup 前已加载正确配置
改完模板还是不生效？先查这三件事
缓存只是常见原因，别一上来就猛清目录：
- 确认当前环境确实是
dev：APP_ENV和APP_DEBUG都得是dev和true；php bin/console server:run若没加--env=dev，默认走prod，而prod下cache: true是硬编码逻辑 - 检查响应头是否有
Last-Modified：用curl -I http://localhost/_profiler查看，有说明auto_reload: true生效且 Twig 正监听文件变更；没有则可能是auto_reload被关了，或文件系统 inotify 限制被触发 - 浏览器强刷（
Ctrl+Shift+R）并禁用缓存调试：DevTools → Network → 勾选 “Disable cache”，排除浏览器层干扰
真正麻烦的不是找不到开关，而是有人改了 base.html.twig 却不知道队友的机器正从 var/cache/dev/twig/abc123.php 里读旧代码。把 cache: false 写死在配置里，再加一条 CI 断言检查 twig.options.cache === false，比每次问“你清缓存了吗”可靠得多。
