cache: false是唯一可靠关闭twig模板缓存的方式；设为null、~或注释掉均会回退至默认缓存路径，必须显式配置并配合auto_reload: true生效。
cache: false 是唯一可靠写法，不是设成 null 或注释掉
很多人以为把 cache 配置项注释掉、设为 null 或 ~ 就等于关闭缓存，实际完全相反：Symfony 会 fallback 到默认路径 %kernel.cache_dir%/twig，缓存照常工作。必须显式写 cache: false（YAML 布尔字面量），这个值会被 Twig 引擎识别为“禁用缓存适配器”，彻底跳过写入和读取逻辑。
常见错误配置：
-
cache: ~→ 等价于未设置，走默认路径 -
cache: ""或cache: null→ 被 Symfony 合并为字符串空值，Twig 解析时仍尝试创建目录 -
cache: "%kernel.cache_dir%/twig_dev"→ 路径合法，缓存就启用，哪怕在 dev 环境
正确位置在 config/packages/twig.yaml（Symfony 3.4+）或 app/config/config_dev.yml（老项目），且该配置不能被其他环境配置覆盖。
验证是否真关掉了：看 var/cache/dev/twig/ 是否还写文件
关掉后，var/cache/dev/twig/ 目录不应再生成任何 PHP 文件。操作步骤：
- 手动删掉整个
var/cache/dev/twig/目录 - 改一个
.twig模板并保存 - 刷新页面
- 检查该目录是否为空 —— 如果有新文件（如
abc123.php）生成，说明cache: false没生效
注意：某些 IDE（如 PHPStorm）开启 “safe write” 时，会先写临时文件再原子替换，导致 Twig 的 filemtime() 检查失效，模板变更不被感知。此时需在 IDE 设置中关闭该选项。
auto_reload: true 必须同时启用，否则改了也不生效
cache: false 只是禁用缓存存储，但 Twig 还要靠 auto_reload 来决定是否每次请求都重新读取源文件。如果 auto_reload: false，即使缓存关了，Twig 也会在第一次加载后把模板内容存在内存里，后续请求不再检查文件修改时间。
确认方式：
- 检查
twig.yaml中是否明确写了auto_reload: true - 或依赖默认行为（Symfony 默认开启），但前提是没被其他配置覆盖（比如在
config_prod.yml中误配到 dev 配置块） - 运行
php bin/console debug:container --parameter=twig.options，输出中应看到"auto_reload" => true和"cache" => false
Windows 下尤其要注意：杀毒软件或文件系统权限可能让 file_put_contents() 失败，报错 Permission denied，这会导致 auto_reload 降级失败，表现像“缓存没关”——其实根本没机会 reload。
Docker 和 CI 环境下容易漏掉的硬性检查点
本地能跑不等于协作环境一致。多人开发或 CI 流水线中，必须做两件事：
- 在 CI 脚本里加断言：
php bin/console debug:container --parameter=twig.options 2>&1 | grep -q '"cache" => false' - 用 curl 测试响应头：
curl -s -I http://app/_profiler | grep -q "Last-Modified"—— 若缺失，说明 auto_reload 没起作用，或模板路径解析异常
更隐蔽的问题：Docker 容器内 var/cache 目录若挂载为只读卷，或宿主机与容器时区不同，filemtime() 返回时间戳偏差超 1 秒，Twig 会认为文件“未更新”，跳过重载。这类问题不会报错，只会让你反复怀疑是不是自己改错了模板。
真正麻烦的不是关不掉，而是你改了模板，队友的机器、CI 构建镜像、甚至你昨天重启的容器，还在读上一次编译出来的 PHP 缓存文件 —— 所以 cache: false 必须写死在配置里，而不是靠环境变量或口头约定。
