symfony3开发环境需同时设置twig.debug: true和twig.cache: false才能真正禁用模板缓存，仅设cache: false无效；验证需检查x-debug-token响应头及修改twig后是否实时生效。
开发环境为什么不能关掉模板缓存就完事
Symfony3 默认在 dev 环境下启用模板缓存，但它的行为和你想象的“改完 Twig 就立刻生效”不完全一致——缓存文件生成后仍会读取已编译的 PHP 模板类，除非触发重建。单纯清缓存（php bin/console cache:clear）只是删文件，不解决“每次修改都要手动清”的低效问题。
真正关闭 Twig 模板缓存的两个关键配置项
必须同时调整以下两处，缺一不可，否则仍会命中缓存：
-
twig.debug设为true：启用 Twig 的调试模式，让模板错误带行号，也影响缓存策略 -
twig.cache设为false：直接禁用模板缓存，强制每次加载时重新编译
修改位置在 app/config/config_dev.yml 中的 twig 节点下：
twig:
debug: true
cache: false
注意：不要只改 cache: false 而漏掉 debug: true，否则 Twig 会回退到默认缓存行为（即使 cache 是 false），这是 Symfony3 的一个隐式依赖逻辑。
验证是否生效的快速方法
改完配置后，不用重启 Web 服务器，但要确认两点：
- 访问页面时，查看响应头中是否有
X-Debug-Token—— 有说明debug: true已生效 - 修改任意一个
.html.twig文件，刷新页面立即看到变化 —— 这是cache: false生效的直接证据 - 检查
var/cache/dev/twig/目录下是否仍有大量 PHP 文件持续生成（如xxx.php带时间戳）—— 如果几乎不新增，说明缓存没真关掉
容易被忽略的陷阱：环境变量与命令行缓存清理干扰
开发时常用 php bin/console cache:clear --env=dev，但如果终端里设置了 APP_ENV 或 SF_ENV 环境变量，实际运行的可能不是 dev 环境。最稳妥的方式是显式指定：
APP_ENV=dev php bin/console cache:clear
另外，如果用了 --no-warmup 参数，Twig 编译器不会预热，但首次访问仍会慢；而完全禁用缓存后，warmup 本身已无意义，可省略。
真正麻烦的是：某些 IDE 插件或 Docker 容器内挂载方式导致 var/cache 目录权限异常或文件未同步，这时即使配置全对，也会“看似没生效”。建议先 ls -l var/cache/dev/twig 看写入时间是否随请求更新。
