一次代码，多端运行：H5 + 小程序的复用实践

wuwenzen@outlook.com (wuwj) — Sat, 23 Jan 2021 00:00:00 +0000

多端已经是老话题了：

产品想要 H5 + 小程序 + 后面可能再来个 App；
但人手并不会随平台数量线性增加。

所以问题就变成了：

能不能尽量做到：一套业务逻辑，多端复用，只在各端做少量适配？

这篇文章从一个实际项目出发，聊聊我是怎么拆分层次、抽象业务核心、隔离端能力差异，让 H5 和小程序在同一套代码下运行得比较舒服。

1. 能复用和不能复用的先分清

先别谈框架，先想清楚几件事：

通常可以复用的：

业务模型：订单、用户、商品这些核心数据结构；
领域逻辑：状态流转、金额计算、表单校验等纯逻辑；
接口层：请求参数组装、响应数据提取、错误码处理；
公共工具：日期、金额、校验、格式化等。

通常不能直接复用的：

UI 组件和布局（DOM vs 小程序组件）；
路由与页面生命周期；
存储层（localStorage vs wx.setStorage 等）；
原生能力（扫码、相册、位置等）。

所以设计时的目标是：

把「业务核心」从这些平台差异里剥离出来，用一层「适配器」去对接不同端能力。

2. 目录与分层：core + adapters

我们当时的多端项目采用的是类似 Monorepo 的结构：

project-root
├── packages
│   ├── core          # 端无关的业务核心（可被多端复用）
│   ├── h5            # H5 端工程（Vue/React 等）
│   └── miniapp       # 小程序端工程（uni-app / Taro / 原生）
└── package.json

2.1 `core` 里放什么？

核心模块大致有：

models/ —— 订单、用户等类型定义和基础逻辑；
services/ —— 业务服务，比如下单、取消订单、查询列表；
apis/ —— 针对后端的 API 封装（不依赖具体请求实现）；
utils/ —— 工具方法。

关键点是：core 不能直接用浏览器 API 或小程序 API，一旦用了就失去可复用性。

代码复用 on Saiga

一次代码，多端运行：H5 + 小程序的复用实践

1. 能复用和不能复用的先分清

2. 目录与分层：core + adapters

2.1 core 里放什么？

2.1 `core` 里放什么？