cache: false 是唯一生效写法，设为 null、~、空字符串或注释均会回退至默认缓存路径；必须显式声明布尔值 false，twig 引擎才跳过缓存写入。
twig.yaml 里 cache: false 是唯一生效写法
不是设成 null、~、空字符串或注释掉，这些都会被 Symfony 合并回默认路径（var/cache/dev/twig/）；必须显式写 cache: false，YAML 解析器会把它当作布尔值处理，Twig 引擎收到 false 才真正跳过缓存写入逻辑。
示例配置片段：
twig:
default_path: '%kernel.project_dir%/templates'
cache: false
debug: true
-
cache: false优先级最高，覆盖环境判断和任何 fallback 行为 - 若用了多个 Twig 环境（如
email_twig），每个都要单独配cache: false - PHPStorm 等 IDE 的 “safe write” 功能可能导致文件修改不被 Twig 监听到，建议关闭该选项
为什么 debug: true 不等于模板不缓存
Symfony 的 debug: true 控制的是 Profiler、错误堆栈、容器热加载等，而 Twig 缓存由自身引擎独立管理，默认在 dev 下仍启用以提升响应速度。两者开关不联动，这是最常踩的坑——改了 .twig 文件没反应，第一反应不该是清缓存，而是查 cache 是否真关了。
- 验证方式：删掉
var/cache/dev/twig/，改一个模板并刷新，目录里不再生成新 PHP 文件，说明关成功了 - 若目录里仍有文件生成，说明
cache没生效，大概率是 YAML 写成了cache: ~或路径字符串 - Docker 环境下注意
var/cache目录是否挂载为可写卷，且宿主机与容器时区一致，否则filemtime()判断可能出错
auto_reload 必须为 true，否则关了 cache 也没用
cache: false 只让 Twig 不写编译文件，但不自动重读源模板——这一步靠 auto_reload 控制。它默认是 true，但若被覆盖（比如在 config/packages/twig.yaml 里写了 auto_reload: false），即使缓存关了，修改保存后也不会生效。
- 检查当前值：运行
php bin/console debug:container --parameter=twig.options，确认输出中auto_reload是true - 不要依赖
APP_ENV=dev自动开启 —— 某些 Docker Compose 配置或 CLI 启动命令（如server:run未带--env=dev）会导致实际运行在 prod 模式 - Windows 下若遇到
file_put_contents(): Permission denied，先检查杀毒软件是否锁了var/cache/dev/twig/目录
多人协作时怎么确保配置不被绕过
本地关掉缓存只是第一步，CI 流水线里必须断言配置真实生效，否则队友的机器可能还在读旧缓存。不能只信“我配了”，得用机器验证。
- CI 脚本中加入：
php bin/console debug:container --parameter=twig.options | grep -q '"cache":false' - 再加一条 HTTP 验证：
curl -s -I http://localhost/_profiler | grep -q "Last-Modified"，缺失该 header 就说明auto_reload失效或缓存未真正关闭 - 禁止在 config 中使用动态路径如
"%kernel.cache_dir%/twig"——不同环境%kernel.cache_dir%可能指向不同位置，且 warmup 后该目录会被创建，实际又启用了缓存
var/cache/dev/twig/abc123.php 里读着上周的编译结果。把 cache: false 和 auto_reload: true 写死在配置里，并用 CI 脚本盯住它们，比每次问“你清缓存了吗”靠谱得多。
