昨晚我差点破防，蘑菇视频的收藏与历史记录问题我终于定位到原因了
昨晚我差点破防，蘑菇视频的收藏与历史记录问题我终于定位到原因了
昨晚翻看用户反馈时，看到一条又一条关于“收藏突然消失”“历史记录乱序或为空”的举报，心里一阵凉。作为长期负责产品稳定性与用户体验的人，这类问题对用户信任的伤害非常直接——想想你辛辛苦苦收藏的视频不见了，谁能淡定？我把这次排查当成一次复盘，也把所有步骤和结论整理成这篇文章，方便同类问题参考，也让你在遇到类似状况时少走弯路。
一、问题表现（用户端）
- 收藏列表出现间歇性丢失，部分用户全部丢失、部分用户仅少量丢失。
- 历史记录会出现时间错乱、最新记录缺失或出现重复条目。
- 问题多在移动端（Android/iOS）和小程序端，但也有少数 PC 端用户反馈。
- 有用户反馈清空历史后再次登录历史反弹出现旧数据。
二、排查思路（我一晚上的步骤）
- 重现问题
- 在不同网络环境、不同设备、不同用户账号下复现（包括新用户与老用户）。
- 尝试触发条件：登录/登出、切换网络、清理缓存、App 升级前后、切换设备。
- 捕获网络与前端日志
- 用抓包工具（Fiddler/Charles/浏览器 DevTools）记录收藏与历史 API 的请求与响应。
- 前端加入临时调试埋点，记录操作时间、客户端版本、用户 ID、请求 payload、响应状态码。
- 检查后端日志与监控
- 查找对应时间段服务端的错误日志、超时、502/503 等异常。
- 检查 API 访问量、延迟、失败率是否有阶跃变化。
- 数据库与缓存核对
- 直接查询数据库中该用户的收藏与历史记录条目，确认数据是否仍存在或被篡改。
- 检查缓存（如 Redis）是否命中与过期策略是否与持久化不一致。
- 回溯代码与部署记录
- 回滚或对比最近一次发布变化，查看是否有与收藏/历史相关的接口更改、数据库迁移或 schema 修改。
- 查看第三方 SDK（统计、鉴权、加密、推送）是否有版本更新或问题公告。
三、锁定原因（核心发现） 通过上述排查，我把问题归结为三类并发与一致性导致的组合错误，最终定位到主因为“客户端与服务端对用户标识与本地持久化策略的不一致”——具体表现为：
- 多端登录/切换账号时，客户端在切换过程中没有做严格的本地数据隔离，导致本地缓存（localStorage/SQLite/SharedPreferences）存储的 userKey 与当前登录用户不一致，随后对错误 key 的缓存进行覆盖或删除，造成收藏/历史“丢失”或被别的账号数据覆盖。
- 服务端对历史与收藏的合并逻辑存在 race condition：当来自不同设备的同步请求几乎同时到达时（尤其在网络波动或重试机制下），后到的请求可能会误用旧的时间戳或错误的合并策略覆盖了更新的数据。
- Redis 缓存过期与持久化策略不一致：某些场景下，收藏/历史先被写入缓存但未及时落盘（db write failure 或异步队列积压），若缓存被淘汰或过期，而持久化任务执行又失败，则会导致短暂或永久的数据丢失。
- 第三方升级影响：部分用户在 App 升级后，旧版本地数据结构与新版不兼容，升级脚本没有正确迁移，导致本地展示异常，但真实服务端数据仍在。
四、如何修复（我和团队在生产环境做的改动）
- 客户端修正
- 在登录/登出/切换账号时，强制清理或隔离与用户相关的本地缓存。增加 user_id 前缀的 key 约定，并在用户切换时做原子替换。
- 增加本地数据迁移脚本：App 启动时检测旧版数据结构，按预期迁移或上报异常供运维处理。
- 对同步流程增加乐观合并策略：保留最近操作时间戳并校验，不允许用明显老旧的数据覆盖新数据。
- 服务端修正
- 将历史/收藏写入操作改为幂等接口，使用唯一操作 ID 或版本号，避免重试导致重复/覆盖。
- 修改合并逻辑，使用最后修改时间（server side authoritative）并在并发写入时引入轻量锁或 CAS（compare-and-set）机制。
- 增强持久化队列的监控与重试能力，确保缓存->数据库的落盘路径有告警与补偿机制。
- 数据修复与用户补偿
- 找出受影响用户（通过时间窗口与错误码筛选），对服务端保留的快照或备份进行恢复，并通过脚本回填。
- 对确实无法恢复的数据，配合客服做解释并适当发放补偿（会员天数/流量券/道具等），以维持用户信任。
五、预防与工程化建议（避免下次重演）
- 把用户相关的本地 key 设计为“user:{user_id}:{resource}”模式，切换用户时严格执行清理或命名空间隔离。
- 对所有会跨设备同步的行为，引入版本号与冲突合并策略；对非幂等操作实现唯一 idempotency_key。
- 严格监控同步相关的关键指标：同步失败率、重试次数、缓存未落盘率等，出现异常即触发 SRE 工单。
- 发布流程中把数据库迁移与客户端数据结构变更绑定到同一版本控制，先发布兼容层，后逐步弃用旧结构。
- 常态化做数据快照与恢复演练（DR 演练），保证在数据异常时能在最短时间内恢复。
六、复盘感想（个人观点） 这次问题的关键不是单一的 bug，而是系统级一致性缺口——多个看似正常的小设计（本地缓存策略、同步重试、合并逻辑）在复杂实际场景下叠加成了显性故障。作为产品与工程的交叉点，收藏和历史这类功能承载着用户信任，工程上必须把“数据一致性和用户预期”放在首位来设计。
如果你也在做内容类产品，建议把用户数据的“完整性测试”纳入回归测试与灰度发布流程，用户能直观感受到的数据更值得额外保护。
七、如果你需要帮助 我擅长定位这类跨端、跨层级的一致性与同步问题，从复现、日志、抓包、数据修复到工程化改进都有实战经验。需要我切入帮你做一次诊断或复盘，可以在网站留言或发邮件，我们约个时间把问题扯清楚、把方案落地。
结语：这次差点破防的经历让我更坚定：面向用户的每一个细节都不能掉以轻心。蘑菇视频的问题解决了，但系统的鲁棒性还要继续打磨。愿你的收藏永不失联，历史记录也能安静地记录每一次观看的痕迹。
