必须显式配置cache: false，debug=true与模板缓存无关；twig缓存由cache选项独立控制，设为false才真正禁用，否则仍会编译并复用php模板文件。
必须显式配置 cache: false，仅设 debug: true 或 APP_DEBUG=true 完全无效。 Twig 的缓存开关和 Symfony 的 debug 模式是两套独立机制，很多人改完 .twig 文件没反应，就是卡在这一步。
为什么 debug=true 不等于模板不缓存
Twig 自身控制模板编译缓存，默认在 dev 环境下仍启用 —— 它只保证错误页面友好、Profiler 可用，但 base.html.twig 编译成的 abc123.php 依然会落盘到 var/cache/dev/twig/ 并被复用。你看到的“刷新生效”，其实是缓存文件还没过期，或 IDE 保存触发了 auto_reload 假象。
-
debug: true影响的是异常显示、dump()可用性、容器热加载等，和 Twig 编译缓存无关 -
auto_reload: true（默认开启）只在缓存存在时检查源文件修改时间，若缓存路径可写，它不会跳过缓存 - Windows 下杀毒软件或 Docker 卷权限问题，可能导致
file_put_contents()失败，缓存目录看似空，实则 Twig 回退到内存ArrayCache，行为更难排查
真正关闭缓存的唯一可靠写法
在 config/packages/twig.yaml（Symfony 3.4+）或 app/config/config_dev.yml（老版本）中，明确写死 cache: false：
twig:
cache: false
debug: '%kernel.debug%'
auto_reload: true
注意：cache: ~、cache: null、cache: '' 或留空，都会被 Symfony 合并为默认路径 %kernel.cache_dir%/twig，等同于没关。
- 若项目用了多个 Twig 实例（如 email 渲染单独配了一个
email_twig），每个都要单独加cache: false - 不要写
cache: "%kernel.cache_dir%/twig"—— 这个路径在cache:warmup后必然存在，缓存照常工作 - 关掉后，每次请求都会重新解析
.twig文件，启动变慢，但改保存即生效，适合调试逻辑分支、宏定义、嵌套 block 行为
验证是否真的关成功了
别信“刷新页面看起来变了”，要查磁盘和响应头：
- 删掉
var/cache/dev/twig/目录，然后改一个模板、刷新页面 —— 如果该目录里**没生成任何新.php文件**，说明关成功了 - 用
curl -I http://localhost/_profiler查响应头，确认含Last-Modified—— 若缺失，说明auto_reload未生效或缓存仍在接管 - PHPStorm 用户需关掉设置里的 “safe write”（安全写入），否则保存时先写临时文件再替换，Twig 监听不到
mtime变更 - Docker 环境务必确保
var/cache是可写卷，且宿主机与容器时区一致，否则filemtime()判断失效，缓存误判未更新
最麻烦的不是配置本身，而是团队里有人本地没关缓存，却把“我这儿没问题”当结论。把 cache: false 写死在 config 文件里，并在 CI 中用 php bin/console debug:container --parameter=twig.options 断言 cache 值为 false，才能堵住这个口子。
