必须写死cache: false，不能注释或留空；需同时启用auto_reload: true和debug: true；验证方式是删除var/cache/dev/twig/后观察是否再生文件。
app_dev.yml里必须写死cache: false，不是注释掉也不是留空
很多人以为把cache配置项注释掉或设成~就等于关闭，其实 Symfony 会 fallback 到默认路径（比如%kernel.cache_dir%/twig），结果缓存照常工作。真正生效的写法只有一种：cache: false（YAML 布尔字面量，不是字符串）。这个值会被 Twig 引擎识别为“禁用缓存”，跳过所有文件写入逻辑。
常见错误包括：
- 写成
cache: "false"（带引号 → 字符串 → 被当成路径，尝试创建名为false的目录） - 写成
cache: null或cache:（空值 → 合并为默认路径） - 只改了
config/packages/twig.yaml却没注意 Symfony 3 默认加载的是app/config/config_dev.yml，后者优先级更高
同时确认auto_reload: true且debug: true已启用
auto_reload: true是 Twig 检测模板文件变更的开关。即使cache: false，如果它被关掉，Twig 就不会调用filemtime()比对修改时间，改完保存也无响应。Symfony 3 dev 配置中默认开启，但若被覆盖（比如在config_dev.yml里重复定义 twig 配置块却漏写了这一项），就会失效。
还要检查两个环境变量是否真实生效：
-
.env中APP_ENV=dev且APP_DEBUG=true - 命令行启动时显式指定
--env=dev，例如php bin/console server:run --env=dev - 别信 IDE 自带的 PHP 内置服务器——它不读
.env，容易 fallback 到prod
验证是否真关掉了：看var/cache/dev/twig/还写不写文件
最直接的验证方式不是刷页面看效果，而是盯住文件系统：
- 手动删掉
var/cache/dev/twig/整个目录 - 改一个
.twig文件并保存 - 刷新页面，观察该目录是否重新生成 PHP 文件
如果目录保持为空，说明cache: false生效；如果出现新文件（比如abc123.php），说明配置没打到真正的 Twig 实例上，或者有多个 Twig 环境（如邮件专用的email_twig）没同步关掉。
Windows 用户额外注意：safe write功能（PHPStorm 默认开启）会导致保存时先写临时文件再原子替换，Twig 可能监听不到变更。关掉 IDE 的「safe write」选项可解决。
Docker 或 CI 中必须断言twig.options.cache === false
本地配对了不等于团队一致。CI 脚本里加一行检查能防很多扯皮：
php bin/console debug:container --parameter=twig.options | grep '"cache" => false'
更进一步，可以请求一个带模板渲染的路由（如/_profiler），检查响应头是否有Last-Modified：
curl -s -I http://localhost:8000/_profiler | grep Last-Modified
这个头存在，说明 Twig 正在监听文件变更；缺失则大概率缓存未禁用或auto_reload被关了。Docker 容器里还要确认var/cache挂载卷可写、宿主机与容器时区一致——否则filemtime()返回时间戳错乱，缓存判断失效。
真正难缠的从来不是配置本身，而是有人改了base.html.twig后，在自己机器上刷出新内容，就以为“没问题了”，却不知道队友的var/cache/dev/twig/里还躺着三天前的编译结果。
