Twig缓存冲突的典型现象是页面内容未变但刷新后仍显示旧数据，或修改index.html.twig后不生效，主因是缓存文件未更新、debug=false误配、目录权限异常或OPcache未忽略缓存路径。
Twig缓存冲突的典型现象
页面内容没变但刷新后显示旧数据，或修改了index.html.twig却始终不生效——这不是模板写错了，而是Twig缓存文件没被正确更新或校验。常见于开发环境误配debug=false、缓存目录权限不对、或OPcache未忽略缓存路径。
关闭Twig缓存的三种实操方式
不是删掉cache配置就等于关缓存，必须让Twig明确跳过编译和加载环节：
- 在
config/packages/twig.yaml中设cache: false（Symfony 3.4+支持） - 若用PHP方式初始化Twig（如命令行工具），直接传
['cache' => false]，避免路径误设为null或空字符串 - 强制清空缓存目录并设只读：运行
rm -rf var/cache/dev/twig后chmod 444 var/cache/dev/twig，Twig会因无法写入而退化为即时编译模式
为什么debug=true还不够
Symfony 3 的 Twig 默认在debug=true时启用auto_reload=true，但它仍会生成并复用缓存文件——只是每次渲染前多一次文件mtime比对。一旦模板路径被软链接、NFS挂载或容器卷权限异常，mtime可能不更新，导致“以为开了debug，其实缓存锁死”。
- 检查实际是否命中缓存：在
var/cache/dev/twig/下找对应模板的*.php文件，修改时间是否晚于.twig源文件 - 临时禁用OPcache对Twig缓存目录的覆盖：
opcache.file_cache_ignore_regex="/var/cache/dev/twig" - 确认
auto_reload真生效：在控制器里加dump($twig->isAutoReload());，输出true才算到位
生产环境别关，但得知道它在哪
关Twig缓存只应在调试阶段用。上线后必须开，否则每个请求都重新解析模板，CPU飙升。关键是理解它的落盘位置：var/cache/prod/twig/，且该目录由cache:warmup预生成——如果cache:warmup失败或被跳过，首次请求就会卡住编译，看起来像“缓存失效”，其实是根本没缓存可读。
