一、设计背景
随着公司业务线与项目数量的持续增长，前端不再是单一应用的交付工具，而逐渐演变为多业务、多终端、多团队协作的复杂工程体系。如果仍以“项目为中心”进行建设，容易产生以下问题：
- 技术栈割裂、重复选型
- 公共能力无法复用
- UI 体验不一致，维护成本高
- 架构升级成本随项目数线性甚至指数增长
因此，我们引入前端中台化 + 分层架构设计，将“共性问题前移、能力下沉、业务上浮”，构建可持续演进的前端平台。
二、总体设计原则
我们的前端中台分层设计遵循以下核心原则：
- 单向依赖原则
上层可以依赖下层，下层不感知具体业务。 - 能力前移、业务后置
越靠近底层，越偏向稳定、通用、长期复用能力。 - 最小抽象原则
中台只沉淀“已经被多项目验证的共性能力”。 - 可替换与可演进
任一层都可以在不影响整体架构的前提下独立升级。
三、前端中台分层总览
整体架构自下而上可分为 六个核心层级：
- 工程与治理层（Foundation）
- UI / Design Token 层
- 基础能力层（Core Abilities）
- 业务能力层（Business Domain）
- 应用层（Applications）
- 交付与运营支撑层
每一层职责清晰、边界明确，共同构成前端中台的完整能力闭环。
四、各层级详细设计
1️⃣ 工程与治理层（Foundation Layer）
定位：前端中台的“地基”
该层解决的是“如何高效、稳定、可规模化地开发前端项目”。
核心能力包括：
- Monorepo 工程体系（Turbo / pnpm）
- 多项目目录规范与依赖约束
- 统一构建工具链（Vite / Webpack 封装）
- 代码规范（ESLint / Prettier / Commitlint）
- 多端工程适配策略（Web / H5 / 小程序 / UniApp）
设计目标：
不论新建多少项目，工程体验保持一致。
2️⃣ UI / Design Token 层
定位：设计与研发之间的“契约层”
通过 Token 化方式，将设计语言从“视觉稿”转化为“工程资产”。
核心能力包括：
- 基础 Token（Color / Font / Spacing / Radius）
- 语义 Token（Primary / Success / Warning / Error）
- 组件 Token（Button / Card / Modal 等）
- Token 自动生成（CSS Variables / JS / 多端映射）
设计目标：
UI 风格可统一、可切换、可规模化维护。
3️⃣ 基础能力层（Core Abilities Layer）
定位：全公司前端的“通用能力库”
该层不感知业务语义，只提供可复用的技术能力。
核心能力包括：
- 通用 Hooks / Utils
- 网络请求与数据层封装
- 权限、路由、状态管理基础能力
- 多端适配工具与桥接能力
设计目标：
所有项目都能直接复用，不因业务差异而分叉。
4️⃣ 业务能力层（Business Domain Layer）
定位：可复用的“业务积木”
该层沉淀经过验证的业务模型与组件，而非页面级逻辑。
核心能力包括：
- 业务组件（如用户选择器、支付模块）
- 业务流程封装（下单、审批、配置流程）
- 领域服务（订单、商品、会员等）
设计目标：
新业务通过组合，而不是从零开发。
5️⃣ 应用层（Applications Layer）
定位：面向用户的最终交付层
应用层只做三件事：
- 业务编排
- 页面组合
- 产品逻辑实现
特点：
- 不包含基础设施代码
- 不定义设计规范
- 尽量薄、尽量简单
6️⃣ 交付与运营支撑层
定位：保障中台长期稳定运行
该层横向贯穿所有层级。
核心能力包括：
- CI / CD 自动化发布
- 版本管理与变更日志
- 性能指标（Web Vitals）
- 错误监控与日志系统
- 内部组件与能力文档站
五、分层架构带来的价值
- 研发效率提升：新项目从“搭建工程”变为“组装能力”
- 体验一致性增强：UI 与交互不再因项目而割裂
- 架构可演进：技术升级不再牵一发而动全身
- 组织协作优化：明确“谁该关注什么问题”
六、结语
前端中台不是为了“集中”，而是为了解耦与规模化。
通过清晰的分层架构，我们将复杂问题拆解到正确的层级，使前端工程能够像平台一样持续生长，而不是随着项目结束而消失。
这不仅是一套技术架构，更是一种长期可持续的工程组织方式。
