从面板到多标签页：SkillHub 0.2.0 交互重构与状态管理实践

老读者应该知道，SkillHub 这个项目我从 0.1.0 就开始在社区同步进展，它是一个面向开发者与创意工作者的本地技能工作台，把高频的小工具、模板片段、常用命令统一收拢到一个应用里，省得在不同软件之间来回横跳。这次 0.2.0 更新，核心就两件事：加入多标签页，以及把底层交互逻辑彻底重写一遍。说白了，这不是加一个按钮的事，而是把整个应用的骨架从“面板切换”换成了“标签页 + 状态驱动”，所以我想把这次改版背后的思考、技术选型、踩坑过程完整记录下来，给同样在做工具类应用的朋友一个参考。

如果你正在做的东西也面临“功能越来越多但切换成本越来越高”的窘境，或者你只是好奇一个桌面端工具怎么把多标签页做顺手，这篇文章应该能帮你省掉不少弯路。

1. 先说背景：0.1.x 用起来别不别扭，0.2.0 就为一个答案

1.1 项目定位：SkillHub 是做什么的

SkillHub 最初的想法很简单：把开发和创作过程中频繁使用的零散能力，比如 JSON 格式化、正则测试、时间戳转换、颜色提取、Git 命令速查、Markdown 模板等等，全部集中到一个桌面应用里。它不是一个 IDE，也不是笔记软件，而是一个“技能工具箱”，每个工具就是一个独立的能力单元。

这个定位听起来很轻，但实际用起来有个问题：工具一多，怎么切换就成了决定体验的关键。0.1.x 时代的交互是一个左侧侧边栏列出所有工具，点一个就切换一个面板。单看这个逻辑好像没什么问题，但用得越多越觉得别扭，那种“不对劲感”不是某一个具体功能造成的，而是整个交互模型的瓶颈在积累。

我自己的使用频率大概一天要打开几十次，切换工具的操作次数远比想象中多。时间一长，我开始意识到，SkillHub 缺的不是更好看的界面，而是一个能够承载多任务并行、快速回访的交互容器。这也是 0.2.0 决定动手改架构的直接原因。

1.2 旧版交互真正让人难受的三个点

先说第一个：页面切换等于状态丢失。0.1.x 里切换工具时，旧工具组件会被卸载，再切回来时会重新挂载，结果是表单填了一半的内容、刚跑完的输出结果、甚至滚动位置全都没了。一开始我以为这是小问题，直到有次填一个多字段的正则生成表单，因为想去另一个工具复制一段文本，切回来之后发现十几个字段全部清空，那一下真的破防。

第二个问题是跨工具的工作流被切碎了。比如从“JSON 转 TS 类型”复制结果，再去“代码模板生成器”里粘贴，两个工具之间没有任何联动，也没有“最近使用”的概念。每次都要从长列表里重新找到目标工具，再逐层进入，路径又长又没有记忆。

第三个问题其实是思维层面的：页面结构把用户锁死在“单一任务”模式里。老产品在做界面设计时天然把人假设成“一次只做一件事”，但实际使用者在工具箱里通常是并行推进多个小任务。一个查时间戳，一个测正则，一个写模板，这三个任务在物理世界可以同时摊在桌面上，在主流的编辑器和浏览器里也被多标签页解决了，而我的应用却逼着用户只能看一个。你说用户能不难受吗？

所以在进入 0.2.0 开发之前，我心里已经有一个很清晰的答案：这个产品需要一个像浏览器标签页一样的东西来承载工具，让多个工具的运行状态能够同时存在、随时切换、按需关闭。

2. 多标签页方案选型：为什么我不走路由模拟这条路

2.1 路由模拟和独立标签系统的关键差异

一开始最省事的做法是用路由模拟：在 URL 里加一个?tab=json-formatter，每条路由对应一个工具，切换就是改 URL。这种方式实现成本很低，尤其适合纯 Web 应用，但仔细推演之后我放弃了。

原因很简单：路由天然是“进入”的逻辑，而标签页是“常驻”的逻辑。路由可以记住你打开了哪个页面，但记不住这个页面的内部状态。比如你在 JSON 工具里已经格式化了一段数据，切到 Markdown 工具再切回来，路由会告诉你回到了“JSON 工具”，但不会告诉你之前输出框里的那段内容是什么。要实现状态恢复，还得自己额外做一层状态缓存，绕了一圈又回到了原点。

独立标签系统则不一样，它的核心是让每个标签对应一个带状态的工作区。标签页不只是一个“当前打开了什么”的指示器，而是一个保持存活、可以被后台运行、随时恢复上下文的容器。这个差别就像浏览器里“打开新标签页”和“跳转到另一个页面”的区别：前者保留了你的操作现场，后者会让你丢失现场。

这个判断是整个 0.2.0 取舍的根基。既然 SkillHub 的核心场景是“并行使用多个工具”，那标签式的多工作区就是唯一正确的模型。方案确定后，后面所有设计都围绕“如何让标签页严格处于保活状态”来展开。

