默认情况下Symfony 3在dev环境启用Twig缓存但不实时重编译，需设twig: cache: false和auto_reload: true才能实现修改即生效，否则必须清缓存；此举会增加5–20ms渲染延迟，仅适用于开发场景。
默认情况下，Symfony 3 在 dev 环境下会启用 Twig 缓存（编译后的 PHP 模板），但不会“实时重编译”——你改了 Twig 文件，必须清缓存才能生效。所谓“关闭模板缓存还原实时编译”，本质是让 Twig 每次都重新解析模板，跳过缓存检查。
为什么改了 Twig 文件没生效？
这不是 Bug，而是 Symfony 3 的预期行为：即使在 dev 环境，Twig 仍会将模板编译为 PHP 文件并缓存到 var/cache/dev/twig/。只要缓存存在且未过期，就不会重新编译。
- 常见现象：
php bin/console cache:clear --env=dev后页面才更新，热刷新失效 - 根本原因：
twig.cache_warmer服务预热了缓存；twig.loader.filesystem默认配合缓存使用 - 注意：仅设置
debug: true不足以触发每次重编译，它只影响错误提示和部分调试逻辑
如何强制 Twig 每次都重新编译？
关键不是“关闭缓存”，而是让 Twig 加载器绕过缓存路径，直接解析源文件并即时编译。最稳妥的方式是在 config_dev.yml 中覆盖 Twig 配置：
twig:
cache: false
auto_reload: true
strict_variables: true
-
cache: false—— 禁用写入缓存文件（不生成var/cache/dev/twig/*.php） -
auto_reload: true—— 启用自动检测源文件修改（即使cache: false也需显式开启） - 必须确保
kernel.debug为true（dev环境默认满足） - 不要设
cache: '%kernel.cache_dir%/twig'或类似路径，那仍是缓存模式
性能影响和开发场景取舍
禁用 Twig 缓存会带来可感知的渲染延迟，尤其含大量 include / macro / extends 的模板：
- 典型开销：单个模板多 5–20ms（取决于复杂度和文件系统速度）
- 仅建议用于快速原型、前端联调或 CI 中的轻量测试环境
- 若使用 NFS 共享卷（如 Docker for Mac），
auto_reload可能因 inotify 失效而降级为 stat 轮询，导致延迟更高 - 生产环境绝对不可设
cache: false；上线前务必确认prod环境使用的是cache: '%kernel.cache_dir%/twig'
验证是否生效的快捷方式
别只看页面效果，直接检查缓存目录和日志更可靠：
- 删掉
var/cache/dev/twig/目录，访问一次页面，再检查该目录是否仍为空 - 在 Twig 模板里加一行
{{ dump('recompiled at ' ~ now|date('H:i:s')) }}，刷新页面看时间是否变化 - 查看 Web Profiler 的 “Twig” 面板 → “Template information” → 若显示 “Compiled template: no” 即表示未缓存
真正麻烦的不是配置开关，而是团队成员各自改了 config_dev.yml 却没同步，或者误把 cache: false 提交到了 prod 分支。缓存开关本身很简单，但上下文隔离和环境一致性才是实际落地时最容易翻车的地方。
