HeroUI Pro、Mantine、shadcn 与自建组件库：从产品形态选择 React UI 体系

8月 8, 2026

AI 参与说明（Agent：Codex）：本文根据作者提出的选型问题，由 Codex 使用公开产品文档、许可证与价格页面辅助调研、整理和撰写。适用背景被抽象为通用的多产品 React 场景，未使用任何私有仓库、项目名称、内部组件、使用数量、路径、凭据或未公开计划。产品版本、价格和条款整理于 2026-08-08，后续可能变化；采购和再分发前仍应核对最新官方资料，许可证分析不构成法律意见。

先给结论#

选择 React UI 体系时，真正决定长期结果的不是“组件有多少”或“迁移要几天”，而是团队想采用哪一种产品形态：

1. 购买持续更新的成品组件系统；
2. 使用免费、由上游维护的开源 npm 组件库；
3. 取得组件源码并承担后续演进；
4. 基于无样式行为原语建立自己的设计系统；
5. 在通用 UI 之外按需购买表格、调度、编辑器等专业引擎；
6. 把组件库本身做成一个对外产品。

如果目标是让一组内部产品长期共享统一、精致的产品界面，又不想持有大量基础组件源码，HeroUI OSS + HeroUI Pro 是合理的成品系统选择。它的价值不只是高级组件数量，还包括统一主题、交互语言、模板、设计资产和持续更新的 package 交付。

如果目标是建立一个可以公开分发、允许用户选择 npm 或源码模式、未来还能销售样式包和服务的 UI 产品，那么 HeroUI Pro 不能成为这条产品线的原料。更合适的基础是 React Aria Components + 自有设计契约 + 许可证清晰的开源实现，再建立免费组件库和独立的付费增值层。

Mantine 是最强的免费、广谱 npm 替代者之一；shadcn 则代表另一种产品哲学——它不是免维护的组件依赖，而是组件源码的分发平台。两者都很好，但解决的问题不同。

本文刻意不把既有代码迁移成本作为主要判断因素。Codex、Cursor、codemod 和视觉测试已经能显著压缩 import、props、slot、样式与 Storybook 的机械迁移时间。迁移变快后，反而更应该直接比较产品形态，而不是被已有代码绑架。

AI 能降低迁移成本，但不能替代产品判断#

AI 编程工具已经很擅长处理这类工作：

• 批量替换依赖、import 和组件 API；
• 根据映射表迁移 variant、slot 和状态属性；
• 生成 codemod、Storybook stories 与基础测试；
• 对照截图修复大面积视觉差异；
• 查询当前文档并为不兼容 API 提供候选改法。

因此，“已经使用多少组件”不应该成为决定性理由。即使一个大型代码库已经深入使用某个 UI 系统，只要产品形态判断改变，迁移也可以由 Agent 分阶段完成。

但 AI 主要降低的是代码变换成本，它不会自动消除以下责任：

• 这个组件的行为契约是否符合产品需要；
• 键盘、屏幕阅读器、触摸、RTL 和国际化是否正确；
• 两个相似组件是否应该拥有相同的状态与 API；
• Data Grid 到底需要普通排序，还是分组、透视、服务端模型与 Excel 导出；
• 许可证是否允许把代码交给客户、生成到用户项目或重新发布为组件库；
• 视觉系统是否形成稳定的品牌资产，而不是一组经过 AI 修补的页面。

一句话概括：

AI 降低了改代码的成本，但没有替团队承担设计系统的产品责任。

六种 UI 产品形态#

选择错误通常不是因为某个组件“不够好”，而是把一种产品形态当成了另一种。例如，购买付费源码套件并不能得到免维护的 npm 组件系统；把 shadcn 当普通依赖使用，也忽略了它要求使用者成为源码持有者和维护者。

比较资料本身也需要区分立场。HeroUI 发布的 React UI 组件库推荐文章 可以用来建立候选目录，也准确描述了 package 与 open-code 模式的差异，但它仍是供应商内容，不是中立排名。版本、价格、许可证和能力边界应回到各产品的一手文档核验。

HeroUI Pro：购买的是“产品 UI 系统”#

HeroUI OSS v3 采用 React 19、Tailwind CSS 4、React Aria Components 和 compound component API。HeroUI Pro 则在同一视觉与行为体系上提供更高层的产品组件、主题、模板、Figma、设计系统工具以及面向 AI 编程工具的 Skills 和 MCP。HeroUI React 文档、HeroUI Pro

截至 2026-08-08，HeroUI OSS v3 已稳定，但 Pro 最新仍是 1.0.0-beta.8。官方发布记录显示，Pro 正以月度 minor 和按需 patch 的节奏增加组件、RTL、SSR、地图、Data Grid 与 AI 交互能力，并同步提高 HeroUI OSS、React Aria 和 tailwind-variants 的 peer dependency。HeroUI Pro Releases

