CC Switch 是一款免费、开源的桌面应用，作用是统一管理 AI 编程工具的 API 供应商，Windows、macOS、Linux 全平台支持。

用 Claude Code、Codex、Gemini CLI、OpenCode 这类 AI 编程工具时，经常要在不同供应商（官方、中转、自建等）之间切换，手动改配置文件很麻烦。CC Switch 把这些工具的供应商配置集中到一个图形界面里，切换时点一下就行，不用再复制粘贴配置内容。

一、获取 CC Switch

CC Switch 安装包：CC Switch安装包（源自 GitHub，Windows + macOS + Linux）

CC Switch 官方提供了各平台的安装包：

二、安装 CC Switch

1. Windows 平台安装

有了 .msi 文件后双击启动，点击 Next：

选择安装路径。默认装在 C 盘，想省系统盘空间可以改到 D 盘：

点击 Install，开始安装：

等待安装完成，完成后桌面会出现 CC Switch 快捷方式，双击就能打开它：

如果不想写注册表，下载 Portable 便携版，解压后直接运行 exe 文件：

注意： Windows 版本已禁用「一键安装」功能，如果需要安装 Claude Code 等工具，请手动安装后再通过 CC Switch 来管理。

2. macOS 平台安装

有了 .dmg 文件后双击打开，把 CC Switch 图标拖入「应用程序」文件夹，应用就能打开了。

3. Linux 平台安装

Ubuntu/Debian/Mint 用户获得 .deb 文件，执行：

sudo apt install ./CC-Switch-*.deb

Fedora/RHEL 用户获得 .rpm 文件，执行：

sudo dnf install ./CC-Switch-*.rpm

其他发行版可以直接获得 .AppImage 文件，加执行权限后运行即可：

chmod +x CC-Switch-*.AppImage
./CC-Switch-*.AppImage

三、CC Switch 基础使用

CC Switch 的核心功能是管理和切换供应商，下面依次给大家讲清楚。

1. 认识主界面

打开 CC Switch 后，顶部是导航栏，可以选择当前管理的 AI 编程工具（Claude、Claude Desktop、Codex、Gemini、OpenCode、OpenClaw、Hermes），切换后下方列表就显示对应应用的供应商配置：

导航栏最右侧是添加按钮（+）。界面主体是供应商卡片列表，每个供应商以一张卡片展示：

2. 添加供应商

点击主界面右上角的 + 按钮，在弹出窗口的「预设供应商」框里选择你的供应商（常用预设包括智谱 GLM、MiniMax、DeepSeek、Kimi 等），预设会自动填好端点地址，你只需要填写 API Key，点击「添加」即可。

如果你的供应商不在预设里，选择「自定义」手动配置接口地址和模型信息。

3. 切换供应商

添加完成后供应商出现在列表中，切换有两种方式：

一是主界面切换，把鼠标悬停在目标供应商卡片上，点击卡片上的「启用」按钮（▶）：

二是托盘快速切换，右键系统托盘里的 CC Switch 图标，在「Claude」「Codex」等子菜单里直接点供应商名称，当前启用的会带勾选标记，不用打开主界面就能切。

4. 健康检查

添加完供应商后，可以点击旁边的「健康检查」按钮，发送一个测试请求来验证 API Key 和网络连通性。这个功能很实用，能帮你快速排除是 API Key 的问题还是网络的问题。

配置正常的话，CC Switch 会给出「运行正常」的提示：

5. 管理供应商卡片

把鼠标悬停在卡片上，会显示一排操作按钮：启用（使用中）、编辑、复制、检测连通、配置用量查询、删除：

• 编辑可以改供应商配置；
• 复制能快速创建副本；
• 检测连通可以测试模型连通性和响应速度；
• 删除可以移除不需要的供应商（当前正在用的供应商要先切换到别的才能删除）。

按住卡片左侧的拖拽手柄（≡）可以上下拖动调整供应商顺序。

四、新手注意事项

1. CC Switch 是管理工具，本身不包含任何 AI 服务。添加供应商时需要填入自己的 API 密钥或配置信息，密钥由各服务商提供。首次使用先添加一个供应商测试连通性，确认能正常调用再批量添加其他供应商。
2. 切换供应商后，已打开的 AI 编程工具（如 Claude Code）需要重启或新开会话才能生效。这是正常现象，不是 CC Switch 的问题——配置是启动时读取的，切换后记得重启对应工具。
3. 不同 AI 编程工具的配置格式不一样，CC Switch 为每个工具提供了对应的供应商添加入口。添加时先选对工具类型（Claude Code、Codex、Gemini CLI 等），再填对应配置，填错位置会导致切换无效。

益诗上线四个月，所有用户上传的图片都放在那里。包括 571 个人的头像，124 张诗歌封面，50 个诗集封面，79 张 AI 海报。

这篇是复盘。我把它完整写下来，因为里面有几步值得记住，也有两个我自己犯的错误值得你绕开。

