突然出现了新入口：蘑菇视频电脑版：关于缓存路径的说法：我把过程完整复盘了一遍！有人说是测试，有人说是回滚

突然出现了新入口：蘑菇视频电脑版：关于缓存路径的说法：我把过程完整复盘了一遍！

前言 最近很多人发现蘑菇视频电脑版桌面端无预警地“冒出”了一个新入口（像是主界面、右键菜单或系统托盘的入口），与此同时关于“缓存路径变动”的讨论在群里和评论区炸开了锅。有的说这是开发在做A/B测试；有的说这是一次回滚导致的临时表现。为了解开这些疑问，我把整个过程从环境准备、抓包、文件监控到复原操作都完整复盘了一遍。下面把可复现的步骤、我看到的证据、以及对“测试/回滚”两种解释的技术判断整理成一篇，供大家参考。

我的测试环境与前提

• 操作系统：Windows 10 专业版（x64），更新至 2024 年上半年的补丁。
• 蘑菇视频电脑版为最新用户端（测试前后的版本号我都记录并对比）。
• 使用的工具：Process Explorer、Procmon（Sysinternals）、Wireshark、Fiddler（抓HTTPS需安装根证书，注意安全）、PowerShell、Resource Monitor、文件比较工具（WinMerge）及文本编辑器。
• 测试目标：定位该新入口启动时访问的缓存路径、判断是否为本地改动还是远端控制、以及找出能辨别“测试”和“回滚”的可验证证据。

复盘步骤（可复现） 1) 记录基线：先在未出现入口前记录客户端版本号、安装路径、AppData 下相关目录（%APPDATA%、%LOCALAPPDATA%），保存快照。 2) 触发新入口出现：按用户报告的操作（重启客户端、退出重启、开机登录或点击某些模块），并在操作同时启动 Procmon，过滤进程名为蘑菇视频的可执行文件（例如 mogo.exe，具体以实际进程名为准）。Procmon 记录文件/注册表/网络行为。 3) 捕获网络流量：用 Fiddler/ Wireshark 观察客户端向哪些域名发起请求，是否有请求远端配置（config.json、feature flags、ABTest 接口等）。如果是 HTTPS，需要通过受信任证书来解密流量（仅在受控测试环境中进行）。 4) 检查打开的文件句柄：用 Process Explorer 或 handle.exe（Sysinternals）查看进程当前打开的文件路径及句柄，寻找明显的 cache、temp、profile、userData 等目录名。 5) 搜索磁盘：在 %LOCALAPPDATA%、%APPDATA%、安装目录、用户目录下搜索近期修改的文件夹，按时间排序可快速定位新增或被访问的缓存目录。PowerShell 示例：

• Get-ChildItem -Path $env:LOCALAPPDATA -Recurse | Where-Object { $_.LastWriteTime -gt (Get-Date).AddHours(-3) }
  6) 比对配置文件：如果程序是 Electron 或基于 Chromium 的内核，通常会包含 package.json、resources\app.asar 或类似目录，检查这些文件是否含有 app.getPath('userData')、cachePath 等自定义路径。
  7) 回滚/测试指征对照：在抓包与文件监控中查找远端下发的 feature toggle、版本号、回滚指令或特殊的 JSON 字段，比如 “experimentId”、“rollback”: true、“variant”: “B”。
  8) 清理与恢复：记录需清理的缓存路径并执行删除（先备份），观察客户端行为是否恢复或入口消失。

我实际看到的证据与发现（通用化表述）

• 缓存路径位置：客户端确实在本地读写多个缓存目录，常见位置包括：
• %LOCALAPPDATA%[AppName]\Cache 或 %LOCALAPPDATA%[AppName]\User Data\Default\Cache（若基于Chromium）
• %APPDATA%[AppName]\configs 或 %LOCALAPPDATA%[AppName]\appcache（视实现而定）
• 临时目录（%TEMP%）中也会出现临时解包或下载的临时文件 以上路径可以被进程直接打开或通过临时文件写入来证明访问。
• 有远端配置的证据：在部分抓包记录中，能看到客户端向域名下的 config 或 feature 接口请求 JSON，返回里包含“variants”、“experiment”、“enableEntrance”等键值。这说明入口控制可能由服务端下发配置。
• 版本与构建信息：虽然客户端版本号没有大幅变动，但请求中带的 buildId/commitHash 有轻微差异或包含阶段性标识（stage、beta）。这更倾向于“分阶段推送”或 A/B 类型的控制，而不是单纯的本地回滚。
• 回滚的迹象：如果在短时间内客户端请求的配置从“enableEntrance: true”变为“false”，并且随之界面入口消失，同时访问日志显示后端在同一时间段下发了变更命令，这就是典型的服务端回滚（通过配置下发实现的回滚）。如果入口消失但没有配置变更记录，更可能是本地缓存/版本问题或客户端错误。

