前端选型速查：用 Kaneo 的 pick-ui-library 技能为每个 UI 任务选对库
【免费下载链接】app🎯 All you need. Nothing you don't. Open source project management that works for you, not against you.项目地址: https://gitcode.com/GitHub_Trending/app116/app
当你在一个大型前端项目中接到"需要弹窗""要做拖拽""要写图表"这类任务时，最纠结的往往不是怎么写，而是选哪个库。本文以 Kaneo 仓库中的 pick-ui-library 技能（在.agents/skills/pick-ui-library/SKILL.md存有同一份副本）为骨架，系统拆解这份"经过品味筛选的推荐清单"背后的决策逻辑，并结合仓库真实依赖与源码落地，整理成一份可直接复用的前端选型速查手册。读完你既能按任务快速匹配库，也能理解 Kaneo 前端（apps/web）为何在数十个场景中一致采用同一批底层选型。
技能定位：一张"查找表"，而不是万能顾问
先看这份技能的元信息（frontmatter）：
name: pick-ui-library description: Pick the right library for a given frontend task from a curated, opinionated list — numbers, OTP inputs, charts, command menus, virtualization, drag and drop, toasts, state, styling, and more. Only runs when explicitly invoked; it does not trigger on its own. disable-model-invocation: true两个关键设计值得注意：
- 显式调用，绝不自动触发：
disable-model-invocation: true意味着 Agent 不会在任意对话里擅自抛出这份清单，只有当用户明确以任务形式提出（"我需要 toast""拖拽用什么？"）时才激活。这种"按需查找"（lookup）模式避免了在无关上下文中刷屏，是工程化 Agent 技能的一个良好范例。 - 有主见的推荐：文档明确写道"These are deliberate, taste-driven picks"——这份清单是经过筛选的、有明确倾向的结论，而不是一个"什么都能用"的中性目录。当清单里有明确答案时，不要端出一桌选项让用户挑。
使用流程：四步决策法
技能给出了固定的调用步骤，每一步都对应一个具体的工程约束：
- 识别任务，而不是用户提到的库名。"我要一个下拉框"本质上是"无样式、可访问的 UI 原语"任务（对应 base-ui），即使对方误报了别的库名，也要回到任务本身去匹配。
- 先看
package.json里已装了什么。项目已经在用清单中的库就直接复用；如果项目正在用竞品（例如用 react-window 而不是 Virtuoso），可以指出差异，但不要未经请求就擅自更换依赖。这是对现有代码库的尊重，也避免无谓的依赖震荡。 - 只推荐一个库，用一句话说明它的用途，如果请求中包含安装/接线需求就顺手完成。清单有明确答案时不要给出"菜单式"的多选项。
- 清单覆盖不到就明说，然后基于自己的知识推荐，同时明确声明"已经离开了这份 curated list"。
完整推荐清单：五个任务域的选型表
这是技能的核心资产，五个分类、全部条目逐一列出。
UI 组件与基础原语
| 任务 | 推荐库 |
|---|---|
| 无样式、可访问的 UI 组件（对话框、弹出层、菜单、下拉选择……） | base-ui |
| 命令面板（⌘K 命令菜单） | cmdk |
| Toast / 通知 | Sonner |
| 一次性密码 / 验证码输入框 | input-otp |
| 可定制的 GUI / 控制面板 | Leva（备选：dialkit） |
这一栏的语义很清晰：凡是"可访问性、焦点管理、关闭逻辑"这类容易被写错的底层细节，交给 base-ui 这类无样式原语；凡是"高频小交互"（命令菜单、toast、验证码输入），用专用小库而不是自己造轮子。
动效与视觉
| 任务 | 推荐库 |
|---|---|
| 通用动画（弹簧、布局动画、进出场） | motion（即 Framer Motion） |
| 数字动画（计数器、价格、统计数字） | NumberFlow |
| 文字动画组件 | torph |
| 3D 地球 | Cobe |
| 动态 OG 图（HTML/CSS → SVG/PNG） | Satori |
| 语法高亮 | shiki |
技能在这里特别划了一条使用边界："弹簧、布局动画、退场动画或手势驱动的值"才需要 motion；一个简单的 hover 或 fade 不需要动效库，纯 CSS transition 才是正确的工具。这条原则直接决定了代码库中动效依赖的数量级——动效库是放大器，不是默认值。
图表
| 任务 | 推荐库 |
|---|---|
| 实时 / 流式图表 | Liveline |
| 通用图表（静态或交互式仪表盘） | recharts |
拆分的标准只有一句话：如果数据点是实时到达、图表随时间滚动，用 Liveline；其余一切场景用 recharts。
交互与性能
| 任务 | 推荐库 |
|---|---|
| 拖拽 | dnd kit |
| 虚拟化（长列表、大表格） | Virtuoso |
虚拟化是性能兜底手段：当列表动辄上千行时才需要 Virtuoso，而不是一开始就引入分页 Hack。
状态与样式
| 任务 | 推荐库 |
|---|---|
| 状态管理 | zustand |
按条件拼接className字符串 | clsx |
| 面向 Tailwind 的类型安全、变体驱动样式 | cva |
| 主题切换 / 暗色模式（加载无闪烁） | next-themes |
同样有一条拆分原则：临时性的条件类拼接用 clsx；当一个组件真的有多种变体（尺寸、意图、状态）且值得一个类型化 API 时，才用 cva。二者天然互补——cva 内部使用的就是 clsx 风格的输入，可以组合使用。
仓库实装验证：这份清单在 Kaneo 里怎么落地
选型清单的价值在于被真实使用。打开 apps/web/package.json 可以看到，清单中的大部分库确实以"正主"身份安装在@kaneo/web的 dependencies 中：@base-ui/react、@dnd-kit/*（core、modifiers、sortable、utilities）、cmdk、sonner、input-otp、class-variance-authority、clsx、framer-motion、shiki、zustand，以及配套的tailwind-merge。下面按任务域逐一对应源码证据。
base-ui + cva + clsx：无样式原语的变体化封装
Kaneo 的 UI 原语目录 apps/web/src/components/ui 下有 50 余个基于 base-ui 封装的组件（dialog、popover、select、menu、tooltip、tabs……）。以 Button 组件为例，它完美演示了"无样式原语 + cva 变体"的组合：
import { mergeProps } from "@base-ui/react/merge-props"; import { useRender } from "@base-ui/react/use-render"; import { cva, type VariantProps } from "class-variance-authority"; import { cn } from "@/lib/cn"; export const buttonVariants = cva( "relative inline-flex ...", { defaultVariants: { size: "default", variant: "default" }, variants: { size: { default: "h-9 px-...", icon: "size-9 sm:size-8", lg: "...", sm: "...", xl: "...", xs: "...", /* icon-lg/icon-sm/icon-xl/icon-xs */ }, variant: { default: "...", destructive: "...", ghost: "...", link: "...", outline: "...", secondary: "...", "destructive-outline": "..." }, }, }, );base-ui 负责mergeProps、useRender这类底层的无样式交互逻辑，cva 负责给size（default、sm、lg、xl、xs、icon 系列共 9 种）和variant（default、destructive、outline、ghost、link、secondary、destructive-outline 共 7 种）建立类型安全的变体 API——这正是技能中"组件有真实变体时用 cva"的教科书式应用。
而 apps/web/src/lib/cn.ts 则是 clsx 的典型封装，并与tailwind-merge组合以解决类名覆盖问题：
import { type ClassValue, clsx } from "clsx"; import { twMerge } from "tailwind-merge"; export function cn(...inputs: ClassValue[]) { return twMerge(clsx(inputs)); }整个apps/web中数百个组件文件都通过cn()拼接条件类名，验证了"clsx 用于临时条件拼接"这一选型。
dnd kit + motion：看板拖拽与进出场动画
Kanban 看板是 Kaneo 的核心交互之一，恰好同时用到了"交互与性能"栏的两个库。看 column-dropzone.tsx：
import { useDroppable } from "@dnd-kit/core"; import { SortableContext, verticalListSortingStrategy } from "@dnd-kit/sortable"; import { AnimatePresence, motion, useReducedMotion } from "framer-motion";useDroppable定义列的放置区，SortableContext+verticalListSortingStrategy管理列内任务的排序；同时AnimatePresence配合motion.div为任务卡提供进出场动画，并且通过useReducedMotion()在用户开启"减少动态效果"时退化为纯透明度动画——这正是技能"motion 负责进出场与布局动画"的应用场景，还顺带实现了无障碍降级。同类模式还出现在 kanban-board/index.tsx、list-view/index.tsx 与 backlog-list-view/index.tsx。
zustand：跨组件共享的轻量状态
状态管理选型在仓库中同样一致。apps/web/src下的 store 目录 有 4 个 zustand store：project.ts、bulk-selection.ts、backlog-bulk-selection.ts、user-preferences.ts。以 store/project.ts 为例：
import { create } from "zustand"; import type { ProjectWithTasks } from "@/types/project"; const useProjectStore = create<{ project: ProjectWithTasks | undefined; setProject: (updatedProject: ProjectWithTasks | undefined) => void; }>((set) => ({ project: undefined, setProject: (updatedProject) => set(() => ({ project: updatedProject })), })); export default useProjectStore;对于"当前打开的项目""批量选中项"这类需要在多个组件间共享、又不值得引入重量级方案的全局状态，zustand 这种"极小核心 API + 外部 store"的形态恰到好处，对应了技能中"useState-per-component 的 props 网需要 zustand 收敛"的判断。
input-otp：验证码输入
验证码/OTP 输入是"看似简单、细节极多"的组件（自动跳格、粘贴拆分、掩码、最大长度）。仓库在 apps/web/src/components/ui/input-otp.tsx 封装了 input-otp，并在 verify-otp.tsx 的邮箱验证流程中实际使用——与技能"一次性密码输入框 → input-otp"的推荐完全对应。
shiki：编辑器里的代码高亮
任务描述的富文本编辑器（基于 Tiptap）中嵌入了代码块扩展 shiki-code-block.ts，其底层由 lib/shiki-highlighter.ts 提供高亮能力。这与技能"语法高亮 → shiki"的条目一致：shiki 基于 TextMate 语法做高亮，输出语义化的 token 着色，而不是粗暴的正则匹配。
sonner 与 cmdk：轻提示与命令交互
Sonner 的落地点包括 use-billing-actions.ts（计费操作的成败提示）、profile-setup-flow.tsx 与 onboarding-flow.tsx（引导流程反馈）；cmdk 则用于任务子任务搜索 task-subtasks.tsx、任务描述与评论编辑器 task-description.tsx、comment-editor.tsx 等处的命令式菜单交互。两者都是"高频小交互交给专用小库"策略的直接体现。
未安装项：留给未来任务的候选
对照清单可见，NumberFlow（数字动画）、torph（文字动画）、Cobe（3D 地球）、Satori（动态 OG 图）、Liveline（流式图表）、recharts（通用图表）、Virtuoso（虚拟化）、Leva（控制面板）、next-themes（主题切换）目前并未出现在 apps/web/package.json 的依赖中。这并不矛盾——技能的使用规则第 2 条本就强调"先查已装依赖、不擅自引入新库"。这些条目是为未来同类任务预留的明确答案：当 Kaneo 需要 1000 行级的长列表、实时折线图或动态 OG 图时，直接命中清单即可，无需再花时间调研选型。
常见误用模式清单：一眼识别该换库的信号
技能最后给出一组"看到这些写法就该换库"的反模式信号，是选型决策中最具操作性的部分：
- 手写 toast 或拿 modal 库做通知→ 改用 Sonner，它就是为了这个场景存在的。
- 手写
<div>下拉/弹窗 + 手工焦点管理→ 改用 base-ui，它替你处理可访问性、焦点陷阱（focus trapping）和点击外部关闭。 - 用重渲染文本的方式做数字动画→ 改用 NumberFlow，它正确处理数字位数的过渡（digit transitions）。
- 直接渲染 1000+ 行的列表→ 先上 Virtuoso 再考虑分页 Hack。
- 每个组件一个
useState、用 props 织成共享状态网→ 改用 zustand。 - 模板字符串里三层深的 className 三元表达式→ 改用 clsx（如果形状像变体，就上 cva）。
这六条的价值在于把"代码坏味道"翻译成"具体换哪个库"的可执行动作，让选型从"个人偏好"变成"可评审、可落地的工程决策"。
小结：让选型成为可复用的工程资产
从 Kaneo 的这份技能可以看出，优秀的前端选型管理不在于"知道很多库"，而在于：
- 按任务域而非按库名组织决策（原语 / 动效 / 图表 / 交互性能 / 状态样式五个域互不混淆）；
- 给出明确边界（CSS transition 与 motion 的分界、Liveline 与 recharts 的分界、clsx 与 cva 的分界）；
- 先看现状再动手（查
package.json、不擅自更换既有依赖）； - 沉淀反模式清单，让未来的维护者一眼识别该重构的信号。
仓库中的实装证明（从 Button 的 cva 变体、column-dropzone.tsx 的 dnd kit + motion 组合，到 verify-otp.tsx 的 input-otp）说明：这份清单不是纸面建议，而是被生产代码逐条兑现的选型规范。无论你是要为新功能选型，还是要评审既有代码的依赖合理性，都可以把 pick-ui-library/SKILL.md 当作团队的"前端选型宪法"来使用。
【免费下载链接】app🎯 All you need. Nothing you don't. Open source project management that works for you, not against you.项目地址: https://gitcode.com/GitHub_Trending/app116/app
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
