必须显式配置twig: cache: false并清空var/cache/dev/twig/目录，否则cache:clear不清理twig编译缓存；验证需确认该目录不再生成新php文件。
直接执行 cache:clear 不一定能清掉 Twig 模板缓存
很多人以为运行 php bin/console cache:clear --env=dev 就万事大吉，结果改了 .twig 文件还是没反应。这是因为 Symfony 的 cache:clear 命令默认只清容器、路由、PHP OPcache 等系统级缓存，而 Twig 编译后的 PHP 文件（如 var/cache/dev/twig/abc123.php）可能仍在磁盘上被 autoload 加载——尤其当配置没生效或目录权限异常时。
-
cache:clear清的是var/cache/dev/下的整个结构，但 Twig 缓存文件可能因进程锁、杀毒软件拦截或 NFS 挂载延迟未被彻底删除 - 即使清掉了，只要
twig: cache配置仍是路径（比如'%kernel.cache_dir%/twig'），下次请求会立刻重建该目录和文件 - Windows 或 Docker 环境下，
var/cache/dev/twig/目录常被锁定，cache:clear执行成功但实际没删掉文件，表现为“清了又来”
twig: cache: false 必须写对，否则等于没关
禁用 Twig 模板缓存不是“清一次就完事”，而是靠配置驱动行为。关键在 config/packages/twig.yaml（Symfony 4+）或 app/config/config_dev.yml（Symfony 3）中显式声明：
- 必须写成
cache: false—— 这是 YAML 布尔字面量，不是字符串"false"，也不是~或null；写错就会 fallback 到默认路径，缓存照常工作 - 如果项目用了多个 Twig 实例（如
email_twig），每个都要单独配cache: false，否则只关了一个 - 检查是否有硬编码覆盖：比如在
src/Kernel.php或自定义服务定义里调用了$loader->setCache(...)，这种代码会直接无视 YAML 配置 - 验证是否生效：运行
php bin/console debug:config twig，确认输出中cache字段值确实是false，而不是一串路径
验证缓存是否真停写，盯住 var/cache/dev/twig/ 目录
页面变没变不重要，关键看这个目录还写不写文件。这才是最可靠的判断依据：
- 手动删掉
var/cache/dev/twig/整个目录（不要只清var/cache/dev/） - 访问一个使用该模板的路由（比如
/） - 立刻检查
var/cache/dev/twig/是否存在、是否生成了新*.php文件 - 再改一次
.twig并保存，重复访问 → 如果目录始终为空或只有旧残留，说明cache: false已生效 - 若目录持续冒出新文件，说明配置没加载（比如环境误设为
prod）、被其他 Bundle 覆盖，或 IDE “safe write” 导致filemtime()检测失效
开发时仍无效？先确认你真在 dev 环境跑
模板不更新，八成不是缓存问题，而是根本没进开发环境：
- 访问地址是不是
http://localhost:8000（server:run默认）？如果是http://localhost/app.php或 Nginx/Apache 直连根目录，大概率走的是prod环境 - 运行
php bin/console about，看Environment行是否为dev；或者在模板里加{{ dump(app.debug) }}，输出true才算到位 - 检查
web/app_dev.php是否被注释或删了安全头，导致自动跳转到app.php - 内置服务器要重启：
php bin/console server:stop && php bin/console server:start --env=dev，否则旧配置仍驻留在进程里
cache: false 是开关，var/cache/dev/twig/ 是证据，--env=dev 是前提。三者缺一，改十次模板都白搭。