2.2 标签页需要承载的最小状态集怎么设计

想清楚用独立标签系统之后，接下来要定义“一个标签页到底是什么”。我画了一张最小状态集的草图，最终收敛下来，一个标签页至少需要这些字段：

这套字段不是一次想全的。最初我只设计了 id、title、kind 三个，结果开发到一半发现关闭标签时怎么提示未保存信息？那必须加 dirty；再做快捷键切换的时候没有最近顺序？那必须加 lastActivatedAt。所以如果你也要做类似功能，建议一开始就把这几个字段塞进去，后面能省去不少重构成本。

另外还有一个值得处理的细节：标签的 params 与工具的历史记录是两回事。params 只是在创建标签时传入的参数，不会随着工具的实时操作而改变，它描述了“这个标签是怎么来的”；而工具内部的运行状态应该在组件内部或按工具独立的 store 里管理，不要一股脑塞进 TabStore，否则状态会越来越臃肿。

3. 核心交互重构：命令总线 + 标签状态管理

3.1 从“按钮逐层点击”到“一次按键直达”

0.2.0 的另一个重头戏是核心交互重构。0.1.x 的交互路径是典型的三层结构：打开侧边栏 → 找到工具 → 点击进入。路径长，而且每一步都要靠鼠标完成，键盘基本派不上用场。作为一个面向开发者的工具，这种交互体验显然是不过关的。

所以这次重构我给自己定了一个硬性指标：用户完成任何一次工具切换，最多不超过两次按键，并且绝大多数场景可以完全不用鼠标。围绕这个目标，我做了一套全局命令体系。打开命令面板只需要一个快捷键，然后键盘输入工具名回车就能打开对应标签；已经打开的标签再输入时，切换动作会直接定位到现有标签而不是新建一个，这个细节能避免标签无限膨胀。

实际做下来，这套交互的效果比预想中好很多，因为命令面板天然适合“模糊搜索 + 快速进入”的心智模型。另外再多说一句，再加一个Ctrl+Tab的前后切换，体感立刻不一样了。这个交互单看没什么技术含量，但配合标签页使用很上瘾。

3.2 TabStore 与 CommandBus 各自负责什么

这次交互重构在代码层面的核心是把“职责”重新划清楚了。我采用了两个核心模块：TabStore 和 CommandBus。TabStore 负责标签数据的增删改查，包括标签列表、当前激活标签、固定状态、草稿状态等；CommandBus 则负责接收全局命令，比如打开工具、切换标签、关闭标签、固定标签，然后统一调用 TabStore 的方法去执行。

听起来有点像把简单问题复杂化，但它解决了一个很实际的问题：界面上任何一个按钮的点击，和键盘快捷键触发的行为，走的是同一条执行路径。以前是点击“关闭”按钮直接调用关闭函数，键盘快捷键又是另一套逻辑，两边非常容易产生行为不一致。现在所有操作都变成向 CommandBus 发命令，由同一个处理器去执行，形成统一出口，后面的维护成本会明显下降。

事件驱动不是唯一选择，但在这次重构的场景下确实是最合适的选择。单一数据源注入到各个交互层，逻辑就变得很清晰了。如果你在做的项目也出现“鼠标操作和键盘操作各写一套逻辑”的情况，这一步重构是值得投入的。

3.3 快捷键、未读提示这些细节值不值得做

核心交互不能只照顾键盘用户，也要照顾鼠标用户，更要照顾“鼠标和键盘混合使用”的用户。0.2.0 里我加了几个细节，看起来是小功能，但实际贡献了不少体验分。

第一个是中间键关闭。浏览器用户都习惯了中键关标签，桌面应用如果不支持这个操作，每次去点那个小叉子都很痛苦。实现上只要在 tab 容器上监听auxclick事件，判断button === 1就可以。

第二个是标签未读闪烁。这个场景是这样的：后台标签页里的工具在运行定时任务，完成后希望提醒用户切回去查看，这时标签标题旁边会出现一个小圆点，并短暂闪烁两次。这个功能以前在面板模式下根本无法实现，因为后台工具根本不会被保留。有了标签系统后，后台工具常驻，才能有“后台提醒”这个概念。

第三个是固定标签。固定后的标签不显示关闭按钮，也不能被中键关闭，避免手滑把常用工具关掉。这个功能实现起来不复杂，但需要在使用场景中定义清楚：固定标签如果内容变 dirty 了，是否要改变颜色提醒？我目前的方案是底色不变，但标题前加一个圆点，这样既不明显打断视觉流，也不会漏掉状态变化。

这些功能的共同点是想清楚交互规则之后再动手写代码，而不是边写边加。如果写到一半再补，很容易出现逻辑分支散落，调试成本高。

4. 多标签页实现的代码级拆解

4.1 类型定义与 Store 基础结构

