核心不是缓存坏了，而是缓存与数据库更新节奏未对齐；symfony 3 默认关闭doctrine二级缓存，需显式启用并配置region_cache_driver及@orm\cache注解，否则所谓失效实为查询缓存或结果缓存问题。
缓存失效导致数据不一致，核心不是“缓存坏了”，而是缓存与数据库的更新节奏没对齐。Symfony 3 默认使用 Doctrine 的二级缓存（如 APCu、Redis）时，若未配合正确的缓存失效策略，很容易读到旧数据。
确认是否真用了二级缓存
Doctrine 二级缓存默认是关闭的，必须显式启用。检查 doctrine.yaml 是否配置了：
second_level_cache: enabled: true- 指定了
region_cache_driver（如pool: doctrine.second_level_cache.providers.redis_pool） - 实体类加了注解：
@ORM\Cache(usage="READ_WRITE")或更严格的"NONSTRICT_READ_WRITE"
如果没开二级缓存，所谓“模型缓存失效”实际是查询缓存（Query Cache）或结果缓存（Result Cache）的问题，处理方式完全不同。
查清缓存失效发生在哪一层
Symfony 3 中常见的三类缓存可能干扰数据一致性：
- 查询缓存（Query Cache）：缓存的是 SQL 文本 → 结果集映射关系。更新实体后若没清掉对应查询缓存，会返回旧结果。
-
结果缓存（Result Cache）：缓存的是最终对象数组。需手动调用
$em->getCache()->evictEntityRegion(...)或设置 TTL。 -
实体缓存（Second Level Cache）：缓存的是单个实体序列化数据。依赖
@ORM\Cache注解 + 正确的 region 配置，更新时 Doctrine 会自动失效关联 region —— 但前提是 update/delete 操作走的是 EntityManager 的标准方法（如$em->persist()+$em->flush()），而非原生 SQL 或批量 DQL。
修复数据不一致的实操步骤
不要直接清空全部缓存，先定位问题范围：
- 对出问题的实体，执行
$em->getCache()->evictEntityRegion(YourEntity::class)立即清除该类型所有缓存项 - 如果是特定 ID 数据不准，用
$em->getCache()->evictEntity(YourEntity::class, $id) - 若用 Redis 作缓存后端，可临时在 Redis CLI 中执行
KEYS *your_entity*查看缓存 key 格式，针对性 DEL - 确保所有写操作都经过 EntityManager：避免绕过 ORM 直接执行
$conn->executeStatement()，否则二级缓存完全无法感知
预防下次再发生
靠人工清缓存不可持续。推荐两个轻量级加固方式：
- 在 Repository 的
save()和remove()方法末尾，自动触发对应缓存清理（可用事件监听器postPersist/postUpdate） - 对高一致性要求的场景（如用户资料、订单状态），干脆禁用该实体的二级缓存，改用短 TTL 的结果缓存 + 显式控制失效逻辑
- 升级时注意：Symfony 3.4+ 和 Doctrine 2.7 开始支持更细粒度的缓存 region 管理，可为不同业务模块划分独立 region，避免互相污染
