twig.cache: false 是唯一能真正关闭模板缓存的配置值，必须显式设置为布尔 false（非字符串），且需配合 auto_reload: true 才能实现改保存即生效；还需确保缓存目录权限正确、无杀毒软件干扰，并在 ci 中断言该配置生效。
twig.cache: false 是唯一能真正关闭模板缓存的配置值
很多人以为设 APP_DEBUG=true 就等于模板不缓存，其实 Twig 缓存开关和 Symfony 的 debug 模式完全独立。即使在 dev 环境下，Twig 默认仍会把编译后的 PHP 文件写入 var/cache/dev/twig/，改了 .twig 文件却没反应，八成是这个缓存还在起作用。
必须在 config/packages/twig.yaml（或旧版 app/config/config_dev.yml）里显式写：
twig: cache: false
cache: false 是 YAML 字面量布尔值，不是字符串 "false"，也不是 null 或 ~ —— 后两者会被 Symfony 合并为默认路径，实际无效。
如果你用了多个 Twig 实例（比如单独配了 email_twig），每个都要单独加这一行。
auto_reload: true 必须开着，否则关了缓存也检测不到文件变更
关掉缓存只是让 Twig 不再复用旧的 PHP 文件；但要“改保存即生效”，还得靠 auto_reload 去监听文件修改时间。它默认是 true，但以下情况可能被覆盖：
- 自定义 Twig 环境时手动设了
auto_reload: false - 某些 Docker 卷挂载导致
filemtime()返回错误时间（宿主机与容器时区不一致） - IDE（如 PHPStorm）开启“safe write”，先写临时文件再原子替换，Twig 监听不到变更
验证方式：删掉 var/cache/dev/twig/，改一个模板并保存，刷新页面后检查该目录是否仍为空 —— 空则说明 cache: false 和 auto_reload: true 都生效了。
Windows 下要注意权限和杀毒软件锁住缓存目录
即使配置正确，var/cache/dev/twig/ 若因权限不足或被杀毒软件占用，Twig 会静默失败，并可能 fallback 到内存缓存（ArrayCache），导致你误以为“关不掉”。典型错误是：
file_put_contents(): Permission denied
解决方法：
- 确保
var/cache及其子目录对 Web 服务器用户可写 - 临时关闭杀毒软件实时扫描（尤其针对
var/目录） - 检查 Windows 长路径限制是否触发（路径过长时 PHP 可能无法创建文件）
如果用 Docker，还要确认挂载卷权限设置正确，且 umask 没导致新文件不可写。
CI/CD 中必须断言 twig.options.cache === false
本地关掉了不等于团队环境都关了。多人协作中，有人漏配、有人用错环境变量（比如 APP_ENV=prod 被覆盖）、或者 CI 构建时没走 dev 配置，都会让缓存悄悄启用。
在 CI 脚本里加一行检查：
php bin/console debug:container --parameter=twig.options | grep '"cache":false'
更进一步，访问一个带模板的路由（比如 /_profiler），用 curl -I 检查响应头是否有 Last-Modified —— 没有就说明 auto_reload 失效或缓存没真正关。
真正麻烦的从来不是怎么关，而是关没关成功没人知道。把 cache: false 写死 + CI 断言，比每次问“你清缓存了吗”靠谱得多。