一、先清点：什么还在，什么没了

先要做的事是把边界划清楚。

数据库完好无损。用户 1770 个，诗歌 15332 首（未删除部分），评论 2368 条，通知 34896 条，还有点赞收藏、关注关系、诗集、漂流瓶、成长记录——全部安好。这些都在 MySQL 里，误删的目录跟它无关。

后端程序也活着。yishi.jar 在另一个目录，进程已经连续跑了 48 天。systemd 单元文件在 /etc/systemd/system/，不在 wwwroot 下面，所以数据库密码、Redis 密码、JWT 密钥、通义千问的 API Key、MinIO 凭据、QQ 互联的 AppID 和 AppKey，一个都没丢。这一点后来省了我很多事。

丢的是这些：

Nginx 配置在宝塔的 vhost 目录里，不在 wwwroot 下，也活着。

二、让站点先活过来

前端最容易补，本地构建产物都在。H5 有 82 个资源文件，管理端 85 个，打包压缩后 scp 上去解包，改属主权限就好。

后端 jar 完全不用重传。我比对了两边的 MD5：

线上  f160342af2d74778653aab791676de8f
本地  f160342af2d74778653aab791676de8f

一致，说明线上跑的就是我本地这份构建，省掉一次重新打包和上传。

APK 也在本地，yishi-0.11.0.apk，20,340,809 字节，放进 /apk/ 目录。Nginx 没有单独的 /apk/ location，走的是 SPA 兜底的静态服务，能正常下载。

真正麻烦的是 MinIO。 它的可执行文件被删了，而且 —— dl.min.io 这个官方下载域已经停用，所有路径都返回 410 Gone：

https://dl.min.io/server/minio/release/linux-amd64/minio            → 410
https://dl.min.io/server/minio/release/linux-amd64/archive/...      → 410
https://dl.min.io/server/minio/release/linux-amd64/minio.asc        → 410

GitHub Releases 也是 404。最后在官方中文源拿到了：

curl -sL --retry 3 -o minio \
  https://dl.minio.org.cn/server/minio/release/linux-amd64/minio

版本 RELEASE.2025-07-23T15-54-02Z，110 MB，仍然支持 --console-address，systemd 单元一个字不用改。

装回去之后还有一层坑。数据目录当时只剩一个 .minio.sys，MinIO 启动时报的是：

Unable to load healing tracker: unformatted drive found, re-initializing..
Error: Read failed. Insufficient number of drives online

它认不出这个盘，于是 mc mb 建桶直接报 Resource requested is unwritable。重启一次，让它把空盘重新格式化，然后建桶、设公共读：

mc mb --ignore-existing local/yishi
mc anonymous set download local/yishi

到这一步站点是活的，但 824 张图片真的没了。磁盘上、备份里、回收站里都没有。

三、意外的出路

那天下午我想通一件事：这些图片在我的服务器上没了，但它们在你手机里。

/img/ 这个路径的响应头是这样的：

expires: Sun, 19 Sep 2027 09:39:02 GMT
cache-control: max-age=31536000
cache-control: public, immutable

一年有效期，immutable 意味着浏览器可以直接复用，不必回服务器校验。MinIO 的文件名是 UUID，永不变更，当初这么配就是为了让图片秒开。这个配置让图片在别人手机上留了一份完整的字节副本，而且源站返回 404 也不会触发重新拉取。

同源页面上的 JavaScript 可以把它读出来，再传回服务器。因为写回的是完全相同的 object key，数据库里那 824 条 URL 一个字都不用改。

我写了一个临时页面干这件事，跑完就撤了。技术路线值得记下来。

第一次尝试，失败了

最初我用两种方式去读缓存：fetch(url, {cache: 'force-cache'})，以及一个游离的 new Image() 对象。

结果 nginx 访问日志里是一整片 404 —— 每一次请求都打到了服务器。浏览器渲染图片时用的是另一条缓存通道。这一版只捞回 93 张，而且命中大多来自别的原因。

换成真实渲染

第二版换了思路：把图片真实地 <img> 渲染进 DOM，再从已经渲染出来的元素上取像素。

// 图片既然能显示，就一定能从它身上取到像素
ctx.drawImage(img, 0, 0, cw, ch);
const blob = await new Promise(res => canvas.toBlob(res, type, 0.94));

因为要经过 canvas 重新编码，还得配一条降级链：toBlob 编码不出来就退回 toDataURL，标准尺寸失败就把图缩到 60%、35% 再试。

这一版数字从 93 涨到 272。

然后页面崩了

头像组有 571 张。第二版一次性把整组缩略图都挂进 DOM，移动端浏览器的内存直接爆掉了。

第三版改成固定槽位：只保留 N 个 <img> 元素循环复用（默认 3 个，可调 2/3/4），每张判完状态立刻 removeAttribute('src') 释放，再换下一张。

// DOM 节点数和内存占用恒定，跟图片总数无关
function release(slot) {
  try { slot.img.removeAttribute('src'); } catch (e) { slot.img.src = ""; }
}

