uni-app 组件库选型

• uni-ui：v1.5.12
• wot ui：v2.3.2
• 2026-08-20 00:34:36

uni-app 多端底层适配，性能可能会更好？

比如 SwipeAction 组件：

uniapp 在 App Vue、H5、微信小程序使用 WXS 类视图层优化，nvue 使用 BindingX，其他不支持的平台才回退普通 JS。(uniapp.dcloud.net.cn)

Wot UI v2 的 wd-swipe-action 源码使用 touchstart、touchmove、touchend 在 Vue 逻辑层计算位移，并在移动过程中获取宽度、更新 translate3d 样式，没有使用 WXS。(raw.githubusercontent.com)

所以在大列表和持续跟手操作里，uni-swipe-action 的技术路线更让人有信心。

但也不能说“整个 Wot UI 性能差”。Button、Tag、Input、Cell、Popup、Form 这些组件通常不是高频跟手计算场景， WOT UI 视觉设计统一，完整 Design Token、CSS 变量、ConfigProvider，方便定制主题接入系统， 主题定制比 uni-ui 方便很多。

以下来自Codex gpt-5.6-sol 极高推理总结：

一句话概括：

uni-ui 更像“跨端基础设施组件库”，Wot UI 更像“带完整视觉体系的产品级组件库”。

核心对比

uni-ui 的优点

• DCloud 官方维护，与 uni-app 编译器、easycom 和各小程序平台结合更紧密。
• 跨端覆盖广，支持 App、H5、nvue、各种小程序以及宽屏设备。
• 部分性能敏感组件做了平台专项处理。
• 例如 uni-swipe-action 在微信小程序、H5、App Vue 中使用 WXS 优化，其他平台提供 JavaScript 回退。
• 平台差异、状态栏、节点测量、后台资源消耗等问题，官方拥有更多处理经验。
• 适合业务功能和跨端稳定性优先、视觉要求相对一般的项目。

uni-ui 的缺点

最大问题正是目前发现的：uni-ui 没有真正意义上的统一主题系统。

uni-sass 主要是一套颜色、间距、圆角等辅助样式类，需要单独引入。它并不代表所有 uni-ui 组件都会自动读取 uni.scss 中的变量。

结合当前项目使用的 uni-ui 版本和组件源码来看：

• 项目的 uni.scss 并不是引入错了。
• 很多 uni-ui 组件根本没有读取 uni.scss 中的变量。
• 有些组件使用另一组变量，例如 $uni-primary。
• 有些组件在内部重新定义了同名变量。
• 有些颜色、字号和高度直接硬编码在组件中。
• 输入框高度、背景色、组件圆角等缺少统一配置入口。

因此，如果继续使用 uni-ui，并希望实现全量统一视觉，通常只能选择：

• 编写大量局部样式覆盖。
• 使用 patch-package 修改组件源码。
• 维护自己的 uni-ui fork。

随着组件数量和页面数量增加，后续升级和维护成本也会越来越高。

Wot UI v2 的优点

Wot UI v2 的主题系统更加符合建设统一设计系统的需求。

它的主题变量主要分为以下层级：

• 基础变量：基础颜色、字号和尺寸。
• 语义变量：品牌主色、正文色、边框色和背景色。
• 组件变量：按钮背景、Input 高度、字号、圆角和内边距等。

它支持：

• 全局 CSS 变量。
• 局部 ConfigProvider 配置。
• 组件级主题变量。
• 暗色模式。
• 国际化。

项目可以把自己的主题变量映射给 Wot UI：

page,
.wd-root-portal {
    --wot-primary-6: var(--app-color-primary);
    --wot-text-main: var(--app-text-color);
    --wot-border-main: var(--app-border-color);
    --wot-input-height: 88rpx;
}

具体组件还会提供类似下面的变量：

--wot-input-bg
--wot-input-font-size
--wot-button-primary-bg
--wot-popup-radius

这种方式比依赖组件内部 class 名进行样式覆盖稳定得多。

