要真正禁用 twig 模板的文件写入，必须在 twig.yaml 中显式设置 cache: false；因为 twig 编译缓存独立于 symfony 的 cache.app 配置，不依赖 psr-6 缓存适配器，设 cache.adapter.null 或修改 cache.app 均无效。
cache.adapter.filesystem 配置后模板仍写入文件？
不是配置没生效，而是 Symfony 3 的模板缓存（Twig）默认走的是 cache.adapter.apcu 或 cache.adapter.array，和你配的 cache.app 完全无关。改 framework.cache.app 不会影响 Twig 编译后的模板缓存路径或行为。
怎么真正禁用 Twig 模板的文件写入？
Twig 模板缓存由 twig.options.cache 控制，它决定是否把编译后的 PHP 模板写到 var/cache/{env}/twig/ 下。要关闭写入，必须显式设为 false，不能靠关掉其他缓存适配器来间接实现：
-
config/packages/twig.yaml中设置cache: false - 若用的是环境级配置（如
config/packages/dev/twig.yaml），确保该文件被加载且未被 prod 配置覆盖 - 设为
false后，Twig 每次都会重新解析模板，不生成 .php 文件 —— 这对开发调试安全，但会明显拖慢响应，仅建议在极少数调试场景下临时启用
为什么设了 cache.app: cache.adapter.null 也没用？
因为 cache.adapter.null 只影响 PSR-6 兼容的通用缓存服务（比如 cache.app、cache.system），而 Twig 编译缓存是独立路径、独立生命周期的机制，它根本不调用 CacheInterface，也不经过 cache.provider.filesystem 这类 provider。
常见误操作包括：
- 在
cache.yaml里把app改成cache.adapter.null，以为能“一并关掉所有缓存写入” - 清空
var/cache/dev/twig/后发现重启服务又自动重建 —— 这恰恰说明twig.cache是开启的，和你配的cache.app无关 - 试图用
php bin/console cache:clear清掉 Twig 缓存 —— 它只清var/cache/dev/下的容器和元数据，twig/子目录默认不受影响（除非加--no-warmup并手动删）
生产环境千万别关 Twig 缓存
哪怕你成功设了 cache: false，上线后每次请求都要重编译 Twig 模板，CPU 和 I/O 开销陡增，500 错误风险直线上升。真正该做的是：让模板缓存写入保持启用，但确保 var/cache 可写、权限正确、不被 Git 提交；同时用 composer install --no-dev --optimize-autoloader 配合 php bin/console cache:warmup --env=prod 预热，这才是稳定做法。