跑 50 张和跑 571 张，占用完全一样。命中的图用 88×88 的小画布裁切收进网格，上限 400 张，单张约 31KB。

顺带还发现一件事：/img/ 的响应带 vary: Origin，而站内「生成海报」功能是用 crossOrigin="anonymous" 读图的 —— 那是另一条缓存条目。所以补了一条 crossorigin 备用路径。

四、三分之一的墙

最终停在 272 / 824，约 33%。

为什么不是更多？我拿一个指标去验证：每张图片最后一次被服务器成功取到的时间。

• 已经找回来的头像：98 张里 97 张的最后一次成功加载在九月
• 仍然缺失的诗歌封面：44 张停在六月，25 张停在五月，只有 18 张落在九月

规律很清楚了。immutable 和 expires 管的是新鲜度：浏览器愿意直接复用，不必回服务器校验。至于留存，移动浏览器和 iOS Safari 依然会按最近最少使用（LRU）清理长期不碰的条目。

头像出现在每一个页面上，被反复读取，缓存条目一直是热的。诗歌封面只在特定卡片上出现，而 15333 首诗里只有 127 首带封面 —— 出现频率太低，条目早就凉了。

我做了一个决定性的验证：把用户当天实际打开过的每一首诗的封面逐一对照。结果是 封面仍缺失的数量为 0。也就是说，他们能在手机上看到的那些诗歌图片，正是已经接回来的那 47 张。剩下那些，确实不在任何设备上留下过副本。

这条路走到头了。

五、然后我犯了第二个错误

我没有立刻收手，转而去试磁盘取证 —— 图片被删掉才两个多小时，服务器还有 16G 空闲空间，我猜数据块可能还躺在原地。

前半段是有收获的。我摸清了 MinIO 在磁盘上的真实布局：每个对象是一个以对象名为名的目录，里面有：

• xl.meta，约 350 字节，含 etag 和 content-type
• DDir-<uuid>/part.1，实际数据，约 656KB 一片

这意味着目录名本身就是文件名，理论上可以整目录找回，比缓存那条路完整得多。

然后我跑了这条命令：

dd if=/dev/vda3 bs=8M | LC_ALL=C grep -aob -F -f patterns.txt

patterns.txt 有 555 个模式 —— 552 个缺失文件名加上几个图片魔数。目标是遍历 40GB 磁盘找残留。

这是那次事故里最糟的一个决定。它把生产盘的 I/O 占满，内存也被吃掉，最终拖垮了整台服务器，我只能在阿里云控制台强制重启。

正确的做法是在离线快照上做，或者用 debugfs 定点读取 inode。任何长耗时的扫描都应该加 nice -n 19 和 ionice -c3，并且预先设好超时。判断数据能否恢复，优先用轻量证据：看一个 inode 的 extent 记录、做小范围采样，都足够下结论。

代价是我为了多救几张图片，让整个站点又断了一次。

六、重启之后

服务器重启后所有服务都自动起来了：yishi、minio、nginx、mysql、redis、cron 全部 active。桶内 272 个对象完好，数据库行数与重启前一致。

我做了收尾：

• 删除临时恢复页面、接收程序、分组清单、nginx 反代配置、8099 端口
• 还原 nginx 配置并删除部署时产生的备份文件
• 移除 mc 的 local 别名
• 清理 /tmp 和本地脚本目录
• 复查确认站点根目录只剩 index.html / assets / static / apk

站内公告也改写了一版，去掉了所有引导用户参与的步骤 —— 找回通道关了，不该再让任何人点进去。

七、值得记住的几件事

在生产目录里删东西之前，先确认它有没有备份。 这次的全部损失，源头就是这一条。我有数据库的每日备份，但对象存储目录不在任何备份计划里。

immutable 管的是新鲜度。 这个响应头让浏览器愿意直接复用、不回源校验。条目能留多久，由最近最少使用策略决定 —— 低频访问的资源，缓存待不了太久。

顺手配的缓存策略，在灾难时会变成救命的东西。 那 272 张图片能回来，靠的就是当初为了让页面快一点而加的 immutable。当时做这个决定，只想到性能这一层。

读浏览器缓存要用渲染。 fetch(cache: 'force-cache') 和游离的 new Image() 都读不到渲染通道那份缓存，实测每一次请求都会打到服务器。

长耗时的扫描要放在离线快照上做。 第二个错误比第一个更不可原谅，因为它是我在已经出事之后，又主动制造的一次故障。

八、接下来

已经加上了对象存储目录的异地备份，跟数据库放在同一套计划任务里。

找不回的 552 张图片，位置会留空。头像随时可以重新上传，新图会被正常保存。

那 272 张能回来，是一台台设备上那些看不见的副本替我保住的。写这篇文章的时候我在想，如果当初没有顺手开那个缓存头，现在的数字会是 0。

写于 2026-09-19，服务器重启之后。