必须显式配置 cache: false 才能禁用 twig 模板缓存，仅设 debug=true 无效；否则修改 .twig 文件仍加载旧编译结果。
关掉 Twig 模板缓存、让改完保存就生效，不是设 debug=true 就完事——必须显式写死 cache: false，否则你改了 .twig 文件，页面还是旧的。
config/packages/twig.yaml 里必须写 cache: false
很多人以为 APP_ENV=dev + APP_DEBUG=true 就自动禁用模板缓存，其实 Twig 默认仍会把编译结果写进 var/cache/dev/twig/。这个路径由 cache 配置项控制，它不认布尔值字符串，只认 YAML 字面量 false：
twig: cache: false # 其他配置保持不变
-
cache: null或cache: ~会被 Symfony 合并成默认路径，等同于没关 -
cache: "false"（带引号）是字符串，Twig 会尝试把它当目录名创建，反而报错 - 如果你用了多个 Twig 实例（比如单独配了
email_twig），每个都要单独加这一行
验证是否真关掉了：看 var/cache/dev/twig/ 还写不写文件
关成功的表现，不是页面变快或变慢，而是那个目录彻底“躺平”：
- 删掉
var/cache/dev/twig/目录 - 改一个模板，保存
- 刷新页面，再检查该目录——如果里面没生成任何新
.php文件，说明关成功了 - 如果还有文件冒出，回头检查
twig.yaml是否拼错、是否被其他配置覆盖（比如config_dev.yml里又重写了cache）
Windows 下尤其注意：杀毒软件或 IDE（如 PHPStorm）可能锁住该目录；PHPStorm 还默认开 “safe write”，先写临时文件再替换，Twig 监听不到变更——得在设置里关掉。
别信 “auto_reload: true” 能兜底
auto_reload: true 是 Twig 的监听开关，但它只在缓存启用时才有意义：它决定“缓存过期后要不要重新读 .twig 文件”。一旦你设了 cache: false，Twig 就不再生成缓存，auto_reload 实际上不参与流程。所以：
- 不用特意去配
auto_reload，默认就是true - 但如果你没关
cache，单靠auto_reload: true也救不了——因为缓存没过期前，它根本不会去读磁盘上的新内容 - 用 Docker 的话，确保
var/cache是可写的卷，且宿主机和容器时区一致，否则filemtime()判断出错，缓存误判“没更新”
关掉之后性能会怎样？
每次请求都重新解析 .twig 文件，意味着 PHP 要做词法分析 + 编译成 PHP 代码，比直接 include 缓存文件慢不少。这不是 bug，是设计取舍：
- 开发阶段值得：改保存即生效，调试逻辑、语法、继承关系都直观
- 别在生产环境用——
cache: false只应出现在dev配置里 - 如果觉得太慢，可折中：把缓存指向内存适配器（如
cache: 'pool: twig.cache_pool'配合cache.adapter.php_array），避免磁盘 I/O，又不失变更检测能力
真正麻烦的不是性能下降，而是你改了模板却不知道队友的机器还在读 var/cache/dev/twig/abc123.php 里的旧编译结果——所以 cache: false 必须写死在版本控制里，而不是靠口头约定或本地 .env。
