🚀 从 Ant Design Pro 到多端架构：一套可落地的前端平台化方案
一、背景：为什么我要“推翻重来”
我原本有一套基于 Ant Design Pro 的 Web 系统。
随着业务发展，逐渐遇到几个典型问题：
- ❌ Web 项目结构越来越重，难以扩展
- ❌ 无法支撑多端（小程序 / App / H5）
- ❌ UI 强绑定，复用困难
- ❌ 业务逻辑散落在各个页面中
与此同时，新的需求已经很明确：
我需要一套能够同时支撑：
- 微信小程序
- 混合 App（H5）
- 桌面 Web
- 移动 Web
并且：
既要统一体验，又要保证各端性能最优
这意味着一个关键问题：
❗前端多端架构，究竟应该如何设计？
二、误区：跨端框架并不是答案
在调研阶段，我首先考虑的是常见方案：
- Taro
- uni-app
- React Native / Flutter
但最终我放弃了这些方案，原因很明确：
1️⃣ UI 强行复用，带来长期维护灾难
“一套代码，多端运行” 本质是伪命题
不同端：
- 渲染机制不同
- 交互模型不同
- 性能瓶颈不同
👉 强行统一 UI，代价是：
- 复杂度指数上升
- Debug 成本极高
- 体验不可控
2️⃣ 框架锁死，技术演进受限
一旦绑定跨端框架：
- 技术升级受限
- 生态依赖严重
- 难以按需优化
✅ 最终结论：
多端统一的关键，不是 UI 复用
而是：逻辑与规范的统一
三、核心思路：分层 + 解耦
我最终采用了一套“前端平台化架构”：
UI层（各端独立实现）
↓
业务层（modules，共享）
↓
服务层（services，共享）
🔥 关键思想：
| 层级 | 是否复用 | 说明 |
|---|---|---|
| UI | ❌ 不复用 | 各端独立实现 |
| 业务逻辑 | ✅ 复用 | 核心资产 |
| API层 | ✅ 复用 | 数据统一 |
| 设计规范 | ✅ 复用 | 体验统一 |
📌 本质上，这是一种：
前端版的“Clean Architecture”
四、工程落地：Monorepo 架构
为了实现真正的复用，我采用了 Monorepo：
repo/
├── apps/
│ ├── web # Next.js
│ ├── mini # 小程序
│ ├── app # H5（App壳）
│
├── packages/
│ ├── services # API层（OpenAPI生成）
│ ├── modules # 业务逻辑
│ ├── request # 跨端请求适配
│ ├── shared # 工具函数
│
├── design-system/
│ ├── tokens
│ ├── foundations
│ ├── patterns
为什么选择 Monorepo？
因为它天然解决了：
- 代码复用
- 版本一致性
- 类型共享
- 跨项目协作
五、关键设计一：API 层（services）
API 层完全基于 OpenAPI 自动生成：
后端 → OpenAPI → 自动生成 TS services
优势：
- 类型安全
- 零手写接口
- 自动同步后端变更
⚠️ 关键点：
必须抽象 request 层：
Web → fetch / axios
小程序 → wx.request
否则无法跨端运行。
六、关键设计二：业务层（modules）
这是整个架构的“核心”。
📦 结构设计：
modules/
├── user/
│ ├── model.ts
│ ├── service.ts
│ ├── hooks.ts
│ ├── store.ts
🔥 核心原则：
modules = 前端领域层（Domain Layer）
必须保证：
- ❌ 不依赖 UI
- ❌ 不依赖平台 API
- ✅ 只包含业务逻辑
举个例子：
export function useUser() {
const user = ref(null)
async function fetchUser() {
user.value = await getUser()
}
return { user, fetchUser }
}
👉 不同端可以用不同方式消费：
- Web：React hooks / Zustand
- 小程序：自定义状态管理
七、关键设计三：Design System
很多人以为 Design System = UI组件库，这是误区。
我的设计：
design-system/
├── tokens # 设计变量
├── foundations # 基础规则
├── patterns # 设计模式
🔥 最重要的是：patterns
例如：
列表页必须包含：
- 筛选区
- 列表区
- 空状态
- 错误态
👉 不同端实现不同：
- Web → React
- 小程序 → WXML
但体验一致 ✅
八、小程序策略：不做跨端
小程序采用：
✅ 原生开发
❌ 不使用 Taro
原因：
- 性能最优
- 能力最完整
- 可控性最高
复用内容：
- services
- modules
九、Web 重构方案
不再使用 Ant Design Pro，原因：
- 过重
- 设计受限
- 难以统一多端风格
新方案：
Next.js + Tailwind CSS + 自建组件体系
目标：
- UI 完全可控
- 支持 Design System
- 可迁移到 H5
十、最终认知总结
这套架构的核心不是技术选型，而是认知升级：
❌ 错误方向：
试图用一个框架统一所有端
✅ 正确方向：
用分层架构统一“逻辑”
用设计系统统一“体验”
🔥 一句话总结：
多端统一的关键，不是代码复用
而是：边界清晰 + 抽象合理
十一、架构本质
如果用一句话定义这套系统：
这不是一个前端项目
而是一个前端平台（Frontend Platform）
十二、后续演进方向
这套架构还可以继续演进：
- 微前端（多团队协作）
- BFF 层（服务聚合）
- SSR + Edge 渲染
- Design Token 自动同步多端
结语
这次重构让我最大的收获不是技术，而是一个认知转变：
前端的复杂度，不在于写页面
而在于如何组织代码
如果你也在做多端项目，希望这篇文章能帮你少走一些弯路。
