CC Switch 手册说能点，代码里其实没这个入口

照着一份手册操作，结果找不到它描述的那个入口，第一反应通常是三种：装错版本了、自己眼神不好、或者这功能要先开点别的。CC Switch 这个项目里，还存在第四种可能——手册描述的那个交互，在当前版本的源码里根本没有接线。

这篇不做评价，只做两件事：把 v3.20.1 里几处能核实的差异摆出来，以及给出一套判定动作，让你下次遇到类似情况能自己在几分钟内定性，而不是反复试。

先说清楚这篇的依据

本文对应的快照是 CC Switch v3.20.1，commit 3217f725，核对日 2026-08-31。所有结论都来自静态阅读仓库里的 docs/user-manual/、src/ 与 src-tauri/，我们没有编译、没有运行、也没有安装过这个桌面应用，所以下面不会出现任何关于界面长相、按钮位置或操作快慢的描述。凡是说「代码里没有」，指的是在这份快照的源码里读不到对应的接线，不是说你那边一定看不见。

现象：手册写了「点击行查看详情」，源码里那一行没有点击处理

用量看板这一章是差异最集中的地方。手册 docs/user-manual/zh/4-proxy/4.4-usage.md 的「查看详情」小节（4.4:137-143）写着「点击请求行可查看详细信息」，并列了三项内容：完整的请求参数、响应内容摘要、错误信息。

回到源码。请求日志表在 src/components/usage/RequestLogTable.tsx，渲染每一行的 <TableRow key={log.requestId}> 在 :200——这个元素上没有任何 onClick，整个组件也没有对外抛出行点击回调。

再往下追一层：仓库里确实存在一个详情组件 src/components/usage/RequestDetailPanel.tsx。跑一条 grep 就能定性：

grep -rn "RequestDetailPanel" src tests --include=*.ts --include=*.tsx

命中全部落在这个文件自己身上，没有任何一处 import。组件写完了，但没有任何地方把它挂进渲染树。顺带一提，它展示的字段是基本信息、token、成本、延迟与错误信息（RequestDetailPanel.tsx:67-319），并不包含手册许诺的请求参数与响应内容摘要。

同一章还有三处同类差异，都能用同样的方式核到：

手册怎么写	v3.20.1 源码里读到的状态
供应商与模型按「文本搜索」筛选，另有搜索 / 重置 / 刷新三个按钮（4.4:149-160）	供应商与模型是看板顶栏的下拉（UsageDashboard.tsx:323-373），日志表内只剩一个状态码下拉（RequestLogTable.tsx:116-137），那三个按钮在代码里不存在
耗时列有三种徽章，前两种按阈值分绿 / 橙 / 红（4.4:129-135）	RequestLogTable.tsx:293-300 是纯文本秒数，有首 token 时间时追加一段，没有徽章、没有阈值配色、没有流式标记
趋势图 Y 轴是请求数量，支持缩放和拖拽（4.4:76-84）	UsageTrendChart.tsx:284-333 是四条 token 面积加一条成本虚线，没有请求数序列，整个文件也没有任何缩放或拖拽组件

两处位置都标出来了，孰对孰错不在本文讨论范围，我们只以实读的仓库状态为准。

第一步判定：先读手册的版本头，再读正文提到的最高版本

顶层 docs/user-manual/README.md:15-17 与中文版 docs/user-manual/zh/README.md:107-111 写的是同一句：文档版本 v3.16.0、最后更新 2026-05-29、适用于 CC Switch v3.16.0 及以上。而快照本体是 v3.20.1（package.json:3）。

但版本头本身也不能当准绳。手册正文里已经写着 v3.15.0 之后才有的行为——1.3:61 提到某类卡片会显示路由支持徽章、2.1:441 说模型选择不再只依赖硬编码列表、4.4:58 说顶部改成了筛选驱动的汇总卡。正文被改过，版本头没跟着动。

