cache: false是唯一可靠关闭twig模板缓存的方式；需配合auto_reload: true，并在所有twig实例（如email_twig）中显式配置，否则仍会写入编译文件。
cache: false 是唯一能真正关闭 Twig 模板缓存的配置
仅设 APP_DEBUG=true 或 APP_ENV=dev 不足以禁用模板缓存——Twig 默认仍会把编译后的 PHP 文件写入 var/cache/dev/twig/，你改了 .twig 文件却没反应，大概率是这个缓存还在起作用。
必须在 config/packages/twig.yaml（或 app/config/config_dev.yml）中显式写死：
twig: cache: false
-
cache: null、cache: ~、cache: ""都会被 Symfony 合并为默认路径，等同于没关 - 若项目用了多个 Twig 实例（如邮件专用的
email_twig），每个都要单独配cache: false - Windows 下注意杀毒软件或 IDE 可能锁住
var/cache/dev/twig/目录，导致file_put_contents(): Permission denied
验证是否真关掉了：看 var/cache/dev/twig/ 还写不写文件
关掉缓存后，Twig 不再生成和读取编译文件，而是每次请求都重新解析原始 .twig 模板。最直接的验证方式就是观察缓存目录是否“静默”：
- 先手动删掉
var/cache/dev/twig/整个目录 - 修改任意一个模板（比如
base.html.twig），保存 - 刷新页面，再检查
var/cache/dev/twig/—— 如果里面**没出现新 PHP 文件**，说明cache: false生效了 - 如果目录里又冒出
abc123.php这类文件，说明配置没生效，回去检查 YAML 缩进、环境是否真为 dev、有没有被其他配置覆盖
auto_reload: true 必须开着，否则改了也白改
cache: false 解决的是“不复用旧编译”，但 Twig 还要靠 auto_reload 来决定“要不要检查文件是否被修改”。两者缺一不可：
- 默认值是
true，但如果你在配置里显式写了auto_reload: false，即使cache: false，Twig 也不会感知文件变更 - 检查是否启用：
php bin/console debug:container --parameter=twig.options，输出中应含"auto_reload":true - 某些 IDE（如 PHPStorm）开启 “safe write” 后，保存实际是“写临时文件 + 原子替换”，Twig 的
filemtime()可能来不及捕获变更——建议关掉该选项 - Docker 环境下务必确认宿主机与容器时区一致，否则
filemtime()返回时间戳错乱，auto_reload会误判文件未更新
多人协作时，光本地配对没用，CI 必须断言
团队里只要有一台机器没关掉缓存，就可能让别人看到“已发布但未生效”的模板——这不是运气问题，是配置没被强制约束。
CI 脚本里加两行硬性检查：
php bin/console debug:container --parameter=twig.options 2>&1 | grep -q '"cache":false'-
curl -s -I http://localhost/_profiler | grep -q "Last-Modified"（响应头含Last-Modified表示auto_reload正常工作）
真正麻烦的不是怎么关，而是有人改完模板推上 Git，自己本地看着正常，队友拉下来却加载着 var/cache/dev/twig/xxx.php 里的旧逻辑——把 cache: false 写死在版本控制里的 config 文件中，并用 CI 卡住，比每次问“你清缓存了吗”靠谱得多。
