近期内外网都在讨论框架与组件。组件库选型会影响页面开发方式、样式维护成本，以及后续替换组件的范围。本文整理调研和团队实践中需要确认的条件、候选库与落地方式。
组件库需要覆盖的约束
组件库除提供控件外，还会规定交互行为、样式组织与扩展方式。选型时需要逐项确认：
- 可访问性：键盘操作、ARIA 属性和焦点管理由库提供到什么程度；业务封装后是否仍可保持这些行为。
- 可定制性：主题、Design Tokens、CSS 变量和 Tailwind 是否能共同使用，覆盖样式时是否需要依赖不稳定的选择器或优先级规则。
- 维护与生态：维护活跃度、版本发布节奏与周边社区能否满足项目需要。
- 国际化与 RTL：长文案、日期和货币格式是否可处理；布局能否在 RTL 语言下翻转。
- 性能与 SSR：是否支持 Tree-shaking、服务端渲染；组件与样式引入后增加的体积是多少。
组件职责与依赖边界
界面代码可分为三层：UI 原子层提供输入、选择、弹层等通用交互；业务组件层组合原子组件并处理业务规则；页面装配层组织数据与业务组件。底层组件库应主要位于 UI 原子层，避免页面直接依赖特定库的 API。
在样式方案确定前，先定义颜色、字号、间距等 Design Tokens，并同时提供 CSS 变量与 Tailwind 映射。这样主题切换和组件封装使用同一组值；替换底层控件时，也无需把样式值从页面中逐处迁移。
数据请求、路由和表格等问题不由原子组件库处理。TanStack 可负责数据与路由相关能力，Radix 或 Headless UI 可负责交互原子；它们的职责不同，可以按页面需求组合。对于无法满足需求的控件，适配层应允许以自研实现替换，而不要求页面改写调用方式。
候选库的使用范围
- Headless UI：提供无样式的交互组件，可与 Tailwind 搭配实现表单和交互。使用前仍需验证所需控件及定制方式是否覆盖项目场景。 https://headlessui.com/react/input
- DaisyUI：以 Tailwind 插件提供主题和样式集合，适合需要快速获得统一样式的页面。接入前应检查定制需求与无障碍实现是否符合要求。 https://daisyui.com/docs/intro/
- Radix UI：提供可访问性相关的基础原语，并支持组合和 CSS 变量。适合需要自行定义视觉样式、同时复用交互行为的项目。 https://www.radix-ui.com/
- TanStack：包含 Query、Router、Table 等工程库，不是 UI 组件库。它可与原子组件库组合，用于数据密集页面。 https://tanstack.com/
- MagicUI：包含动效和营销展示组件，可用于官网或活动页的局部展示。 https://magicui.design/docs/components
- Aceternity UI：包含卡片、悬浮等视觉组件。适合局部展示；主流程使用前需确认交互、一致性和维护要求。 https://ui.aceternity.com/components/card-hover-effect
- ReactBits：提供场景化组件片段，例如
model-viewer，可按具体需求取用。 https://reactbits.dev/components/model-viewer
按页面类型组合
企业后台或运营系统可使用 Radix UI + Tailwind + TanStack Table/Query：Radix UI 处理基础交互，Tailwind 提供样式实现，TanStack 处理表格和数据请求。
表单或流程页面可使用 Headless UI + React Hook Form + Zod，并按页面需求引入组件。该组合分别处理交互、表单状态和数据校验。
官网或营销页可在 Tailwind 基础上使用 MagicUI 或 Aceternity 的展示组件。动效组件应限定在展示区域，不能改变主流程的可访问性和交互一致性。
接入与迁移
先输出 Design Tokens 的 CSS 变量和 Tailwind 映射，再建立 ui/atoms 与 ui/molecules。页面通过这两层使用组件，底层库的属性、样式覆盖规则和兼容处理集中在适配层。
现有页面迁移可先处理输入框、选择器和弹层，再处理表格、树等交互和状态更多的组件。每个阶段都需要检查国际化文案溢出、RTL 布局翻转，以及键盘焦点、快捷键和 ARIA 属性；这些检查应进入发布清单。
Tailwind 与组件库内置样式的覆盖顺序必须在接入前约定，否则业务页面会通过提高选择器优先级解决局部问题，后续主题或库版本更新时难以定位覆盖来源。还需要跟踪 Radix 和 TanStack 的破坏性更新及 SSR 兼容性。数据密集页面可优先使用 TanStack Table；虚拟滚动和列拖拽等复杂交互仍需按实际实现验证。
选择的依据
需要长期维护且包含复杂交互的项目，可以将 Radix UI + Tailwind + TanStack 作为候选组合：交互原语、样式实现和数据能力分别由不同库承担。以表单为主且需要尽快搭建页面时，可评估 Headless UI 与表单校验方案的组合。官网页面可以额外引入 MagicUI 或 Aceternity 的展示组件。
具体选择仍取决于组件覆盖范围、主题实现、SSR、国际化和无障碍要求。无论底层库如何确定，先定义主题机制并通过适配层隔离库 API，能够把后续扩展或替换限制在组件层。