所以第一条可复用的判据是：看正文里提到的最高版本号，不看版本头。版本头只能告诉你「至少滞后到这里」，正文里的版本标记才是这一段最后被维护的时间点。

第二步判定：把「有没有这个入口」翻译成一次 grep

这类交互最终都要落到某个组件文件里，所以「入口在不在」是一个可以完全靠读文件回答的问题。三个动作，依次做：

1. 找承载这个交互的组件，看事件处理器在不在。 表格行能不能点，就看那个 <TableRow> 有没有 onClick；按钮渲染不渲染，就看它外面有没有条件包裹。
2. 对组件名跑一次全库 grep。 只在自己文件里命中，说明它没被任何地方引用。上面那条 grep -rn 就是完整的判定命令，把组件名换掉即可复用。
3. 别用手册里的中文词去搜代码。 界面文案走 i18n 键，手册用的词和代码里的词经常不是一个。举个能核实的例子：手册在 1.3:89-91 与 4.1:108-110 把供应商健康状态叫「健康 / 警告 / 不健康」和「健康 / 降级 / 不健康」，而 src/components/providers/ProviderHealthBadge.tsx:23-52 的三条分支用的文案键分别对应「正常 / 降级 / 熔断」。拿「不健康」去 grep 代码，一条都搜不到。

第三步判定：搜不到未必是没有，先换个名字再搜

这个项目有一个很容易把人绕进去的特点：同一件事在手册里有好几个名字。zh/README.md:84 叫「应用接管」，第 4.2 节全篇叫「应用路由」，2.6:214 和 4.3:17 又叫「代理接管」；4.1 整节叫「代理服务」，而 4.2:14 叫「路由服务」。

设置项的位置同样有多种写法：1.3:149-174 说设置页分通用 / 高级 / 用量 / 关于四个 Tab，1.5:159-177 又描述了一个代理 Tab，1.5:279 还有一个标着 Beta 的 OAuth 认证中心 Tab，而 4.1:27 把代理服务写成高级下的子项，4.2:20 写成高级下的路由服务，2.6:196 写成路由 Tab 下的本地路由。

结论只有一句：按手册的词搜不到时，先把同义词都试一遍，再下「没有这个入口」的判断。

三类结论必须分开记

差异不都是一回事，混在一起会导出错误的处置动作。按可核实的证据，至少要分三类：

第一类：实现改过，文档没跟上。 最干净的一例是 Stream Check 的检查参数。手册 4.5:47 写超时默认 45 秒、4.5:55 写最大重试默认 2 次、4.5:80-83 描述它「发送简短 prompt、限制最大输出 token、用流式响应检测首字节时间」。而 src-tauri/src/services/stream_check.rs:50-59 的 impl Default for StreamCheckConfig 里，timeout_secs 是 8、max_retries 是 1；同一个 impl 块里、Self 之前的 :52-54 注释原文写明这是「可达性探测打的是 base_url 的小请求（仅读响应头），不等待模型生成，故超时远小于旧的真实请求检查（45s → 8s）」。探测方式换了，超时随之缩短，注释里连迁移痕迹都留着。三项里只有降级阈值两边一致。这几个数是 v3.20.1 的默认配置，可配置、也会随版本变，不要当成固定值背下来。

第二类：文档内部自相矛盾，不必查代码就能发现。 例如当前启用的供应商能不能删：1.3:57 与 1.3:72 都写当前启用时删除按钮禁用、需先切到别的供应商，而 2.4:75 写的是可以删除、只是建议先切换。两说必有一错，这一处我们没有在源码里核实，就照实标为未核实。健康徽章的名字也有一处属于这一类：1.3:89-91 写「警告」、4.1:108-110 写「降级」，两份文档之间就对不上；加上前面提到的代码文案，一共三套说法。

