我真没想到，蘑菇视频下载的推荐内容问题我终于定位到原因了

蘑菇视频242026-05-12 00:43:01

前几天我碰到一个很让人抓狂的问题：用户反馈蘑菇视频下载里推荐内容“千篇一律”、或者明明做了个性化设置却一直推老内容。刚开始以为是算法模型出了锅，或者是用户画像数据丢失，结果折腾半天定位到了一个出乎意料的地方——边缘缓存（CDN/反向代理）配置把个性化的推荐接口内容当成了可缓存的静态资源，导致大量用户拿到同一份“过时”的推荐列表。

下面把我排查的思路、如何确认根因、整改步骤和后续预防措施整理出来，供遇到类似问题的同学参考。

问题描述（用户角度）

推荐内容重复率高，个性化程度低；
部分用户看到的推荐与其账号/设备行为明显不符；
问题在短时间内广泛出现，但并非所有用户同时受影响；
回滚前的老版本没有这个现象，新版本上线后开始出现。

排查思路与定位步骤 1) 复现并收集证据

在不同账号、不同设备与网络环境下重复访问推荐接口，记录返回的recommendation payload、HTTP响应头、状态码。
在浏览器或抓包工具中观察请求里的授权头（Authorization / Cookie / X-User-Id）是否随请求发送并被服务器正确消费。

2) 对比日志与请求

查后端日志，看请求是否到达推荐服务，是否为缓存命中（看是否从cache层返回）。
在网关/边缘层（如Nginx、CDN）开启调试日志，检查是否存在大量“cache hit”且命中的是同一response id。

3) 检查响应头和缓存策略

关注Cache-Control、Expires、ETag、Vary等头部，看看推荐接口是否带上了“no-cache”或“private”。
用curl带上不同用户token尝试请求，查看返回是否相同，以及响应头中是否带X-Cache、X-Cache-Hit等字段。

4) 排查最近变更

回顾最近的部署/配置变更：CDN规则、网关配置、反向代理模板、或是引入了新的第三方中间层（例如A/B测试代理、流量采集中间件）。
特别留意对“缓存键”或“缓存策略”做的任何自动化改动（例如为了降低压力，把所有非静态接口统一设置了长缓存）。

最终发现的根因（摘要）

推荐接口属于高度个性化的动态内容，但在某次部署/CDN规则调整后，边缘层把该接口当成可缓存资源处理。
缓存Key没有包含用户标识或Authorization，缓存策略TTL被设置得过长，且缺少正确的Vary头，导致一个用户的推荐结果被大量复用到其他用户上。
结果出现“某段时间内大量用户看到同一份推荐列表”的现象，表现为个性化失效或推荐陈旧。

解决方案（应急+长期）应急措施（立即可做）

立刻把有问题的推荐接口从CDN缓存策略中移除（设置Cache-Control: no-cache, no-store 或在CDN规则里排除该路径）。
如果CDN支持，执行即时缓存清理/刷新（purge），以把错误的缓存条目清掉。
回滚最近对边缘或网关的配置变更（如果按变更序列能快速回退）。

根本修复（后续发布）

明确哪些接口是动态且个性化的，统一标记为不可缓存或采用短TTL + 缓存分片策略。
在必须缓存的动态内容上，设计合理的缓存Key：把用户ID、地区或其他会影响返回内容的请求头包含进Key，或者采用Edge-Side Include（ESI）把静态与动态片段拆开缓存。
使用Vary响应头（例如 Vary: Authorization, Cookie, Accept-Language）在支持的场景下避免误缓存。
若使用第三方CDN，配置缓存规则时把“含有认证信息”的请求路径排除或者使用不同的缓存键策略。
在后端增加缓存透明度：每次响应加入X-Cache、X-Cache-Key等调试头，便于定位。

验证与监控

修复后用脚本批量模拟多账号并发请求，确认不同用户拿到不同推荐结果，且响应头显示为miss或正确的缓存策略。
建立自动化监控指标：推荐结果相似度（对比不同用户返回的一致率）、缓存命中率、CTR/播放率突变告警。
把关键HTTP头变更纳入CI检查，例如由静态检测器校验不能对“/recommend”类接口打上长期缓存。

预防机制（避免重蹈覆辙）

部署前的配置校验清单：所有接口的缓存策略需人工或自动审核，动态接口默认禁缓存。
在灰度/预发布环境里复现边缘缓存行为，确保在生产环境规则生效前能捕捉到错误。
把缓存规则作为基础平台能力的透明文档，供产品/算法同学在设计时参考。
定期做“异步全站抓取”测试，从不同网络节点模拟用户请求，检测是否有异常缓存下发。

一些实际的调试命令示例（便于快速验证）

查看响应头（Linux/macOS）： curl -I -H "Authorization: Bearer " https://api.example.com/recommend curl -I -H "Authorization: Bearer " https://api.example.com/recommend 对比返回的 Cache-Control、Vary、X-Cache 等字段。
模拟不同用户拿到相同body： curl -s -H "Authorization: Bearer " https://api.example.com/recommend | md5sum curl -s -H "Authorization: Bearer " https://api.example.com/recommend | md5sum

结语从一开始怀疑模型，再到看日志、抓包、比对，最后把问题锁定在CDN/缓存策略上，整个过程既郁闷又有成就感。很多时候，推荐问题并不单纯是算法错了，而是系统工程层面的细节（缓存、Header、代理规则）把个性化给“抹平”了。希望把这个排查过程和解决思路分享出来，能帮到正在折腾推荐问题的同学。如果你也遇到类似现象，可以把关键响应头和部分请求样例贴出来，我们可以一起看看到底是哪里被缓存住了。