只有显式配置 twig.cache: false（yaml 布尔值）才能真正禁用 twig 编译缓存，设为 null、~ 或空值均会回退默认路径；该配置需在 config/packages/twig.yaml 等实际 twig 配置文件中生效，多实例需逐一设置，且须配合 auto_reload: true 并确保时区、ide 安全写入、权限等环境正常。
twig.cache: false 是唯一生效的禁用方式
设 cache: null、cache: ~ 或留空，Symfony 会回退到默认路径（如 var/cache/dev/twig/），缓存照常工作。只有显式写 cache: false（YAML 布尔字面量，不是字符串）才能真正禁用 Twig 编译缓存引擎。
这个配置必须落在 Twig 的实际配置文件中，常见位置是：
-
config/packages/twig.yaml（推荐，全环境统一控制） -
app/config/config_dev.yml（Symfony 3 传统结构，仅影响 dev）
若项目用了多个 Twig 实例（如 email 渲染单独配了 email_twig），每个实例都得单独加 cache: false，否则那个实例仍会缓存。
debug=true 不等于模板不缓存
Symfony 的 debug 开关控制的是 Profiler、错误页面、容器热加载等，和 Twig 自身的缓存逻辑完全解耦。即使 APP_DEBUG=true 且 APP_ENV=dev，Twig 默认仍启用缓存以提升开发时响应速度——这是设计使然，不是 bug。
所以别再问“我都开 debug 了怎么模板还不更新”，答案就一个：cache: false 没配。
验证是否真关掉：删掉 var/cache/dev/twig/ 目录，改一个 .twig 文件并保存，刷新页面。如果该目录里没生成新 PHP 文件，说明成功；如果又冒出一堆 abc123.php，那就是配置没生效或被覆盖。
auto_reload: true 必须同时启用
cache: false 只是让 Twig 不写编译文件，但不保证它会主动检查模板是否改动。若 auto_reload 关了，Twig 会把模板内容整个读进内存并复用，你改了文件也无感知。
好在 Symfony 默认开启 auto_reload: true，但要注意：
- 某些 IDE（如 PHPStorm）开启“safe write”后，保存其实是先写临时文件再原子替换，Twig 的
filemtime()判断可能失效 → 关掉 IDE 的 safe write - Docker 环境下，宿主机与容器时区不一致会导致
filemtime()返回时间异常，Twig 误判文件未更新 → 统一时区，或挂载/etc/localtime - Windows 下长路径或杀毒软件锁定
var/cache/dev/twig/可能导致写失败，报file_put_contents(): Permission denied→ 检查目录权限和实时防护软件
CI/CD 中必须断言 cache 值为 false
本地配好了不等于上线就安全。团队协作中，有人手误注释掉 cache: false、CI 构建用错环境变量、甚至 Docker 镜像缓存了旧容器配置，都会让缓存悄悄复活。
在 CI 脚本里加两行硬性检查：
-
php bin/console debug:container --parameter=twig.options | grep '"cache":false'—— 确保输出中cache字段值是布尔false，不是null或路径字符串 -
curl -sI http://app/_error/500 | grep -q "Last-Modified"—— 若响应头含Last-Modified，说明 Twig 正监听文件变更；缺失则大概率缓存已启用或auto_reload失效
真正难缠的不是配不配得对，而是缓存静默生效后，A 改了模板、B 刷新看到旧结果、C 查日志发现请求根本没进新代码——这种问题排查成本远高于一开始就写死 cache: false 并加 CI 断言。
