必须显式配置cache: false（YAML布尔字面量）并确保auto_reload: true，否则dev环境下Twig仍会启用编译缓存；需清除缓存、验证目录无新增PHP文件，并确认运行在dev环境。
twig.yaml 里必须写 cache: false，不是留空也不是注释掉
很多人以为设了 APP_DEBUG=true 就自动关缓存，其实 Twig 在 dev 环境下默认仍启用文件级编译缓存。真正起效的只有显式配置 cache: false —— 注意是 YAML 的布尔字面量 false，不是字符串 "false" 或 null。
在 config/packages/twig.yaml 中修改或添加：
twig:
cache: false
这个值会覆盖所有环境判断逻辑，强制禁用缓存引擎。如果该行被注释、写成 cache: ~ 或指向一个目录（比如 cache: '%kernel.cache_dir%/twig'），缓存依然会写入。
确认 auto_reload: true 已启用，否则改了文件也不触发重解析
auto_reload 控制 Twig 是否每次请求前检查 .twig 文件的修改时间。它和 cache 是两个独立开关：关了缓存但没开 auto_reload，Twig 会跳过文件读取直接返回空内容或报错；开了 auto_reload 却没关 cache，则改完仍可能从旧编译 PHP 文件里读。
检查是否已启用（默认是 true，但建议显式写出）：
twig:
cache: false
auto_reload: true
- 若使用
config_dev.yml而非twig.yaml，同样要在对应位置写死这两项 - Windows 下注意杀毒软件可能锁定
var/cache/dev/twig/目录，导致file_put_contents()报Permission denied，此时即使配置正确也表现像“没生效”
验证缓存是否真停写：盯住 var/cache/dev/twig/ 目录
关缓存后，这个目录下不应再生成任何 PHP 文件。改一个 .twig 模板并保存，刷新页面，然后立刻执行：
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
ls -la var/cache/dev/twig/
如果输出为空，或只有一两个残留旧文件（无新增），说明配置生效；如果持续有哈希命名的 *.php 文件出现，说明 cache: false 没被加载，或者被其他配置覆盖（比如某 bundle 的 twig 扩展强行重写了 service）。
常见干扰点：
- 多个 twig 配置文件共存（如
twig.yaml和framework.yaml里都配了 twig）→ 以最后加载的为准 - Docker 容器内挂载了宿主机
var/cache，但权限不一致，导致写失败却无报错 - 某些 IDE 自动保存时带临时文件锁，Twig 读取到空内容后 fallback 到内存缓存
别信“改完就生效”，先清一次缓存再测
即使配置正确，旧的编译文件仍可能被 PHP opcode 缓存（如 OPCache）或 Symfony 容器缓存间接引用。首次启用 cache: false 后，务必执行：
php bin/console cache:clear --env=dev
而不是只刷新浏览器。否则你看到的“没变化”，很可能是 PHP 还在执行上一轮缓存下来的 abc123.php。
更隐蔽的问题是：某些开发服务器（如 server:run）启动时未指定 --env=dev，实际跑在 prod 模式下，此时 cache: false 根本不加载——所以一定要确认 APP_ENV=dev 在 .env 里且没被运行时覆盖。
