必须在Twig配置中显式设置cache: false，而非仅设debug: true；config_dev.yml中应写为cache: false（布尔值），不可用字符串，并需验证缓存目录无新文件生成。
关 Twig 模板缓存，不能只改 debug: true，必须在 Twig 配置里写死 cache: false——否则你改了 .twig 文件，页面照样不更新。
config.yml 里怎么写才真正禁用 Twig 缓存
Symfony 3 的 config.yml（或更推荐的 config_dev.yml）中，Twig 缓存由 twig.cache 控制。它不是开关，而是一个路径值；设成 null、~ 或留空，都会 fallback 到默认缓存目录（如 var/cache/dev/twig/），等于没关。
- 正确写法是显式设为 YAML 布尔字面量：
cache: false - 不要写成字符串：
cache: "false"或cache: 'false'—— 这会被当路径解析，可能创建名为false的子目录 - 若用了多 Twig 实例（如邮件模板单独配了
email_twig），每个实例的cache都得单独设false - 配置位置建议放在
app/config/config_dev.yml，避免污染 prod 环境
为什么 APP_DEBUG=true 不够用
Symfony 的 debug 开关影响的是 Profiler、错误页面、容器热加载等，但 Twig 引擎自身的缓存策略是独立控制的。dev 环境下默认仍启用编译缓存以提升响应速度，debug: true 只是让报错更友好，不等于“不缓存模板”。
- 典型现象：改完
base.html.twig，刷新页面没变化，var/cache/dev/twig/下却有新 PHP 文件生成 → 说明缓存还在工作 -
cache: false会让 Twig 每次请求都重新解析源文件，跳过编译缓存环节 - 副作用是请求变慢（尤其模板多时），但开发调试阶段值得换这个确定性
验证是否真的关掉了
别信配置写了就生效。动手验证比看文档更可靠：
- 删掉
var/cache/dev/twig/整个目录（确保它被清空） - 改一个模板文件并保存
- 刷新页面，再检查
var/cache/dev/twig/是否有新文件生成 → 没有，说明cache: false生效了 - 注意 IDE “safe write” 干扰：PHPStorm 默认先写临时文件再替换，Twig 可能监听不到变更，需在 Settings → System Settings → Use “safe write” 中关闭
- Docker 环境下还要确认
var/cache是可写卷，且宿主机与容器时区一致，否则filemtime()判断会出错
协作和 CI 中容易漏掉的关键点
单人本地调通不等于团队一致。多人开发时，最麻烦的是“别人机器上缓存没关”，你改了模板他看不到效果。
- 必须把
cache: false写死在版本控制的配置文件里（如config_dev.yml），不能靠口头约定或本地.env覆盖 - CI 流水线应断言：
php bin/console debug:container --parameter=twig.options | grep '"cache":false' - 同时验证 HTTP 响应头是否含
Last-Modified：它代表 Twig 正在监听文件变更，是auto_reload: true+cache: false共同作用的结果 - 别忽略
auto_reload: true—— 它默认开启，但如果被其他 bundle 覆盖或误配为false，即使cache: false也没用
真正卡住人的从来不是“怎么配”，而是有人改了模板却不知道队友的 var/cache/dev/twig/abc123.php 还在运行旧逻辑。把 cache: false 钉死在 config 里，再加一条 CI 检查，比每次问“你清缓存了吗”省心得多。
