必须显式设置cache: false才能真正禁用twig模板缓存，仅app_debug=true或app_env=dev无效；因twig在dev下仍默认将编译php文件写入var/cache/dev/twig/，请求直接执行缓存而非解析源文件，改模板无反应实为缓存未真正关闭。
必须显式设置 cache: false 才能真正禁用 Twig 模板缓存，仅靠 APP_DEBUG=true 或 APP_ENV=dev 完全无效。
为什么改了 .twig 文件却没反应
Twig 在 dev 环境下默认仍会把编译后的 PHP 代码写入 var/cache/dev/twig/，下次请求直接 include 这些文件，跳过模板解析。你看到的“刷新生效”，其实是缓存文件恰好被清掉或未命中——不是机制保障，是运气。
- 常见错误现象：
file_put_contents(): Permission denied（Windows 下杀毒软件锁住目录）、Warning: require(.../abc123.php): failed to open stream（缓存路径不可写但配置没设false） - 不要依赖
cache:clear：它只清容器和元数据缓存，Twig 编译缓存需额外干预，且每次手动清太反人类 - 验证是否真关闭：改一个
.twig文件后，检查var/cache/dev/twig/目录下是否**完全停止生成新 PHP 文件**；若有，说明配置没生效
怎么在 config/packages/twig.yaml 中正确禁用
该文件优先级最高，覆盖所有环境推导逻辑。别留空、别注释、别写字符串 "false"，必须用 YAML 布尔字面量。
twig:
default_path: '%kernel.project_dir%/templates'
cache: false
auto_reload: true
-
cache: false是硬开关，强制 Twig 每次请求都重新解析.twig源文件 -
auto_reload: true必须同时开启，否则即使cache: false，Twig 也不会主动监听文件修改时间戳，你得手动刷新两次才生效 - 删掉任何类似
cache: "%kernel.cache_dir%/twig"的动态路径配置——它会让缓存回退到目录模式，尤其在cache:warmup后自动创建目录，等于白设
多人协作时如何避免本地配置漂移
一个人设错，整个团队就可能看到旧模板。不能靠口头约定，得靠可验证的落地动作。
- CI 脚本中加入断言：
php bin/console debug:container --parameter=twig.options | grep '"cache":.*false' - 用
curl -I http://localhost/_profiler检查响应头是否含Last-Modified；缺失说明auto_reload失效或缓存未真正关闭 - Docker 或 IDE 启动命令里必须显式指定
--env=dev，否则php bin/console server:run可能 fallback 到prod，而 prod 下cache: true是硬编码行为 - Windows 用户额外注意：
var/cache/dev/twig/长路径+权限问题高频触发，建议用 WSL2 或确保该目录对 PHP 进程可读写
真正麻烦的不是配不配得对，而是改完模板后没人意识到自己正从 var/cache/dev/twig/abc123.php 里读着三天前的编译结果。把 cache: false 写死在配置里，再加一条 CI 检查，比每次问“你清缓存了吗”可靠得多。
