必须在twig.yaml中明确写cache: false，而非注释或设为null；该布尔值需置于config/packages/twig.yaml中，多twig实例须逐一配置，且app_debug=true不影响twig缓存。
twig.yaml 里必须写 cache: false，不是注释掉或留空
很多人以为把 cache 配置行注释掉、或者设成 ~ 或 null 就等于关了缓存，其实 Symfony 会 fallback 到默认路径（%kernel.cache_dir%/twig），结果还是在写文件。唯一生效的写法是明确用 YAML 字面量 false：
twig:
cache: false
debug: true
auto_reload: true
注意三点：
-
cache: false是布尔值，不是字符串"false"，否则会被当路径处理 - 这个配置必须放在
config/packages/twig.yaml（Symfony 3.4+）或app/config/config_dev.yml（老项目），不能只在parameters.yml里改 - 如果项目用了多个 Twig 实例（比如邮件模板单独配了个
email_twig），每个都要单独加cache: false
别信 APP_DEBUG=true 就自动关缓存
Symfony 的 debug 开关控制的是 Profiler、错误页面、容器热加载等，和 Twig 缓存完全无关。即使 APP_ENV=dev 且 APP_DEBUG=true，Twig 默认仍启用磁盘缓存——你改了 base.html.twig 刷新没反应，八成就是这原因。
验证方法很直接：
- 删掉
var/cache/dev/twig/目录 - 改一个模板，保存
- 刷新页面，再看
var/cache/dev/twig/是否有新 PHP 文件生成 - 没生成 → 关成功；有生成 → 配置没生效或被覆盖
Docker / Windows 下容易卡在权限和文件监听上
关了缓存不代表立刻实时生效，两个典型阻断点：
- Windows 上杀毒软件或 IDE（如 PHPStorm）可能锁住
var/cache/dev/twig/，导致file_put_contents(): Permission denied报错，Twig 回退到内存缓存（ArrayCache），表现像“关了但没完全关” - Docker 容器里
var/cache目录若没挂为可写卷，或宿主机与容器时区不一致，filemtime()返回时间异常，Twig 误判模板未更新，跳过重编译 - PHPStorm 默认开启 “safe write”，保存时先写临时文件再原子替换，Twig 的
auto_reload监听不到变更 —— 要去 Settings → System Settings → uncheck “Use safe write”
CI 流水线里必须检查 twig.options.cache 值是否为 false
本地配对了没用，队友的机器、CI 构建环境可能跑在 prod 模式下，或者 config 被环境变量覆盖。最稳妥的方式是在 CI 脚本里加断言：
php bin/console debug:container --parameter=twig.options | grep "cache.*false"
同时建议补一条 HTTP 层验证：
- 请求一个带模板的路由（比如
/_profiler） - 检查响应头是否含
Last-Modified—— 这个头由 Twig 在auto_reload: true且缓存关闭时注入，缺失说明缓存机制仍在干预
真正麻烦的不是配不配得对，而是有人改完模板推了代码，别人拉下来跑着旧结果还查不出哪出问题。把 cache: false 写死 + CI 断言，比每次问“你清缓存了吗”省事得多。
