必须显式设cache: false才能真正关闭Twig模板缓存，仅debug=true无效；因Twig默认在dev环境仍缓存编译后的PHP文件于var/cache/dev/twig/，改.twig源文件不触发更新，需验证目录是否停写、响应含Last-Modified头且debug:container显示cache=>false。
必须显式设 cache: false，仅开 debug=true 不起作用。
为什么改了 .twig 文件没反应？
因为 Twig 默认在 dev 环境下仍启用编译缓存——它把 .twig 编译成 PHP 文件，存在 var/cache/dev/twig/ 下。哪怕 APP_DEBUG=true，只要没关掉缓存，你就还在读旧的 abc123.php。
- 检查
var/cache/dev/twig/目录是否在持续写入新文件（用ls -lt或资源管理器刷新看） - 若目录为空但页面仍不更新，可能是权限问题：
file_put_contents(): Permission denied常见于 Windows 或 Docker 容器内 - 别信“保存即生效”的错觉：没关缓存时，你改的是源文件，Twig 读的是缓存文件，两者完全脱钩
怎么在 config/packages/twig.yaml 中真正关掉缓存
不是注释掉 cache 行，也不是设成 null 或空字符串，必须写死为 YAML 字面量 false：
twig: cache: false auto_reload: true
-
cache: false是唯一被 Twig 引擎识别为“禁用缓存”的值；cache: ~或cache:（空）会被 Symfony 合并回默认路径 -
auto_reload: true要保留（默认就是 true），否则即使缓存关了，Twig 也不会主动检查文件修改时间 - 如果你用了多个 Twig 实例（比如邮件模板单独配了个
email_twig），每个都要单独加cache: false
验证是否真关掉了缓存
不能只看配置写了没，得看运行时行为和磁盘表现：
- 访问任意页面后，立刻检查
var/cache/dev/twig/：该目录应始终为空，或只有零星临时文件（如.gitignore生成的） - 执行
php bin/console debug:container --parameter=twig.options，输出中"cache" => false才算生效 - 用
curl -I http://localhost/app_dev.php/_profiler查响应头，必须含Last-Modified；若缺失，说明auto_reload没起效或缓存仍在工作 - Windows 用户额外注意：
var/cache若被杀毒软件锁定、或路径过长（尤其含中文），会导致缓存无法清空或写入失败
关掉缓存后要注意什么
每次请求都会重新解析 .twig 文件 → 渲染变慢是必然的，但这是调试期可接受的代价。
- 不要在 prod 环境用
cache: false，它会让首字节时间（TTFB）明显升高 - 若用了自定义
TemplateIterator或手动调用Twig\Loader\FilesystemLoader，确保其构造参数没绕过全局配置 - 最麻烦的不是配置难，而是团队里有人忘了这行，结果他本地改完刷新就生效，别人却要反复问“你清缓存了吗？”——所以必须写死在
config_dev.yml或 CI 可断言的位置
