必须显式配置cache: false才能真正关闭Twig模板缓存，仅设APP_ENV=dev和APP_DEBUG=true无效；需在config_dev.yml中写死该配置，并确保auto_reload: true启用，否则修改模板不生效。
cache: false 必须写死在 config_dev.yml 里
仅靠 APP_ENV=dev 和 APP_DEBUG=true 不会真正禁用 Twig 缓存。Symfony 3 的 Twig 默认行为是：即使在 dev 环境，只要 cache 配置项没显式设为 false，它就会往 var/cache/dev/twig/ 写编译后的 PHP 文件。你改了 .twig 文件却没生效，八成是这个配置漏了。
实操建议：
- 打开
app/config/config_dev.yml（不是config/packages/twig.yaml，Symfony 3 主要用前者） - 找到
twig:下的cache:行，确保它被设为 YAML 字面量false，不是字符串"false"，也不是注释掉或留空 - 正确写法：
cache: false；错误写法：cache: "false"、# cache: ~、cache: "%kernel.cache_dir%/twig"
auto_reload: true 是前提，否则改了也不检测
cache: false 只让 Twig 不写缓存文件，但不等于它会自动感知文件变化。如果 auto_reload 关了，Twig 会把模板内容“记”在内存里，后续请求直接复用——你保存了 base.html.twig，页面还是旧的。
实操建议：
- 确认
auto_reload: true已启用（Symfony 3 dev 默认开启，但某些自定义 loader 或手动构造Environment时可能覆盖） - 不要在代码里手动 new Twig\Environment 并漏传
'auto_reload' => true - 验证方式：改一个模板后刷新，再用
ls -l var/cache/dev/twig/看目录是否为空且无新增文件；同时检查响应头是否有Last-Modified
var/cache/dev/twig/ 还有文件？说明 cache 没关成功
关闭成功的标志是：该目录完全不生成任何 PHP 文件。如果它存在且里面有 abc123.php 这类哈希命名的文件，说明 cache 配置没生效，或者被其他配置覆盖了（比如 bundle 的默认值、环境变量注入、或 config.yml 中更靠前的 twig 配置）。
常见干扰点：
- Docker 容器内挂载了宿主机的
var/cache，导致本地改配置但容器仍读旧缓存路径 - 某些 IDE 插件（如 PHPStorm 的 Symfony 插件）会主动 warmup 缓存，绕过你的
cache: false -
php bin/console cache:warmup --env=dev会强制重建缓存，哪怕你配了cache: false—— 这个命令本身就不该在 dev 环境跑
Windows 下 file_put_contents(): Permission denied 是权限锁，不是配置错
看到这个错误，别急着改 YAML。它通常意味着 Windows 杀毒软件、OneDrive 或文件资源管理器把 var/cache/dev/twig/ 目录锁死了，Twig 尝试写缓存失败，但又没 fallback 到 cache: false 路径逻辑，于是报错并中断渲染。
解决路径很窄：
- 先确认
cache: false已写对，再临时退出杀软/OneDrive 同步 - 用管理员权限启动终端执行
php bin/console cache:clear --env=dev，清空整个 cache 目录再试 - 终极办法：把
var/目录移到非 OneDrive 同步路径下（比如C:\symfony-app\var\），避免系统级文件监控干扰
真正麻烦的是缓存策略没被所有人看见——有人本地开着 cache: "%kernel.cache_dir%/twig"，CI 却跑在 clean 环境里，结果测试通过、上线炸锅。把 cache: false 写进版本库，比教十遍“记得清缓存”管用。
