缓存标记在ThinkPHP 6.x中仅对File和开启useTags的Redis驱动有效，Memcached或未配置useTags时会静默失效；业务拆分应按数据变更源头粒度进行，并配合精准缓存失效与二级兜底策略。
缓存标记（Cache Tag）在 ThinkPHP 中实际是否可用？
ThinkPHP 6.x 官方文档提到的 cacheTag 功能，仅对 File 和 Redis 驱动生效，且 Redis 驱动需开启 useTags 配置；若用 Memcached 或未配置 useTags => true，调用 Cache::tag('user')->set() 会静默失败或退化为普通缓存，不报错也不生效。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确认缓存驱动：检查
config/cache.php中'default' => 'redis'，且对应redis配置里含'useTags' => true - 避免在 CLI 环境误用：命令行下
Cache::tag()可能因连接复用或上下文缺失导致标签失效 - 验证是否生效：用
Cache::has('user')查不到，但Cache::tag('user')->get('profile:123')能取到，说明标签写入成功；反之则需排查驱动配置
复杂业务逻辑该按什么粒度拆分？
不是“把一个方法切成三个函数”就算拆分。关键看数据依赖和变更频率：用户订单页要展示「余额 + 优惠券列表 + 待发货数 + 积分」，这四块数据更新节奏完全不同——余额每秒可能变动，积分每天凌晨结算，优惠券有有效期，待发货数只随物流状态变。强行共用一个缓存 key（如 user_dashboard_123）会导致缓存频繁击穿或脏读。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 按「变更源头」切分：余额 → 绑定支付回调事件；优惠券 → 绑定用户领券/过期定时任务；待发货数 → 监听订单状态机流转
- 缓存 key 命名带业务语义：用
balance:user:123、coupons:active:user:123，而非data_123_part1 - 读取时用
Cache::getMultiple()批量拉取，比串行get()减少 60%+ Redis 连接开销
缓存失效策略选 delete 还是 clear？
Cache::tag('order')->clear() 会清空该标签下所有 key，在高并发下单场景极易引发雪崩：一个订单状态更新，触发清除整个 order 标签，连带把其他用户的未支付订单缓存也干掉了。
更安全的做法是精准失效：
- 写操作后只删具体 key：
Cache::delete('order:status:456')，而不是清标签 - 读操作加二级兜底：查缓存无数据时，先加
Cache::lock('order:456:loading', 3)防穿透，再查库并回填 - 对无法精准定位的批量更新（如运营后台批量改优惠券），改用「缓存过期时间漂移」：原设 3600s，随机 ±300s，避免同时失效
为什么业务拆分后反而更慢了？
常见原因是拆分后引入了过多远程调用或同步等待。比如把「生成报表」拆成「查订单 → 查用户 → 查商品 → 拼装」四步，每步都走一次数据库查询，没合并 SQL，也没用协程或连接池，总耗时反超单次 JOIN 查询。
必须检查：
- 是否仍存在 N+1 查询：用
Db::getLastSql()看日志，确认关联字段是否用了with()预加载 - 拆分后的服务间通信是否走 HTTP：本地模块拆成独立微服务又没上 Swoole，HTTP 延迟直接吃掉性能优势
- 缓存 key 冲突：不同业务模块用了相同 tag 名（如都用
user），互相干扰失效
缓存标记和业务拆分不是银弹，它放大你原本的数据建模和调用链路问题。上线前务必用 Xhprof 或 think-swoole 的 trace 功能看真实耗时分布，而不是只盯着「代码拆开了」这个动作。