它最适合什么产品#

HeroUI Pro 最适合：

• 同时维护多款 Web 产品，希望共享一致视觉语言的团队；
• 重视 AI、Dashboard、文件管理、导航、数据展示、聊天和编辑器界面；
• 希望基础层以 npm package 更新，而不是把几十个组件复制进仓库；
• 愿意接受一个明确的设计系统供应商，并用内部复合层承载产品语义；
• 生成物不会把 Pro 源码或受限资产继续分发给最终用户。

它购买的不是某一个 DataGrid 或 Sidebar，而是“这些组件应该如何共同构成产品”的持续意见。对于需要快速形成多产品一致性的团队，这种集中意见本身就是价值。

它不适合什么产品#

HeroUI Pro 不适合作为以下产品的直接基础：

• 对外发布的通用组件库或组件 Registry；
• 会把组件源码生成到客户项目中的 App Builder；
• 要求完全离线、无需私有下载凭据即可重建的供应链；
• 需要修改并再分发底层组件源码的白标组件产品；
• 以企业级透视表、BI、排班调度或大型数据编辑为核心的专业产品。

Pro 采用私有 package 下载和 CI/CD token，许可证允许把组件集成进最终软件，但禁止分享或再分发 Pro 源码，也禁止使用 Pro 的全部或部分内容创建与其竞争的工具、组件库或服务。HeroUI Pro Installation、HeroUI Pro Terms

价格是否值得#

2026-08-08 的官方价格为：

首次购买包含一年更新，续期不是强制订阅；停止续期后，可以继续使用更新窗口内最后有权取得的版本。团队方案按实名席位授权。HeroUI 实时价格数据、HeroUI Pro Licensing

如果团队确实需要的是前述“产品 UI 系统”，Web Hero 的价格是合理的。判断依据不应是一次迁移能否省回 $299，而应是：这个产品是否愿意长期购买 HeroUI 对视觉、组件组合和升级节奏的意见。

如果答案是否定的，即使它当前很便宜，也不应该购买。

Mantine：广谱、免费、维护型 npm 组件库#

Mantine v9.5.1 官方提供 120+ 组件和 70 hooks，覆盖表单、Overlay、日期、Tree、Spotlight、通知、富文本和图表等常见产品能力。Mantine UI 还提供免费的响应式页面区块。Mantine、Mantine UI

从产品形态看，Mantine 的优势非常清楚：

• MIT 开源；
• 组件和 hooks 覆盖广；
• 由 npm package 持续交付；
• 不需要购买私有高级组件层；
• 适合希望“一套免费库解决大多数应用 UI”的团队。

它与 HeroUI 的区别不只是外观。Mantine 拥有自己的 Provider、主题、CSS variables、Styles API、CSS Modules 和生态扩展；HeroUI 则更接近 Tailwind 4 + React Aria + compound components 的组合。选择 Mantine，意味着认可 Mantine 自己的应用框架式设计系统，而不是把它当作可随意拆出的组件来源。

如果产品希望：

• 完全使用免费开源 package；
• 获得尽可能广的常规 Web 应用覆盖；
• 不把 Tailwind utility 或 React Aria 作为设计系统的显式公共契约；
• 组件库本身不是需要对外销售的核心产品；

那么 Mantine 可能比 HeroUI Pro 更合适。

如果产品重视 Tailwind 原生扩展、React Aria 行为复用、AI 产品组件、主题资产，以及未来自建同类组件的路径，HeroUI 的形态更匹配。

shadcn：把“源码持有与维护控制”变成产品能力#

shadcn 官方明确说明，它不是传统组件库，而是“构建自己的组件库”的方法。CLI 把实际组件代码交给使用者，Registry 协议负责分发，团队可以修改任何一层。shadcn Introduction

这意味着 shadcn 的价值不在于免费替代 HeroUI，而在于：

• 组件代码可以在许可证范围内成为产品的一部分；
• App Builder 可以把源码交给最终用户；
• 团队可以建立自己的 Registry、namespace 和组件市场；
• AI 可以直接读取、修改和组合全部组件源码；
• 不需要等待上游暴露每一个 slot 或 variant。

AI 编程工具让这种模式比过去更可行。上游 diff、API 迁移和相似组件批量升级都可以自动化。但要让它成为可靠产品，仍需建立：

1. 唯一 canonical 源码；
2. 上游 commit 与许可证 provenance；
3. package 和 Registry 的同源构建；
4. slot、state、variant 与 CSS token 契约；
5. 可访问性、RTL、交互和视觉测试；
6. 用户修改后的 diff、update 与冲突策略。

这里的“控制权”不等于取得上游作者的版权。官方 shadcn 代码采用 MIT License；代码进入自己的仓库后，团队取得的是依照许可证修改、维护和再分发的权利，同时仍需保留适用的版权与许可证声明。第三方 Registry 也不能自动继承 shadcn 官方仓库的 MIT 条款，必须逐项核查来源。shadcn License