理论聊够了，进入代码环节。这套实现的思路可以挪到任何前端技术栈里，我这边用的 TypeScript 来写类型，状态管理用的是一个极简的自定义 store，没有引入重型状态库，因为标签页的更新频率并不高，用一个发布订阅模式完全足够。

首先是类型定义：

export type TabStatus = 'idle' | 'loading' | 'error'; export type TabKind = 'json-formatter' | 'regex-tester' | 'timestamp-converter' | 'color-picker' | string; export interface SkillTab { id: string; title: string; kind: TabKind; params: Record<string, unknown>; status: TabStatus; dirty: boolean; pinned: boolean; lastActivatedAt: number; createdAt: number; } export interface TabSnapshot { tabs: SkillTab[]; activeTabId: string | null; savedAt: number; }

然后是一个最小化的 TabStore，核心就是维护 tabs 数组和 activeTabId：

class TabStore { private tabs: SkillTab[] = []; private activeTabId: string | null = null; private listeners = new Set<() => void>(); subscribe(fn: () => void) { this.listeners.add(fn); return () => this.listeners.delete(fn); } emit() { this.listeners.forEach((fn) => fn()); } getState() { return { tabs: this.tabs, activeTabId: this.activeTabId, activeTab: this.tabs.find((t) => t.id === this.activeTabId) ?? null, }; } openTab(kind: TabKind, params?: Record<string, unknown>) { const existing = this.tabs.find((t) => t.kind === kind && !t.pinned); if (existing) { this.activateTab(existing.id); return existing; } const tab: SkillTab = { id: crypto.randomUUID(), title: this.resolveTitle(kind), kind, params: params ?? {}, status: 'idle', dirty: false, pinned: false, lastActivatedAt: Date.now(), createdAt: Date.now(), }; this.tabs.push(tab); this.activateTab(tab.id); this.emit(); return tab; } activateTab(id: string) { this.activeTabId = id; const tab = this.tabs.find((t) => t.id === id); if (tab) tab.lastActivatedAt = Date.now(); this.emit(); } closeTab(id: string) { const tab = this.tabs.find((t) => t.id === id); if (!tab || tab.pinned) return; this.tabs = this.tabs.filter((t) => t.id !== id); if (this.activeTabId === id) { this.activeTabId = this.findNextActiveTab(id); } this.emit(); } private findNextActiveTab(closedId: string) { const idx = this.tabs.findIndex((t) => t.id === closedId); if (idx === -1) return null; return (this.tabs[idx - 1] ?? this.tabs[idx + 1] ?? null)?.id ?? null; } private resolveTitle(kind: TabKind) { const titles: Record<string, string> = { 'json-formatter': 'JSON 格式化', 'regex-tester': '正则测试', 'timestamp-converter': '时间戳转换', 'color-picker': '取色器', }; return titles[kind] ?? kind; } }

这段代码不复杂，但里面有用两点需要注意：closeTab 时不是无脑取前一个标签作为下一个激活项，而是优先取左边的邻居，没有左边再取右边，这个行为更贴近主流编辑器；而openTab 加了“已有标签则激活”的判断，这样快捷键重复打开一个工具时不会产生一堆重复标签。

4.2 关闭、切换、固定的边界处理

代码里最容易出 bug 的就是边界处理。关闭标签这个动作听起来很简单，但当它是“当前激活标签”时，焦点给谁、如果关闭的是最后一个标签怎么办、如果唯一剩下的标签被固定住了怎么办，这些都要单独考虑。

我目前的策略是：关闭当前标签后，优先把焦点给左侧相邻标签，如果左侧没了就给右侧。最后一个可关闭标签被关闭后，应用会回到一个“空状态”界面，而不是强制某个标签一直存在。固定标签不能关闭，这个在 closeTab 里做了拦截。UI 层也要同步处理：固定标签不渲染关闭按钮，也不响应中键关闭。

另一个边界是切换标签时 dirty 状态的提醒。如果一个标签处于脏状态（比如有未保存的模板修改），用户切换标签不应该拦截，因为 SkillHub 的标签本身就是工作区，切换不等于销毁。但在关闭这个标签时，如果 dirty 为 true，需要弹一个轻量的确认浮层，提示“该标签内有未保存内容，确认关闭？”。这个浮层不是 modal 对话框级别那么重，就是一个跟随鼠标的小弹窗，避免打断操作流。

切换标签时的组件生命周期也要专门处理。我的实现是给每个标签建立一个独立的容器节点，切换时不是卸载，而是把旧标签的容器隐藏，把新标签的容器显示出来。这样组件的useEffectcleanup 不会执行，React 内部也不会去销毁组件实例，状态自然保留。效果上最接近浏览器的“后台标签页挂起”机制。

具体实现上，我维护一个 Map：

const tabContainersRef = useRef(new Map<string, HTMLDivElement>()); function renderTab(tab: SkillTab) { return ( <div key={tab.id} >