必须在 twig.yaml 中显式设 cache: false，因为 APP_DEBUG=true 或 APP_ENV=dev 仅影响错误提示和Profiler等，不控制 Twig 编译缓存；Twig 默认在 dev 环境仍启用文件缓存，将 .twig 编译为 PHP 存于 var/cache/dev/twig/ 下，导致修改模板后页面无变化。
必须在 twig.yaml 中显式设 cache: false，仅靠 APP_DEBUG=true 或 APP_ENV=dev 无法真正关闭 Twig 模板缓存。
为什么 debug=true 还是会缓存模板
Symfony 的 debug 开关只影响错误提示、Profiler、容器热加载等机制，和 Twig 自身的编译缓存无关。Twig 默认在 dev 环境下仍启用文件缓存，把 .twig 编译成 PHP 存在 var/cache/dev/twig/ 下——你改了模板却没生效，大概率就是这个目录里的旧文件还在被加载。
常见错误现象包括：
- 刷新页面无变化，即使已保存修改
-
var/cache/dev/twig/目录持续有新 PHP 文件生成 - 清过
cache:clear后短暂生效，但下次请求又恢复旧内容
怎么正确关闭 Twig 模板缓存
在 config/packages/twig.yaml 中强制写死 cache: false，不要留空、不要注释、不要设为 null 或字符串 "false"：
twig: cache: false # 其他配置保持不变
这个值会被 Symfony 解析为布尔 false，从而禁用整个缓存引擎。若使用了多个 Twig 实例（如独立配了 email_twig），每个都要单独加这一行。
关键验证点：
- 删掉
var/cache/dev/twig/目录后重启请求，该目录不应再出现新文件 - 检查
php bin/console debug:container --parameter=twig.options输出中cache值是否为false（不是路径或null） - 确保
auto_reload: true已启用（默认开启，但若手动覆盖了twig.options可能被冲掉）
容易被忽略的环境与权限陷阱
即使配置写对了，以下情况仍会导致缓存“看似没关掉”：
- Windows 下杀毒软件或 IDE（如 PHPStorm）锁住
var/cache/dev/twig/目录，导致file_put_contents()失败，Twig 回退到内存缓存（ArrayCache），行为不可预测 - Docker 容器中
var/cache卷未设为可写，或宿主机与容器时区不一致，使filemtime()判断出错，误认为模板未更新 - IDE 启用了“safe write”，保存时先写临时文件再原子替换，Twig 的文件监听机制可能错过变更事件
- 某些部署脚本或 CI 流程中执行了
cache:warmup，它会无视cache: false强行预编译模板——开发机上应避免运行此命令
关掉之后要注意什么
cache: false 后每次请求都会重新解析并编译所有 .twig 文件，启动耗时明显上升，但换来的是改保存即生效——这对调试逻辑、语法、继承结构非常关键。别试图用“部分缓存”折中，Twig 没提供细粒度开关；真要兼顾性能，可考虑把缓存适配器换成内存型（如 ArrayAdapter），但这仍属于缓存，不是“实时重载”。最稳妥的做法，就是接受开发期的这点延迟，把 cache: false 写死、验证、纳入团队规范。
