必须设cache: false而非null或~，因后者会被合并为默认路径仍启用缓存；删var/cache/dev/twig后刷新无新文件生成即生效，多人协作须写死配置确保一致。
为什么改了 .twig 文件却没反应
不是浏览器缓存，也不是服务器没重启——根本原因是 Twig 默认在 dev 环境下仍启用模板编译缓存。即使 APP_DEBUG=true 且 APP_ENV=dev 都正确，Twig 依然会把 index.html.twig 编译成 PHP 文件，写入 var/cache/dev/twig/，后续请求直接执行它。你改了源文件，但缓存没失效或没被绕过，自然看不到变化。
必须设 cache: false，不是注释掉或设为 null
在 config/packages/twig.yaml 中，找到 twig: 下的 cache 配置项，显式写成布尔值 false：
twig:
cache: false
debug: true
auto_reload: true
-
cache: ~或cache: null会被 Symfony 合并为默认路径（%kernel.cache_dir%/twig），实际仍启用缓存 -
cache: ""（空字符串）不合法，YAML 解析失败，启动报错 - 若项目有多个 Twig 实例（如 email 渲染单独配了一个
email_twig），每个都要单独加cache: false
验证是否真关掉了
别只看页面有没有变，要确认缓存目录是否彻底停写：
- 删掉
var/cache/dev/twig/目录 - 修改任意一个
.twig文件并保存 - 刷新页面，再检查
var/cache/dev/twig/—— 如果目录仍是空的，说明cache: false生效了 - 如果目录里又生成了新 PHP 文件（如
abc123.php），说明配置没生效，回头检查 YAML 缩进、环境加载顺序或是否被其他配置覆盖
Windows 用户额外注意：safe write（PHPStorm 默认开启）会导致文件“先写临时再替换”，Twig 监听不到变更；Docker 用户要确保 var/cache 是可写卷，且宿主机与容器时区一致，否则 filemtime() 判断出错，缓存误判未更新。
关掉之后的代价和替代方案
cache: false 意味着每次请求都重新解析、词法分析、语法树构建、生成 PHP 代码——性能明显下降，但换来的是“改保存即生效”的确定性。如果你只是调样式或局部逻辑，又不想太慢，可以折中：
- 用内存缓存代替磁盘：设
cache: 'array'（Twig 内置适配器），不写文件，但保留编译结果在内存中 - 保持
auto_reload: true（默认已开），确保文件变动能被检测到 - 不要依赖 IDE 的“自动刷新”提示，它只反映浏览器行为，和 Twig 缓存无关
真正容易被忽略的是：多人协作时，有人本地没关缓存，改完模板推上去，队友拉下来发现页面不对——因为对方机器还在读 var/cache/dev/twig/xxx.php。所以 cache: false 必须写死在版本控制里的配置中，而不是靠口头约定或文档提醒。
