cc-switch 供应商列表管理实战：拖拽排序、复制与删除的完整操作与源码解析-平芜编程栈

cc-switch 供应商列表管理实战：拖拽排序、复制与删除的完整操作与源码解析

【免费下载链接】cc-switchA cross-platform desktop All-in-One assistant for Claude Code, Codex, OpenCode, OpenClaw, Grok Build & Hermes Agent. Only official website: ccswitch.io项目地址: https://gitcode.com/GitHub_Trending/cc/cc-switch

本篇围绕 cc-switch 用户手册中的「排序与复制」章节展开，讲解如何在供应商列表中通过拖拽调整显示顺序、基于现有供应商快速创建配置副本，以及安全删除供应商。读完本文，你不仅能掌握这三项操作的具体步骤，还能从源码层面理解排序权重sortIndex的落库机制、复制时配置深克隆与唯一标识生成策略，以及删除按钮在不同应用（Claude、Codex、OpenCode、Hermes 等）下的启用条件。

拖拽排序

操作步骤

cc-switch 支持通过拖拽调整供应商的显示顺序：

将鼠标移到供应商卡片左侧的≡拖拽手柄
按住鼠标左键
上下拖动到目标位置
松开鼠标完成排序

排序用途

常用优先：将常用的供应商放在列表顶部，减少切换时的查找成本
故障转移顺序：排序会影响故障转移（Failover）队列的默认顺序。当 Proxy 路由开启自动故障转移时，队列顺序直接继承自供应商列表的排序

源码层面的排序实现

排序功能的实现集中在 useDragSort.ts，它基于@dnd-kit/core完成拖拽交互：

触发阈值：PointerSensor配置了activationConstraint: { distance: 8 }，即指针移动超过 8 像素才激活拖拽，避免普通点击误触发拖拽逻辑（见 useDragSort.ts）
键盘可访问：同时注册了KeyboardSensor并配合sortableKeyboardCoordinates，键盘用户也可以完成排序
排序权重的三级回退：sortedProviders的排序规则依次为sortIndex（用户拖拽后持久化的位置）、createdAt（创建时间）、名称（按当前界面语言做localeCompare排序，支持 zh-CN、zh-TW、en-US 三种 locale），见 useDragSort.ts

拖拽结束后的落库流程在handleDragEnd中完成：

用arrayMove计算新的完整顺序；
为列表中所有供应商生成{ id, sortIndex }更新项，批量调用providersApi.updateSortOrder(updates, appId)持久化；
失效["providers", appId]查询缓存刷新界面；
若当前是路由类应用（isProxyAppId(appId)为真），额外失效failoverQueue查询——源码注释明确写道 “Routing apps derive failover order from sort_index”，这正是「排序影响故障转移队列」结论的代码依据；
调用providersApi.updateTrayMenu()同步系统托盘菜单（该步骤失败只记录日志、不影响排序本身）。

整个流程见 useDragSort.ts。

复制供应商

适用场景

快速创建供应商的副本，适用于：

基于现有配置创建变体
备份当前配置
创建测试用配置

自 v3.15.0 起，统一供应商（Universal Provider）列表也提供复制按钮，可以直接从现有统一供应商创建副本后再调整同步应用和模型。

操作步骤

鼠标悬停在供应商卡片上，显示操作按钮（复制按钮为卡片右侧的 Copy 图标，见上文截图红框标注处）
点击「复制」按钮
自动创建副本，名称添加copy后缀
编辑副本修改配置

复制内容的具体行为

文档给出「复制会创建完整副本」的结论，源码 App.tsx 中的handleDuplicateProvider给出了精确的字段清单：