因此，shadcn 很适合两类产品：

• 明确需要“组件源码由用户持有和维护”的生成式应用平台；
• 想同时提供 npm package 和源码 Registry 的自有 UI 产品。

它不适合只想安装依赖、等待上游修复、避免维护源码的团队。

React Aria：最值得长期拥有的不是样式，而是行为契约#

React Aria Components 是无样式、可组合的 React 组件层，处理键盘、焦点、触摸、辅助技术、国际化和 Collection 等通用行为。它可以直接配合 Tailwind 或自有 CSS 使用。React Aria Components

从生态绑定角度看，它比“给每个视觉组件做一层 wrapper”更有效：

• 视觉层可以从 HeroUI 换成自有主题；
• 状态、焦点和无障碍模型仍然保留；
• 自建组件不必重新发明 Dialog、ListBox、Tree 或 Drag and Drop 行为；
• 公共组件库可以定义自己的 slot 和 variant，而不复制另一个视觉系统。

合理的优先级是：

1. 视觉系统已有能力时直接组合；
2. 视觉系统缺少行为时使用 React Aria；
3. React Aria 确实缺失或不兼容时，再比较 Base UI 或 Ark UI；
4. 表格、工作流、富文本、虚拟化等专业问题交给专业引擎。

这种分层比同时维护 Radix、Base UI、React Aria 三套基础 primitive 更容易形成稳定产品。

付费源码套件与专业引擎不是一回事#

市场上的“付费 UI”至少有两类，不能放在一起比较。

付费源码套件#

Unlumen、Untitled UI React、Tailwind Plus 等产品通常交付页面、区块、动效或组件源码。它们的优势是视觉完成度高、复制后可深度修改；缺点是源码进入项目后，维护责任仍归使用者。购买者获得的是许可证范围内的源码访问和修改权，不是底层版权。

更重要的是，再分发权通常受到严格限制。例如 Unlumen 允许在网站、SaaS 和客户项目中使用及修改组件，但明确禁止把原版或修改版组件继续发布为组件库、Registry、UI kit 或组件包；该限制同时适用于免费与 Pro 组件。Tailwind Plus 和 Untitled UI 也分别限制将其资产用于竞争性的组件库、模板或 Builder。Unlumen License、Tailwind Plus License、Untitled UI License

因此，这类产品适合最终应用，不适合成为公开组件产品或 App Builder 的上游源码。它们也不符合“只更新 npm 依赖、不维护源码”的偏好。

专业引擎#

MUI X、AG Grid、KendoReact、DevExtreme 和 Syncfusion 的核心价值，是普通 UI 库不应该重复建设的专业能力：

• 大数据量虚拟化；
• 行列固定与复杂编辑；
• 分组、树形数据和透视；
• 服务端数据模型；
• Excel 导入导出；
• Scheduler、Gantt、Diagram 和 Pivot Grid。

截至 2026-08-08，MUI X Pro 为 $299/开发者/年，Premium 为 $599/开发者/年；AG Grid Enterprise 从 $999/开发者起。MUI Pricing、AG Grid Pricing

它们应当作为“专业引擎 + 当前视觉系统适配层”出现，而不是为了一个 Data Grid 把整个产品换成 Material、Ant 或企业控件风格。

自建免费 UI 与 Pro 产品：这是商业决策，不是备份方案#

如果团队准备同时维护一个免费 UI 库和一个付费版本，首先要回答：它是否真的是一个独立产品？

如果只是担心上游停止维护，自建完整组件库往往是昂贵的保险。继续使用开源基础层、保存退出方案和控制业务耦合，通常已经足够。

如果目标是对外服务其他开发者，自建才具有战略意义。较健康的产品划分可以是：

免费层#

• 完整可用的基础组件与必要的高级组件；
• React Aria 驱动的行为和无障碍；
• npm package 作为默认维护型交付和稳定 API；
• Registry/source mode 作为可选的源码持有模式，而不是另一套平行实现；
• 公共 token、slot、state、variant 与扩展契约；
• 不故意阉割可访问性或基础能力来逼迫付费。

Pro 层#

• 高质量 style packs 和品牌主题；
• premium variants、motion presets 与复杂模板；
• Figma 和设计系统同步；
• 团队空间、权限、私有 Registry；
• 托管升级、冲突解决、迁移服务和优先支持；
• 可能的 AI 设计与代码生成工具。

这种模式的重点是：免费层出售的是信任，Pro 层出售的是完成度、协作和持续服务。 Pro 不应该只是给免费组件换一套颜色，也不应该复制一份相同基础组件后改名收费。

npm 与源码双交付如何避免失控#

双交付可以形成差异化，但必须只有一份 canonical 实现：

