ToB 系统设计需要考虑的因素
ToB 系统设计 ≠ 页面好不好看，而是围绕「业务复杂性、权限、稳定性、可扩展性、可维护性」来设计的工程体系。
一、ToB 系统和 ToC 的本质差异
| 维度 | ToB | ToC |
|---|---|---|
| 用户量 | 少 | 多 |
| 使用频率 | 高频、长时间 | 碎片化 |
| 关注点 | 稳定、效率、可配置 | 体验、流畅 |
| 业务 | 复杂、多角色、多流程 | 简单、单路径 |
| 需求变更 | 定制化强 | 相对统一 |
ToB 系统的第一原则：可控、可扩展、可配置
二、核心设计维度
1️⃣ 业务建模
ToB 系统的本质是业务系统，不是页面集合。
要考虑：
- 业务实体如何抽象（用户 / 组织 / 项目 / 订单 / 资源）
- 状态流转是否清晰（状态机）
- 是否支持多流程并行
常见设计：
- 领域模型（Domain Model）
- 状态机驱动 UI
- 表单 = 配置 + 规则，而不是写死
2️⃣ 权限与角色体系
ToB 权限一定不是：
“登录 / 未登录”
而是：
常见模型：
- RBAC（角色权限）
- ABAC（属性权限）
- 角色 + 数据权限
前端要考虑：
- 菜单权限
- 按钮权限
- 接口权限
- 数据可见范围
用户 → 角色 → 权限点 → 页面 / 接口 / 数据3️⃣ 系统稳定性 & 可恢复能力
ToB 特点：
- 一次操作影响很大
- 出错成本高
必须考虑：
- 防误操作（二次确认、撤销）
- 操作可回滚
- 表单自动保存
- 接口重试 & 幂等
前端层面：
- Loading 防抖
- 提交锁
- 错误兜底页面
4️⃣ 可配置 & 可扩展能力
ToB 系统 80% 的需求来自「变化」
典型需求：
- 不同客户字段不同
- 表单流程不同
- 校验规则不同
- 页面模块不同
常见方案：
- JSON Schema 驱动表单
- 配置化页面（低代码）
- 插件化架构
UI = 渲染引擎 + 配置 + 业务插件5️⃣ 复杂交互 & 高效操作
用户特征：
- 每天用 8 小时
- 熟练用户
设计重点：
- 批量操作
- 快捷键
- 表格性能
- 快速筛选
ToB 系统允许“丑”，但不允许“慢”
三、架构层面的设计
6️⃣ 工程架构
必须考虑：
- 模块拆分
- 权限隔离
- 多团队协作
常见方案：
- Monorepo
- 微前端（乾坤 / Module Federation）
- 插件系统
7️⃣ 状态管理策略
ToB 的状态特点：
- 状态多
- 生命周期长
- 跨页面
| 状态类型 | 方案 |
|---|---|
| 本地 UI 状态 | useState |
| 页面级 | Zustand / Redux |
| 全局业务态 | Redux / MobX |
| 服务端状态 | React Query |
8️⃣ 性能与大数据量处理
高频场景：
- 大表格
- 实时数据
- 长列表
常见优化：
- 虚拟滚动
- 分页 / 游标
- Web Worker
- 节流批量更新
四、运维 & 交付能力
9️⃣ 可观测性
ToB 系统必须可追踪
- 日志
- 操作审计
- 用户行为记录
- 错误定位
🔟 多环境 & 灰度能力
- 多租户
- 多环境
- 灰度发布
- Feature Flag