必须显式设cache: false才真正关闭Twig模板缓存，因debug: true仅控制错误显示与Profiler，不干预Twig自身缓存；需同时配置auto_reload: true并验证磁盘无新PHP文件生成。
改完 Twig 模板没反应？不是缓存没清，而是根本没关掉——debug: true 不等于模板不缓存，必须显式设 cache: false 才生效。
为什么 debug=true 还要手动关 cache
Symfony 的 debug 控制错误显示、Profiler 和容器热加载，而 Twig 缓存由自身引擎独立管理，默认在 dev 下仍启用以提升响应速度。两者开关不联动，误以为开了 debug 就等于模板实时生效，是协作中最多见的误解。
-
debug: true时，Twig 仍会把.twig编译成 PHP 文件写入var/cache/dev/twig/ - 只要该目录可写，哪怕你改了模板，Twig 也会优先加载已编译的 PHP 文件
- 只有
cache: false才强制跳过编译缓存，每次请求都重新解析原始文件
怎么真正关闭 Twig 模板缓存
在 config/packages/twig.yaml（或 Symfony 3 的 app/config/config_dev.yml）中，明确写死 cache: false：
twig: cache: false auto_reload: true
-
cache: false是唯一可靠方式；设成null、~或留空，Symfony 会回退到默认路径，实际仍启用缓存 -
auto_reload: true必须同时开启，否则即使关了缓存，Twig 也不会监听文件变更，需手动刷新才能触发重解析 - 若用了多个 Twig 环境（如
email_twig），每个实例都要单独配cache: false
验证是否真的关成功了
别只信配置，要看磁盘和行为：
- 删掉
var/cache/dev/twig/目录，改一个模板并保存，刷新页面 —— 如果该目录里**没生成新 PHP 文件**，说明关成功了 - 检查
APP_ENV=dev且APP_DEBUG=true在.env中同时生效，缺一不可 - Windows 下注意杀毒软件或 IDE “safe write” 功能可能锁住目录，导致
file_put_contents(): Permission denied错误；PHPStorm 中需关闭 Settings → System Settings → “Use safe write” - Docker 环境下确保
var/cache是可写卷，且宿主机与容器时区一致，否则filemtime()判断失效，缓存误判未更新
关缓存后渲染变慢，但调试更准
关闭后每次请求都重新解析 .twig 文件，启动耗时上升是必然的，但换来的是：改保存即生效、语法错误立刻暴露、逻辑分支调试不被缓存掩盖。
- 这不是性能倒退，而是开发阶段的必要取舍 —— 生产环境必须开缓存，但 dev 阶段宁可慢一点，也不能被“看似生效实则读旧缓存”的假象误导
- 如果团队多人协作，务必把
cache: false写死在config_dev.yml，并在 CI 中加断言：php bin/console debug:container --parameter=twig.options输出中确认cache值为false（不是null或路径字符串） - 最麻烦的从来不是配置本身，而是有人改了
base.html.twig却不知道队友的机器正从var/cache/dev/twig/abc123.php里读着一周前的编译结果
