symfony 3 dev环境下，cache.app默认使用cache.adapter.array（内存缓存），不写文件；twig模板虽编译为php文件但自动检测源码变更；服务容器在debug=true时动态编译，仅配置变更时才重生成。
开发时频繁清缓存不是必须的，Symfony 3 的 dev 环境默认已禁用多数缓存写入——你看到的“清缓存”操作，其实大部分只是在重置内存状态或清理 Twig 编译文件，真正影响开发效率的，是容器编译缓存和 Doctrine 元数据缓存。直接关掉缓存配置反而会让问题更隐蔽。
dev 环境下哪些缓存本就不写文件
Symfony 3 在 APP_ENV=dev 且 debug=true 时，会主动绕过 PSR-6 文件落地逻辑：
-
cache.app默认绑定到cache.adapter.array，所有getItem()操作只存在内存里，save()不生成任何文件 - Twig 模板虽会编译成 PHP 文件（存于
var/cache/dev/twig/），但每次请求都会检查源文件修改时间，无需手动清 - 服务容器缓存（
Container.php）在 debug 模式下被设为“动态编译”，每次请求都可能重新生成，但仅当 config 或 bundle 变更时才触发
真正该关的不是缓存，而是元数据自动刷新
Doctrine 实体映射变更后响应慢，根源常是元数据缓存没及时失效。与其关缓存，不如让刷新更可控：
- 在
config/packages/doctrine.yaml中显式关闭元数据缓存驱动：metadata_cache_driver: { type: 'array' }（而非pool或apcu） - 确保
doctrine.orm.auto_generate_proxy_classes设为true（dev 环境默认已开） - 删掉
var/cache/dev/doctrine/orm/Proxies/目录可强制重建代理类，比全量cache:clear快得多
关掉 cache.adapter.filesystem 会导致测试失真
如果你在 cache.yaml 里强行把 cache.app 指向 cache.adapter.filesystem，又在 dev 环境下期望它“不生效”，就会陷入矛盾：
- 文件缓存适配器仍会尝试写入
var/cache/dev/pools/，但 Symfony 容器别名机制可能覆盖你的配置，导致行为不可预测 - 一旦你写了
$cache->getItem('user_123')->isHit()测试逻辑，本地跑通、上线却命中失败——因为 prod 环境用的是 Redis，而 dev 环境因路径权限或适配器未加载根本没写成功 - 更危险的是：某些 Bundle（如 FOSHttpCache）依赖缓存池存在，关掉后直接抛
ServiceNotFoundException
高频改代码时最省事的折中方案
不关缓存，但减少干扰项：
- 把
APP_DEBUG=0临时设为false（即关闭 debug），能跳过大量运行时检查，加快容器构建；但保留APP_ENV=dev以维持开发工具链 - 用
php bin/console cache:clear --no-warmup避免 warmup 步骤，尤其在只改了控制器或模板时 - 对 Doctrine 映射改动，优先执行
php bin/console doctrine:cache:clear-metadata，它比全量清缓更快、更精准 - 如果只是改了数据库内容想立刻看到效果，直接用
php bin/console doctrine:cache:clear-result清结果缓存，比清整个 cache 更安全
缓存机制本身没拖慢开发，拖慢的是我们对它的误判——比如以为关掉就能快，结果反而让环境差异变大、问题更难复现。真正要盯住的，是哪个环节在反复重编译、哪个缓存池实际被用了、哪次 clear 其实根本没必要。
