symfony 3 关闭 twig 模板缓存必须在 twig.yaml（或 config_dev.yml）中显式配置 cache: false 和 auto_reload: true，仅设 app_env=dev 或 debug=true 无效；验证方式是确认 var/cache/dev/twig/ 目录不再生成任何 php 文件。
直接改 framework.yaml 不生效，必须去 twig.yaml
很多人以为关 Twig 模板缓存是改 framework.yaml 里的 cache 或 templating 配置，其实完全走错路。Symfony 3 的 Twig 缓存由独立的 twig 包控制，framework 层面的缓存配置（如 cache.app）只影响容器、HTTP 响应等，和 .twig 文件解析无关。
真正起作用的只有 config/packages/twig.yaml（或旧项目中的 app/config/config_dev.yml），且必须显式写死 cache: false：
twig:
cache: false
auto_reload: true
-
cache: false是 YAML 字面量 false，不是字符串"false"，也不是~或null -
auto_reload: true要保留（默认就是 true），否则即使关了缓存，Twig 也不会主动检查文件修改时间 - 如果用了多个 Twig 实例（比如邮件模板单独配了一个
email_twig），每个都要单独设cache: false
APP_ENV=dev 和 APP_DEBUG=true 只是前提，不是充分条件
仅靠设置 .env 文件里 APP_ENV=dev 和 APP_DEBUG=true，**不会自动关闭 Twig 缓存**。这是 Symfony 3 最容易踩的坑：debug 开启只影响 Profiler、错误页面、容器热加载，而 Twig 缓存引擎默认仍启用以提升开发时响应速度。
验证是否真走 dev 环境：
- 运行
php bin/console debug:container --parameter=kernel.environment，输出必须是dev - 检查
php bin/console debug:container --parameter=kernel.debug，输出必须是true - 二者缺一不可；若其中一项是
prod或false，哪怕配置写了cache: false，也会被环境层覆盖
验证缓存是否真关掉：看 var/cache/dev/twig/ 还写不写文件
最可靠的验证方式不是刷新页面看效果，而是盯住磁盘路径。关成功后，这个目录应该彻底“静默”：
- 手动删掉
var/cache/dev/twig/整个目录 - 改一个
.twig文件并保存 - 刷新页面，然后立刻检查该目录——如果里面**没生成任何新 PHP 文件**（比如
abc123.php），说明cache: false生效了 - 如果目录里又出现文件，说明配置没加载、被覆盖，或者路径权限问题导致写入失败（Windows 下杀毒软件常锁该目录）
注意：某些 IDE（如 PHPStorm）默认开启“safe write”，先写临时文件再原子替换，Twig 监听不到变更。可在 IDE 设置里关掉 “Use "safe write" (save changes to a temporary file first)”。
Docker 或 Windows 下容易被忽略的权限与时区陷阱
本地开发用 Docker 或 Windows 时，关缓存后仍不生效，大概率不是配置问题，而是底层 I/O 异常：
- Docker 中
var/cache必须挂为可写卷，且宿主机与容器 UID/GID 一致，否则file_put_contents()报Permission denied - Windows 下长路径（尤其嵌套深的
var/cache/dev/twig/...）可能触发系统限制，建议把项目放在短路径下（如C:\symfony\） - 宿主机和容器时区不一致会导致
filemtime()返回时间异常，Twig 误判模板“未更新”，从而跳过重解析——用date命令两边对比确认
真正麻烦的从来不是怎么关，而是关了之后没人检查它到底有没有停写。只要 var/cache/dev/twig/ 还在生成文件，就说明缓存还在跑，不管 debug 是开是关。