第三类：文档没写全。 v3.20.1 在用量看板里新增的「自动扫描会话记录」开关（UsageDashboard.tsx:485-521）在手册里搜不到——grep -rn "自动扫描\|立即同步" docs/user-manual/ 在 4.4 一章零命中；而 docs/release-notes/v3.20.1-zh.md 的「使用攻略」一节恰恰把读者指向 4.4 去看会话扫描开关的口径。发布说明指向的页面还没更新，这种情况下继续在手册里翻是没有结果的。

三类都只描述差异本身，到此为止，不去推断哪一处才是作者本意。

处置后怎么验证

判定完之后的处置其实只有一句：以实读的源码为准，把手册当索引而不是当规格。验证方式同样不需要运行程序——

• 确认自己看的是哪个版本：package.json:3 的 version 字段，配合 git log --oneline -1 拿到 commit。手册与代码对不上时，先确保两边是同一个快照。
• 确认某个能力是否真的接线：重复上面那条组件名 grep，看有没有除自引用之外的 import。
• 确认文案：用 i18n 键而不是中文词去反查，键名在组件里是写死的，比译文稳定。

什么情况说明不是这个原因

这一步比前面几步都重要。有三类「找不到入口」跟文档滞后无关，误判会让你去改一份根本没问题的配置。

其一，入口在代码里，但被硬前置条件挡着。 手册自己写了不少这类条件，只是分散在二十多个章节里：测速按钮仅在代理服务运行时可用（1.3:70）；用量查询的后台自动刷新仅当供应商处于当前启用状态时触发（2.5:61）；MCP 同步仅在对应应用已安装时执行，未安装时不写入也不报错（3.1:127-135）；Codex 的「需要本地路由映射」必须开启本地路由服务并启用 Codex 接管，且使用期间保持开启（2.1:566）。这些情况下功能是存在的，只是没满足条件——判据是组件被正常引用、只是渲染受一个布尔量控制。

其二，平台分支。 这一条 Windows 用户尤其要注意。手册 3.4-sessions.md 的「恢复会话」一节（:81-90）先讲 macOS 下用你偏好的终端启动，再写「其他平台：恢复命令会被复制到剪贴板」，读起来像是非 macOS 只是降级。而代码 src/components/sessions/SessionManagerPage.tsx:1571 把整个恢复按钮包在 isMac() && (…) 里，非 macOS 分支下这个按钮压根不渲染；handleResume（:431-453）里那段复制到剪贴板的逻辑因此只在被程序化调用时才有机会跑到。类似的还有 Claude Desktop 相关功能仅支持 macOS 与 Windows，Linux 不支持写入 3P 配置（2.6:21、:260）。在这两处上找不到入口是平台差异，不是文档滞后。

其三，两边各缺一块，不是单向滞后。 会话页的供应商过滤器就是这样：类型 ProviderFilter（SessionManagerPage.tsx:85-94）里有 hermes，后端扫描器和 hasSessionSupport（App.tsx:306-319）里也有它，但下拉里实际渲染的 <SelectItem>（:1103 到 :1175）没有这一项。反过来，手册 3.4 的过滤清单（:58-67）列了 Hermes，却没有代码里有的另外两个来源。这种情况下，「手册说能点、代码没接」只描述了一半，另一半是代码有、手册没写。

判完这三条还是对不上，才轮到「手册描述的这个交互在当前版本没有接线」这个结论。这个结论的处置很简单：别再找了，去看源码里实际做了什么。

---

本文依据 CC Switch 官方仓库（github.com/farion1231/cc-switch）的 README、docs/ 下的用户手册、 路由指南与发布说明，以及 src/、src-tauri/、tests/ 的源码整理， 核对日 2026-08-31，对应仓库快照 3217f725（仓库内版本号 3.20.1）。 本文内容为仓库源码与文档口径，我们没有安装或运行过这个桌面应用， 因此不涉及界面外观、操作手感与切换速度的任何描述。 文中出现的阈值与默认值均为源码中的默认配置，不构成对实际运行结果的保证。 该项目仍在快速迭代，版本与默认值随时可能变动，请以仓库最新内容为准。