twig.cache: false 是唯一彻底禁用 twig 编译缓存的配置；设为 null、~ 或空值均会回退至默认缓存路径，且必须置于 dev 环境专属配置中，配合 auto_reload: true 并验证响应头 last-modified 才确保生效。
twig.cache: false 是唯一生效的配置值
设 cache: null、cache: ~ 或留空，Symfony 都会 fallback 到默认路径（%kernel.cache_dir%/twig），实际仍启用磁盘缓存。只有明确写 cache: false（YAML 布尔字面量，不是字符串）才能彻底禁用 Twig 编译缓存引擎。
这个配置必须落在 dev 环境专属文件里，比如 config/packages/dev/twig.yaml 或 app/config/config_dev.yml；若写在全局 twig.yaml 中，prod 环境也会被强制关缓存，导致严重性能问题。
-
cache: false后，Twig 不再生成或读取var/cache/dev/twig/下的 PHP 文件 - 每个请求都会重新解析
.twig源文件，改保存即可见效，但响应时间略升 - 如果用了多个 Twig 实例（如 email_twig），每个都要单独配
cache: false
auto_reload: true 必须显式确认开启
即使 cache: false 已设，若 auto_reload 被意外关闭（比如被某 Bundle 覆盖），Twig 也不会监听文件修改时间，导致你改了模板却无反应。
检查方式：执行 php bin/console debug:container --parameter=twig.options，输出中应包含 "auto_reload": true。它默认为 true，但某些自定义环境或旧版配置可能覆盖该值。
- IDE 的“safe write”功能（如 PHPStorm 默认开启）会导致
filemtime()获取到临时文件时间，使 auto_reload 失效 → 关闭 IDE 的 safe write - Docker 环境下，宿主机与容器时区不一致，
filemtime()可能返回未来时间，触发 Twig 认为文件“未更新” → 统一时区并验证date输出 - Windows 用户注意杀毒软件或 OneDrive 可能锁定
var/cache/dev/twig/目录，造成写入失败和 auto_reload 降级
验证是否真正关闭缓存的三步法
别信“我改了，刷新没变”就以为关失败——先确认是否真走 dev 环境，再看缓存目录行为，最后抓响应头。
- 检查
.env：确保APP_ENV=dev且APP_DEBUG=true，缺一不可 - 删掉
var/cache/dev/twig/，改一个模板并保存，刷新页面后观察该目录是否仍为空 → 空则说明cache: false生效 - 用
curl -I http://localhost/_profiler查响应头，应含Last-Modified→ 有则说明 auto_reload 正常工作
CI/CD 中必须断言的两个硬性条件
本地调通不等于团队协作安全。多人开发时，有人漏配、有人手误清错缓存、有人 Docker 启动没带 --env=dev，都会让模板缓存悄悄复活。
在 CI 脚本里加两行检查，比每次问“你清缓存了吗”管用：
php bin/console debug:container --parameter=twig.options 2>&1 | grep -q '"cache":.*false'curl -sI http://app:8000/_profiler | grep -q "Last-Modified"
真正难处理的不是配置本身，而是缓存状态在不同机器上不可见、不可测、不可控。把 cache: false 写死 + CI 断言，才是可落地的协作规范。