Wot UI v2 目前拥有较为完整的组件体系，支持微信小程序、支付宝小程序、钉钉小程序、H5 和 App 等主流平台。

Wot UI 支持 easycom

npm 安装方式可以在 easycom 中增加下面的规则：

{
    "easycom": {
        "autoscan": true,
        "custom": {
            "^wd-(.*)": "@wot-ui/ui/components/wd-$1/wd-$1.vue"
        }
    }
}

配置完成后，页面可以直接使用：

<wd-button>提交</wd-button>
<wd-input></wd-input>

因此，Wot UI 可以使用 easycom，不需要在每个页面手动导入组件。

Wot UI v2 的缺点

• 不是 DCloud 官方组件库，团队规模和长期持续维护能力无法与 DCloud 相比。
• 虽然支持主流平台，但不代表每个小程序平台都经过相同强度的验证。
• 小程序样式隔离、root-portal、弹层尺寸初始化等场景仍需特殊处理。
• 部分被移动到页面根节点的组件，可能无法自动继承外层 ConfigProvider。
• Tabs、Slider 等依赖尺寸测量的组件放在延迟渲染弹层中时，可能需要在打开后重新计算尺寸。
• 长列表滑动、SwipeAction 和复杂手势场景需要在真实设备上测试。

Wot UI 可以做到高度主题化，但也不能理解为绝对百分之百覆盖所有样式。

• Wot UI 组件自身的大部分视觉可以由主题变量接管。
• 少数组件细节仍可能需要 custom-class、custom-style 或 :deep() 覆盖。
• 页面本身、uni-app 原生组件、系统导航栏等内容仍需由项目自己的主题系统控制。

如何选择

如果项目更看重以下目标：

• 覆盖更多小程序平台。
• App 和 nvue 能力。
• 跨端稳定性。
• 性能敏感的手势组件。
• 官方长期维护保障。

那么更适合选择 uni-ui。

如果项目更看重以下目标：

• 统一品牌视觉。
• 完整的主题变量体系。
• 统一控制颜色、字号、高度、背景和圆角。
• 暗色模式。
• 更丰富、更现代的组件。
• 降低后续页面样式维护成本。

那么更适合选择 Wot UI v2。

针对当前项目的建议

当前项目的主要目标是：

• 支持 H5、微信小程序和 App。
• 建立统一的视觉设计。
• 统一控制颜色、字号、Input 高度、背景色和圆角。
• 继续对组件进行深度美化。
• PC 端基本可用即可。

基于这些需求，我更倾向于：

使用 Wot UI v2 作为主要 UI 组件库，配合 uni-app 原生组件。少数性能或平台敏感组件经过实测后，再决定是否保留 uni-ui。

现在的需求已经不只是偶尔修改主色，而是在建设项目自己的设计系统。

继续使用 uni-ui，短期迁移成本更低，但后续每增加一个页面或组件，都可能继续面对组件硬编码样式和主题变量不生效的问题。

Wot UI 初期存在迁移和跨端验证成本，但在视觉统一、主题维护和后续开发效率方面更有优势。

建议先做跨端验证

不建议立即全量迁移，可以先建立一个组件验证页面，重点测试：

• Navbar 和状态栏安全区。
• Input、Textarea、Form 和 Picker。
• Popup、Dialog 和 Toast。
• Tabs 和 Steps。
• 长列表中的 SwipeAction。
• 键盘顶起。
• 弹层滚动穿透。
• 底部安全区。
• 主题变量和暗色模式。
• H5、微信小程序和 App 的实际表现。

验证通过后，再逐步迁移当前项目使用的 uni-ui 组件。

项目规范注意事项

当前项目的 AGENTS.md 明确规定：

• UI 框架固定使用经典 npm 版 uni-ui。
• 禁止重新引入 Wot UI 或其他 UI 组件库。

这属于当前项目规范，并不是技术层面的最终结论。

如果最终决定切换到 Wot UI，需要先明确修改这条项目规范，然后再调整依赖、easycom 配置和现有页面组件。