flowchart LR
    source["Canonical component source<br/>行为、slots、states、tests"]
    package["npm package<br/>默认维护型消费"]
    registry["Registry / source mode<br/>用户选择源码持有"]
    pro["Pro 增量资产<br/>主题、模板、工具、服务"]

    source --> package
    source --> registry
    source --> pro

package 和 Registry 不应各维护一套组件。Registry item、依赖元数据和源码文件应该由同一 canonical source 生成；package 应作为默认产品契约，Registry 只提供明确支持的源码模式和可 eject 组合。Pro 只在此基础上增加合法、独立的资产和服务。

推荐的双轨架构#

对于一个既维护内部产品，又准备建立公开 UI 产品的团队，最清晰的结构不是把所有需求塞进一个库，而是维护两条边界明确的轨道：

内部产品轨可以采用 HeroUI OSS/Pro，也可以在产品目标更匹配时整体采用 Mantine。关键是只保留一个 canonical 视觉系统，不在同一产品中同时引入 HeroUI、Mantine、MUI Core 和 Ant Design 的全套主题。

公共 UI 产品轨应建立严格的实现隔离流程：只使用公开 API、自有设计和许可证允许再分发的来源，并为每个组件保留 provenance、设计记录和许可证说明。购买 HeroUI Pro、Unlumen 或其他付费源码，并不自动赋予将其包装成另一个组件库的权利。

这种隔离常被称为 clean-room，但它只能降低受限源码或资产污染的风险，不能自动消除合同中的竞争限制。如果同一团队一边使用商业组件，一边准备发布功能范围相近的公共或付费 UI 产品，发布前仍应向供应商取得书面确认，并在必要时接受独立法律审查。

两条轨道可以共享产品经验，但不应共享受限源码、私有主题、资产或逐项复刻的实现。公共 UI 产品成熟后，可以先在自身网站和一个独立示例应用中 dogfood，再决定是否成为其他产品的新默认值。

“HeroUI 扩展契约”应该约束什么#

即使选择成品系统，也不应把所有产品状态塞进供应商组件。一个可执行的扩展契约至少包括：

1. 基础组件直接使用：不要为每个 Button、Input、Dialog 建立无语义 wrapper。
2. 复合组件才进入共享层：只有跨产品复用的 App Layout、Prompt Composer、File Browser、Property Editor 等产品模式进入内部复合层。
3. 业务状态外置：领域对象、表格列模型、工作流节点和权限判断独立于视觉组件。
4. 只使用公共扩展点：通过 compound API、slots、class names、variants 和 semantic tokens 扩展，不依赖私有 DOM 结构。
5. 专业能力单独适配：Grid、Flow、Editor、Tree 和 Virtualizer 保持引擎边界，不把引擎 API 泄漏成全局设计系统 API。
6. 一致性不只检查颜色：同时验证 token、空间节奏、交互状态、动画、API、无障碍和国际化。

具体实现可以按四级路径递进：

1. 纯组合现有组件；
2. 使用官方 variant/slot 能力对齐外部元素；
3. React Aria 行为 + 当前设计系统 token；
4. 专业引擎 + 当前设计系统适配层。

这个契约的目的不是伪造“零供应商绑定”，而是确保真正有价值的产品状态和行为不会被某个视觉 package 吞没。

按产品目标做最终选择#

最终判断#

HeroUI Pro 是否值得购买，不能用一个全局的“是”或“否”回答：

• 对需要成品化、多产品一致性和 package 更新的内部产品体系，值得；
• 对希望完全免费、广覆盖的常规应用，Mantine 可能更合适；
• 对需要源码持有、生成应用或经营组件 Registry 的产品，shadcn 模式更合适；
• 对准备经营自己的 UI 产品的团队，React Aria 和自有设计契约比任何付费视觉库更重要；
• 对专业数据和编辑场景，应该购买专业引擎，而不是期待通用 UI 库解决全部问题。

AI 已经让迁移和源码维护更便宜，因此没有必要因为历史代码而坚持一个不匹配的体系。但同样不能因为 AI 能生成组件，就低估设计、许可证、可访问性、测试和生态支持的长期责任。

更稳健的产品策略是：

内部产品购买成熟意见，公共产品拥有核心契约；通用视觉交给一个 canonical 系统，专业能力交给专业引擎，源码持有只用在真正形成差异化的地方。

参考资料#

• HeroUI React Documentation
• HeroUI React Releases
• HeroUI Pro
• HeroUI Pro Live Pricing
• HeroUI Pro Releases
• HeroUI Pro Licensing
• HeroUI Pro Terms & Conditions
• Mantine
• Mantine UI
• shadcn/ui Introduction
• React Aria Components
• MUI Pricing
• AG Grid Pricing
• Unlumen License
• Tailwind Plus License
• Untitled UI License