Twig模板缓存本质是编译缓存，仅在prod环境生效，dev环境默认禁用；若dev下模板不更新，问题多在浏览器、代理或OPcache，而非Twig缓存。
模板缓存关不掉？先确认你真在动 Twig 缓存
Symfony 3 的“模板缓存”本质是 Twig 编译缓存，它和 cache:clear 清的不是一回事。命令行里没有直接开关它的 flag，但你可以绕过它——前提是知道它在哪、怎么被触发。
默认情况下，Twig 缓存路径是 var/cache/{env}/twig，且仅在 debug=false（即 prod 环境）时才真正生效；dev 环境下 Twig 默认禁用编译缓存，每次请求都重新解析模板。所以如果你在 dev 下调试却看到“旧模板”，问题大概率不在缓存，而在浏览器或代理层。
- 检查当前环境：运行
php bin/console about，看Environment和Debug值 - 确认 Twig 配置是否显式启用了缓存：查看
config/packages/twig.yaml，找cache:项。若设为false或null，则强制禁用；若指向目录（如%kernel.cache_dir%/twig），说明启用中 - 临时关闭 ≠ 清空：清空
var/cache是重头来过；而“关闭”意味着让 Twig 每次都跳过写入/读取缓存文件
dev 环境下模板实时生效的正确姿势
开发时最常用、最安全的“临时关闭”方式，就是确保你在 dev 环境，并让 Twig 自动跳过缓存逻辑：
- 启动服务时显式指定环境：
php bin/console server:run --env=dev（Symfony 3.4+ 支持） - 确保
.env中APP_ENV=dev且APP_DEBUG=1 - 不要手动设置
twig.cache为路径——留空或设为false即可 - 如果仍看到旧模板，先执行
php bin/console cache:clear --env=dev，再刷新页面（注意：这是清容器缓存，不是 Twig 缓存，但会影响 Twig 配置加载）
prod 环境下想临时禁用 Twig 缓存？别硬来
生产环境禁用 Twig 缓存等于主动降性能，不推荐。但若真要调试（比如部署后发现模板渲染异常），唯一可行的临时办法是改配置并重建缓存：
- 编辑
config/packages/prod/twig.yaml，把cache:设为false或注释掉整行 - 运行
php bin/console cache:clear --env=prod—— 这会清掉旧的 Twig 编译文件，下次请求时因配置禁用，Twig 就不再生成新缓存 - 注意：这会导致首次请求变慢（Twig 解析 + 编译），且所有请求都承担解析开销，仅限紧急排查
- 切勿用
rm -rf var/cache/prod/twig后不清理容器缓存，否则 Twig 可能仍从旧容器配置里读到缓存路径，造成行为不一致
容易被忽略的缓存干扰源
你以为关了 Twig 缓存就万事大吉？这些地方可能偷偷缓存着你的模板输出：
-
Response对象自带 HTTP 缓存头：控制器里调了$response->setPublic()->setMaxAge(3600)？浏览器或 CDN 会缓存整个响应，跟 Twig 无关 - 反向代理（如 Nginx FastCGI cache、Varnish）：它们缓存的是最终 HTML 字符串，Twig 是否编译成功根本没机会参与
- 浏览器本地缓存：按
Ctrl+F5强制刷新，或检查 Network 面板里 Response Headers 是否含X-Symfony-Cache或Cache-Control - PHP OPcache：如果 Twig 编译出的 PHP 文件被 OPcache 缓存，即使删了
var/cache，旧代码仍可能执行。必要时执行opcache_reset()或重启 PHP-FPM
