必须显式设 cache: false 才能真正关闭 Twig 模板缓存，因为 debug=true 仅影响错误提示和 Profiler，不控制 Twig 缓存；Twig 在 dev 环境默认仍启用磁盘缓存，会复用已编译的 PHP 文件而非重新解析模板。
关掉 Twig 模板缓存不能只靠 debug=true，必须显式设 cache: false，否则改完 .twig 文件根本不会生效。
为什么 debug=true 还是不刷新模板
Symfony 的 debug 开关控制的是错误提示、Profiler、容器热加载等，和 Twig 缓存无关。Twig 默认在 dev 环境下仍启用磁盘缓存（写入 var/cache/dev/twig/），你保存文件后它根本不去重新解析，而是直接加载已编译的 PHP 文件。
-
debug=true不会覆盖 Twig 的缓存行为，两者完全解耦 - 即使
APP_ENV=dev且APP_DEBUG=true都满足，twig.cache仍默认指向一个真实路径（如%kernel.cache_dir%/twig） - 常见假象：删了
var/cache/dev/twig/后第一次刷新正常，但第二次又卡住——说明缓存又被自动重建了
怎么真正关闭 Twig 缓存（Symfony 3）
唯一可靠方式是在 Twig 配置中硬编码 cache: false，不是注释掉、不是设为 null 或空字符串，必须是 YAML 字面量 false。
- 修改
config/packages/twig.yaml，确保包含：twig: cache: false
- 如果用了多个 Twig 实例（比如单独配了
email_twig），每个都要单独加cache: false - 设成
~或null会被 Symfony 合并回默认路径，等于没关 - Windows 下注意杀毒软件或 IDE（如 PHPStorm）可能锁住
var/cache/dev/twig/目录，导致file_put_contents(): Permission denied错误
验证是否真的关成功了
别信“好像刷新了”，要实锤确认缓存停写。
- 先手动删掉
var/cache/dev/twig/目录 - 改一个模板文件（比如加个
{{ dump() }}），保存 - 刷新页面，再检查
var/cache/dev/twig/是否有新 PHP 文件生成 —— 如果没有，说明关成功了 - 若用 Docker，确保
var/cache是可写卷，且宿主机与容器时区一致，否则filemtime()判断失效，缓存误判“未更新”
关掉之后要注意什么
关缓存不是零成本操作：每次请求都会重新解析 .twig 文件，页面响应变慢，但换来的是“改保存即生效”的确定性。
- 开发阶段够用，但切勿在 prod 环境设
cache: false，会拖垮性能 - 某些 IDE（如 PHPStorm）默认开启 “safe write”，先写临时文件再原子替换，Twig 监听不到变更 —— 需在设置里关掉该选项
- 如果模板结构稳定、只是调样式或文案，可折中用内存缓存适配器（如
array），避免磁盘 I/O，又不完全失去缓存机制
最麻烦的不是关不掉，而是你改了模板，队友的机器还在读 var/cache/dev/twig/abc123.php 里的旧编译结果。把 cache: false 写死在配置里，比每次问“你清缓存了吗”靠谱得多。