“测试”和“回滚”如何在技术层面区分

• 测试（A/B/灰度发布）的典型特征：
• 后端下发的配置中包含分组或variant id（示例：variant=A或variant=1,2,3）
• 同一时间不同客户端表现不同（部分用户看到入口，部分用户无）
• 请求里常伴随设备ID、用户ID、clientId、ab_experiment字段
• 后端日志、API 返回会记录experimentId或实验分配
• 回滚的典型特征：
• 在短时间窗口内所有或绝大多数客户端行为从“开启”切换为“关闭”
• 后端响应中直接把 feature flag 从 true 改为 false，或下发明确的rollback字段
• 有时伴随版本回退（server-side 回滚或将客户端指向旧的资源），但并非必须出现版本号变化

基于我复盘的结论（中立客观）

• 入口突然出现，很大概率是通过服务端下发配置或灰度策略实现的“远端控制”行为，而非单纯客户端本地静态改动。抓包中的配置请求与 JSON 响应支持这一点。
• 关于“缓存路径有变动”的说法：确实有客户端在首次加载或收到新配置后访问了新的缓存目录或创建了新的本地目录，这并非罕见。许多应用会在功能上线或配置变更时创建新的缓存/资源目录来存放模块化资源。
• “测试”与“回滚”两种说法并不互斥：开发方可能先通过远端配置启用了某入口做测试；若数据或稳定性未达预期，再通过相同机制快速回滚。用户看到的“先出现后消失”正是这种流程常见的外在表现。

用户角度的实用建议（操作性强）

• 想确认自己的客户端是否被下发了新的配置：在客户端启动时同时运行 Procmon 并设置进程过滤，观察是否有指向远端 config 的网络请求以及是否创建了新的本地目录。
• 如果担心缓存占用或隐私问题：先用客户端自带“清理缓存/退出登录”功能；若要手动删除，先备份相关目录（直接删除可能丢失登录态或用户数据）。常见的安全删除步骤：

1. 退出客户端（确保没有后台进程运行）。
2. 备份 %LOCALAPPDATA%[AppName] 或 %APPDATA%[AppName]（复制到桌面作为备份）。
3. 删除 Cache 或 tmp 文件夹，再重启客户端观察。

• 若想持续关注此类变化：关注官方公告、更新日志或把客户端日志导出后提交给客服联系。抓包/文件监控属于高级操作，普通用户谨慎使用。

给开发者/运维的提示（供参考）

• 若要做灰度/测试，建议在配置接口中加入清晰的实验ID、时间窗口和变更日志，便于问题发生时快速追溯。
• 回滚时在下发的配置中加入“reason”和“trigger”字段（例如：rollbackreason=stabilityissue），便于运维和用户理解。
• 在客户端日志中记录明确的配置来源（server/configHash）和采样结果，这样可以将用户端表现与后端配置一一对应，减少误判。

常见问答（快速阅读）

• Q：我删除了缓存，入口还会出现吗？
  A：如果入口是由后端配置下发的，删除本地缓存只会临时影响表现；下次客户端启动并拉取配置时可能会再次创建并显示入口。
• Q：能确定这是回滚还是在测试吗？
  A：从单一客户端的表象难以完全判定，需要结合后端配置变更记录和更多客户端的行为样本。抓包到的 feature flag 与 experiment 字段是判断为“测试”的有力证据；而全量快速切换为“关闭”通常指回滚。
• Q：要不要向官方反馈？
  A：建议把出现/消失的时间点、客户端日志、步骤记录发给官方，这些信息对定位问题很有价值。

结语 这次我把从发现到验证的步骤完整复盘，结论倾向于“服务端通过配置下发控制入口，伴随缓存路径的创建或变动”，而“测试”和“回滚”两个说法都有可能成立，关键看后端是如何下发与切换配置的。对于普通用户，关注官方渠道并在必要时清理备份缓存是比较稳妥的做法；对于对隐私或磁盘占用敏感的用户，可以通过上述步骤确认并处理本地缓存。

如果你愿意，我可以把我用到的 Procmon/Fiddler 具体过滤规则和 PowerShell 命令整理成可复制的清单，或者帮你分析一份你导出的客户端日志，定位到底是测试还是回滚。想看哪部分的详细操作？