必须显式设置cache: false才能真正关闭twig模板缓存，仅开启debug=true无效；关闭后每次请求重新解析.twig文件，改保存即生效，需验证var/cache/dev/twig/是否停写。
开发阶段关掉 Twig 模板缓存、同时让修改实时生效，不是简单设 debug=true 就完事——默认情况下即使 debug 开着，Twig 仍会缓存编译后的 PHP 文件，你改了 .twig 文件却没反应，大概率是缓存没真正清掉或路径权限不对。
Twig 编译缓存到底存在哪？
Twig 缓存默认写在 var/cache/{env}/twig/ 下，是一堆以哈希命名的 PHP 文件（比如 abc123.php）。它和 Symfony 的容器缓存分开管理，cache:clear 会清掉它，但开发时频繁手动清缓存太折腾。
- 确认当前环境是否真走 dev：检查
.env中APP_ENV=dev且APP_DEBUG=true，二者缺一不可 - 不要依赖“自动刷新”假象：哪怕 debug=true，Twig 默认仍启用缓存；必须显式禁用
- Windows 下注意路径分隔符和长文件名限制，
var/cache/dev/twig/若因权限或杀毒软件被锁，会导致缓存无法更新甚至报错file_put_contents(): Permission denied
怎么真正关闭 Twig 模板缓存
在 config/packages/twig.yaml 中强制设 cache: false，而不是留空或注释掉。这个配置优先级高于环境判断，能绕过所有默认行为。
twig: cache: false # 其他配置保持不变
-
cache: false是唯一可靠方式；设成null或~会被 Symfony 合并为默认路径，不生效 - 若用了自定义 Twig 环境（如单独配了个
email_twig），每个实例都要单独关cache - 关掉后，每次请求都会重新解析 .twig 文件 → 启动变慢，但改完保存即生效，适合调试逻辑和语法
为什么开了 debug 还要手动关 cache？
因为 Symfony 的 debug 控制的是错误显示、Profiler、容器热加载等，而 Twig 缓存由自身引擎控制，默认开启以提升 dev 下的响应速度。两者开关独立，容易误以为“debug=true 就等于模板不缓存”。
- 验证是否生效：删掉
var/cache/dev/twig/目录，改一个模板，刷新页面；如果目录里没新文件生成，说明关成功了 - 常见陷阱：某些 IDE（如 PHPStorm）在保存时触发“安全写入”，先写临时文件再替换原文件，导致 Twig 监听不到变更 —— 可在设置里关掉“safe write”
- 若用 Docker，确保
var/cache是可写的卷，且宿主机和容器时区一致，否则filemtime()判断可能出错，缓存误判未更新
想保留部分缓存又想快速调试怎么办
折中方案是把 Twig 缓存指向内存适配器，避免磁盘 I/O 延迟，又不完全失去缓存机制。适用于模板结构稳定、只调样式或小逻辑的场景。
twig: cache: 'cache.adapter.array'
-
cache.adapter.array是纯内存缓存，生命周期仅限单次请求，改完模板下次请求就自动刷新 - 不能跨请求共享，所以不会出现“改了没生效”的滞后问题
- 比
cache: false略快一点点，但差别微乎其微；真正省时间的是避免反复清缓存的操作
关缓存本身很简单，难的是确认它真的关了——别只信配置写了，要去看 var/cache/dev/twig/ 是否停写、是否还生成新文件、改模板后响应是否同步变化。这些细节不验证，很容易以为“已经关了”，结果还在对着旧缓存调试。
