真正关闭Twig缓存需同时满足debug: true、auto_reload: true和cache: null（或false），且仅限dev环境；prod环境下必须保持debug: false以启用缓存，否则性能崩溃。

config.yml里关Twig缓存根本不起作用

直接在config.yml里写cache: false或cache: ~，是无效的。

Symfony 3 的 Twig 配置不走config.yml主配置文件，而是由twig.yaml（或config.yml中twig:顶层键）控制。

而且，必须配合debug和auto_reload共同生效。

真正关闭Twig缓存的三要素

关缓存不是只设一个开关，而是让 Twig 每次都重新编译模板。

这只应在开发调试时启用，生产环境绝对禁止。

• debug: true：必须开启，否则auto_reload被忽略
• auto_reload: true：启用后，Twig 会检查 .twig 文件修改时间，变化则重编译
• cache设为null、false或一个不可写的路径（如/dev/null）：强制跳过写缓存文件

示例（app/config/config.yml）：

twig:
debug: '%kernel.debug%'
auto_reload: '%kernel.debug%'
cache: '%kernel.debug%'

注意：%kernel.debug%在dev环境下为true。

此时，cache: true会被 Twig 解释为“用默认缓存路径”。

所以实际要关缓存，得显式写cache: null或cache: false。

为什么改了config.yml还是看到var/cache/下有twig/目录

Symfony 自己的缓存体系，比如容器、路由这些，和 Twig 的编译缓存，是两回事。

哪怕已经把 Twig 缓存关掉，执行cache:clear时，系统照样还是会把var/cache/dev/twig/这个目录结构重新建出来。

不过，里面不会再产出 .php 编译文件。

判断是否真的关掉很简单：看看目录里有没有以xxx.php结尾的编译文件。没有的话，就说明配置生效了。

• 运行php bin/console cache:clear --env=dev后，检查var/cache/dev/twig/是否为空或只含空子目录
• 修改一个 .twig 文件，刷新页面，观察响应时间是否明显变长（重编译开销）
• 若仍有缓存行为，确认没被APP_DEBUG=0覆盖，或.env里SYMFONY_ENV=prod误设

关缓存后性能暴跌，但debug=false却没生效

这是典型环境错配。

你可能在dev环境改了配置，却用APP_ENV=prod访问，或者反过来了。

Twig 缓存行为完全由当前运行环境的kernel.debug值决定，而不是你编辑的是哪个 config 文件。

• 执行php bin/console debug:container --env=dev | grep debug确认 dev 环境 debug 为 true
• 执行php bin/console debug:container --env=prod | grep debug确认 prod 环境 debug 为 false
• 不要在prod下关 Twig 缓存——那会导致每次请求都解析模板，CPU 直接拉满

开发环境和生产环境的正确做法

真正需要拿捏的，不是“到底要不要关”。

而是“该在什么场景下关、什么场景下开”。

• 开发阶段：通常使用dev + debug=true + auto_reload=true + cache=null，方便看界面、查问题
• 上线阶段：必须切回prod + debug=false

到了这个状态下，cache即便不手动写，Twig 也会默认把文件缓存自动开起来。