只有 yaml 字面量 false 才能真正禁用 twig 缓存，需在 config/packages/twig.yaml 中显式配置 twig: cache: false 并保留 auto_reload: true，否则仍会回退到默认缓存路径或内存缓存。
twig.cache: false 是唯一可靠写法
设成 null、~、空字符串或注释掉配置，Twig 都会 fallback 到默认路径（如 %kernel.cache_dir%/twig），实际仍启用缓存。只有 YAML 字面量 false 才能真正禁用编译缓存引擎。
必须写在 config/packages/twig.yaml 或 config/packages/dev/twig.yaml 中，且不能被其他环境配置覆盖：
twig:
cache: false
auto_reload: true
-
auto_reload: true必须显式保留（虽然 dev 默认开启，但某些自定义加载逻辑可能绕过） - 若项目用了多个 Twig 实例（如邮件模板单独配了
email_twig服务），每个都要单独加cache: false - Windows 下注意
var/cache/dev/twig/目录是否被杀毒软件锁定——即使配置正确，file_put_contents(): Permission denied也会让 Twig 回退到内存缓存，表现像“关不掉”
验证缓存是否真关闭了
别只看页面刷新有没有变化，要确认两件事：缓存文件停写 + 响应头含 Last-Modified。
- 清空
var/cache/dev/twig/后访问任意 Twig 页面，目录应保持为空；如果又生成了abc123.php类文件，说明cache: false没生效或被覆盖 - 用
curl -I http://localhost:8000/_profiler查响应头，必须看到Last-Modified—— 这是auto_reload: true正常工作的证据；缺失则 Twig 没监听文件变更，改了模板也不会重编译 - CI 脚本里可断言：
php bin/console debug:container --parameter=twig.options | grep '"cache":.*false'
APP_ENV=dev 不等于 Twig 缓存关闭
环境变量只是入口开关，很多地方会绕过它：
-
php bin/console server:run不加--env=dev时，默认走prod，而 prod 下cache: true是硬编码行为 - Docker Compose 中若写了
APP_ENV=prod覆盖，容器内实际就是生产模式 - 有人执行
php bin/console cache:clear忘记加--env=dev，清掉了 dev 缓存目录，Twig 可能回退到ArrayCache，导致“部分模板生效、部分不生效”的诡异现象
关缓存后性能下降是预期行为
每次请求都重新解析 .twig 文件 → 启动变慢、首字节延迟升高，这是代价。但它换来的是“保存即生效”，适合调试模板语法、继承逻辑、宏调用等。
- 不要在 CI 或测试环境关 Twig 缓存——那会拖慢整个测试套件；只在本地开发机上配
cache: false - 如果团队共用一套
config/packages/twig.yaml，建议用条件配置：when@dev: { twig: { cache: false } }，避免误入 prod - 真正麻烦的不是性能损失，而是有人改了
base.html.twig却没意识到队友的机器正从var/cache/dev/twig/xxx.php读旧编译结果——这种不一致比慢一点更难排查