内容	是否复制	源码细节
名称	✅ 复制（追加`copy`后缀）	新名称为`${provider.name} copy`
配置	✅ 完整复制	`settingsConfig`通过`deepClone`深克隆，副本与原配置互不影响
备注 / 元数据	✅ 复制	`meta`同样`deepClone`
网站链接	✅ 复制	`websiteUrl`原样复制
图标	✅ 复制	`icon`与`iconColor`均复制
排序位置	✅ 插入到原供应商下方	新副本`sortIndex = 原 sortIndex + 1`，同时把原位置上所有后续供应商的`sortIndex`整体 +1，再调用`updateSortOrder`批量落库；若这一步失败，复制流程会中止，不会出现顺序错乱

源码补充：不同应用下的额外约束

在 OpenCode、OpenClaw、Hermes、Pi 这类“累加模式”（additive）应用中，供应商除了本地记录外还可能存在于应用自身的 live 配置中。复制逻辑会先读取 live 配置里已存在的供应商标识，再通过generateUniqueProviderCopyKey生成唯一键：基础键为${原id}-copy，若冲突则依次尝试-copy-2、-copy-3……（见 App.tsx）。同时副本会被标记addToLive = false，即只创建本地供应商记录，不会自动写入应用的 live 配置，需要你确认后再决定是否为副本启用/加入配置——这避免了复制操作意外改变应用当前指向的服务商。

对于统一供应商，复制逻辑在 UniversalProviderPanel.tsx 的handleDuplicate中：对原供应商做整体deepClone，分配新的crypto.randomUUID()作为 id，名称追加copy后缀，随后依次执行upsert（保存副本）和sync（同步副本到其关联的应用），成功后提示「统一供应商已复制并同步」。这也对应文档中「v3.15.0 起可直接复制统一供应商后再调整同步应用和模型」的说法。

复制按钮的界面渲染位于 ProviderActions.tsx，其title文案来自 i18n 键provider.duplicate（中文为「复制」）。

复制后编辑

复制完成后，通常需要修改：

名称：改为有意义的名称（默认原名 copy仅适合临时区分）
API Key：如果副本对应不同的账号
端点：如果副本指向不同的服务

删除供应商

操作步骤

鼠标悬停在供应商卡片上，显示操作按钮
点击「删除」按钮（卡片最右侧的垃圾桶图标）
确认删除

删除确认

删除前会弹出确认对话框，显示：

供应商名称（确认文案由 i18n 键confirm.deleteProviderMessage生成，会代入confirmAction.provider.name）
删除后无法恢复的提示

确认消息的构造见 App.tsx 的confirmActionMessage。

删除限制

文档给出的两条限制与源码中的启用逻辑一致，ProviderActions.tsx 的canDelete决定了删除按钮何时可点击：

当前启用的供应商：在 Claude 等单选类应用中，正在使用的供应商删除按钮会被禁用（!isCurrent条件）；文档建议先切换到其他供应商再删除
统一供应商：删除统一供应商后，其关联的应用配置也会被删除
从源码结构看，还有两类额外约束：Hermes v12+ 管理的只读供应商（isReadOnly）不显示删除能力，需在其 Web UI 中操作；OpenCode / OpenClaw / Hermes 等累加模式应用删除始终可用（其语义是“从配置中移除该供应商”而非删除本地记录）

删除的兜底机制

删除本身通过 useProviderActions.ts 中的deleteProvider（底层为useDeleteProviderMutation）执行。对于复制出的副本，建议遵循“先复制验证、再删原件”的顺序：先复制一份用于备份，确认副本可用后再删除原件，即使误删也有本地配置可恢复。

小结

cc-switch 的供应商列表管理围绕一个核心字段sortIndex展开：拖拽排序通过@dnd-kit收集新顺序后批量持久化，并联动故障转移队列与托盘菜单；复制操作深克隆配置、在原位置下方插入副本、在累加应用中生成唯一键且默认不写入 live 配置；删除操作受当前启用状态与应用类型的双重约束并配有确认对话框。三项操作对应的关键实现可分别在 useDragSort.ts、App.tsx 与 ProviderActions.tsx 中查证。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考