必须显式配置 twig: cache: false 才能彻底禁用 twig 模板缓存；debug=true 或 app_env=dev 不影响 twig 缓存逻辑，auto_reload: true 需同时保留，验证需检查缓存目录是否再生文件及 twig.options 参数值。
改了 Twig 模板却没变化？不是缓存没清，而是 Twig 缓存根本没关掉——debug=true 不等于模板不缓存，必须显式设 cache: false 才生效。
为什么 APP_ENV=dev 还要手动关 cache
Symfony 3 的 debug 控制的是 Profiler、错误页面、容器热加载，和 Twig 缓存是两套逻辑。默认 dev 下 Twig 仍会把 base.html.twig 编译成 PHP 文件写进 var/cache/dev/twig/，你保存后它直接读缓存，根本不解析新内容。
-
cache: false是唯一能彻底禁用 Twig 编译缓存的配置；设成null、~或留空，Symfony 都会 fallback 到默认路径（比如%kernel.cache_dir%/twig） - Windows 下还要注意杀毒软件或 IDE “安全写入”可能让
filemtime()获取不到变更时间，导致auto_reload: true失效 - 如果用了 Docker，确保
var/cache是可写卷，且宿主机与容器时区一致，否则文件修改时间判断错乱
怎么在 config 中真正关掉 Twig 缓存
不要动 config_dev.yml 里已废弃的旧结构；Symfony 3.4+ 推荐统一在 config/packages/twig.yaml 中配置：
twig: cache: false auto_reload: true
-
cache: false必须是 YAML 字面量false，不是字符串"false"，否则会被当路径处理 -
auto_reload: true要显式保留（虽然 dev 默认开启），避免被其他配置覆盖 - 若项目有多个 Twig 实例（如 email 渲染单独配了
email_twig），每个都要单独加cache: false
验证关没关成功：别靠“感觉”，看文件和响应头
删掉 var/cache/dev/twig/ 目录，改一个模板，刷新页面——如果目录里又生成了新 PHP 文件（比如 abc123.php），说明没关成功。
- 用
php bin/console debug:container --parameter=twig.options查输出中cache值是否为false（不是null，也不是一串路径） - 访问任意带 Twig 渲染的路由（如
/_profiler），用curl -I http://localhost:8000/_profiler | grep Last-Modified；有Last-Modified头才说明 Twig 正在监听文件变更 - CI 流水线里必须加这两条断言，不能只信本地配置
关掉之后性能变慢，但调试更可靠
每次请求都重新解析 .twig 文件，确实比读缓存慢——这是代价，也是目的。开发阶段你要的是“改完保存即见效果”，不是“快但不确定是否真生效”。
- 启动变慢是正常现象，不用优化；上线前切回 prod 环境自然恢复编译缓存
- 如果实在卡顿，可折中用内存缓存适配器：
cache: 'cache.adapter.array'，不写磁盘但也不持久 - 最麻烦的不是慢，是有人改了
layout.html.twig却不知道队友的机器还在读var/cache/dev/twig/xxx.php—— 所以cache: false必须写死在版本库配置里，不能靠口头约定
