必须显式设 cache: false，仅 debug: true 无效；cache: ~、null 或空字符串均不生效，唯字面量 false 可彻底禁用缓存，且需同时启用 auto_reload: true 并排除 IDE 安全写入和 Docker 时区干扰。
必须显式设 cache: false，仅开 debug: true 不管用。 Symfony 3 的 Twig 缓存和 debug 模式是两套独立开关，很多人改完模板刷新没变化，就是卡在这儿。
为什么 cache: false 是唯一可靠写法
YAML 中的 cache: ~ 或 cache: null 会被 Symfony 合并成默认路径（比如 var/cache/dev/twig），实际仍启用缓存；cache: ""（空字符串）也不生效。只有字面量 false 才会让 Twig 引擎彻底跳过缓存逻辑，每次请求都重新解析 .twig 文件。
- 若用了自定义 Twig 实例（如
email_twig），每个实例的配置都要单独加cache: false - 不推荐用
cache: /dev/null或不可写路径——部分版本会静默失败或抛异常 - 关掉后，
var/cache/dev/twig/目录下不再生成任何 PHP 编译文件，这是最直接的验证方式
必须同时确认 auto_reload: true
即使 cache: false 生效，如果 auto_reload 被关掉，Twig 就不会监听文件修改时间（filemtime()），导致改了模板也无响应。
- 检查
config/packages/twig.yaml或config_dev.yml，确保有auto_reload: true（dev 环境默认开启，但可能被覆盖） - 某些 IDE（如 PHPStorm）开启“safe write”时，会先写临时文件再原子替换，导致
filemtime()不变 → Twig 认为文件没动 → 必须在 IDE 设置里禁用该选项 - Docker 环境下，宿主机与容器时区不一致会导致
filemtime()判断错乱，建议统一设为Europe/Berlin或UTC
验证是否真关成功
别只信配置，要动手验证。删掉 var/cache/dev/twig/ 后改一个模板，刷新页面：
- 如果目录里**没新文件生成**，且页面内容实时更新 → 关成功
- 如果目录里又冒出一堆
.php文件 → 配置没生效，回头检查 YAML 缩进、是否写成了字符串"false"、或被其他配置覆盖 - 运行
php bin/console debug:container --parameter=twig.options，输出中"cache" => false（布尔值，不是null或路径字符串）才算到位
真正容易被忽略的是协作场景：一个人本地关了，另一个人没改配置，CI 流水线又跑在 prod 模式下 —— 这时候不是“模板不生效”，而是“谁的模板生效”成了随机事件。把 cache: false 写死在 config_dev.yml，再加一条 CI 断言，比反复问“你清缓存了吗”实在得多。
