企业后台架构改造：公共宿主、独立应用与业务 SDK

业务范围扩大后，集中式后台的改动、发布与维护成本持续上升。

我加入时，前端资源分散于不同部门，页面模型与交互能力分别建设。随着业务域、终端形态和参与团队增加，集中式后台的改动与发布成本持续上升，重复页面与分散的交易流程也增加了维护负担。

改造未采用整体重写，而是根据复用价值、发布方式与维护责任划分公共能力和业务边界。以下六个项目说明相关方案在生产环境中的具体应用。

公共宿主统一处理导航、权限与装载，业务应用保持独立开发、发布和回滚。

2020 年，我完成统一宿主与业务应用的核心设计，明确导航、权限、路由、应用装载和跨应用通信的职责；随后带领团队完成基础能力建设与存量页面迁移。

存量应用可分阶段迁移，新应用可独立部署和回滚，日常业务迭代无需频繁修改公共宿主。该架构目前仍在生产环境中使用，后续财务项目也沿用了相关设计。

• 技术：React · Module Federation · Node.js · CI/CD
• 职责：架构设计 · 关键代码 · 接入约定 · 发布流程

宿主统一管理页面栈、浮层和出入场，业务页面聚焦数据、校验与业务交互。

2019 年底开始验证方案后，我在 2020 年完成 src_v3 的核心设计，同时保留原有 Redux 业务层。旧版需要在中心路由和 reducer 中逐项注册页面，并由各页面分别处理数据与侧栏状态；新版按目录发现页面，通过 Context 提供根级共享状态和统一的 Presenter / Modal 接口。

设计确定后，我带领团队迁移页面并补齐相关能力。App 统一管理页面层级、关闭流程与动画结束后的清理，后续增加从 URL 恢复页面层级和查询条件的能力；新旧入口并行运行，迁移过程未中断存量业务。

在同类需求中，两个页面的开发周期从 5 个工作日缩短至 2 个工作日，周期缩短 60%。减少的工作主要包括页面注册、浮层实现、出入场控制与宿主状态接入，开发时间可集中于数据、校验和业务交互。

• 页面接入：按目录发现页面，减少中心路由中的重复注册
• 共享状态：rootState / setRootState 补充宿主级状态，不替代原有 Redux 业务层
• 叠层接口：presenter.push / hide · modal.push / hide
• 生命周期：willEnter · didEnter · willLeave · didLeave 由通用层统一处理
• 迁移方式：新旧版本并存，按页面逐步切换，不中断存量系统

数据分析、资源管理与配置工具独立部署，并接入不同后台。

我为多个企业后台设计并开发可嵌入的运营页面。页面按业务域独立构建，公共请求层处理状态、错误、下载与异步任务，适配层处理不同宿主的运行差异。

新页面按目录约定接入，无需继续扩展中心配置；同一页面可接入多个后台，并保持独立发布。

• 技术：React · TypeScript · Webpack · Axios
• 职责：架构设计 · 核心开发 · 长期维护

以稳定接口封装完整业务页面，调用方无需了解内部实现。

我设计了一套前端 SDK，统一完整业务页面的渲染生命周期、输入参数与事件回传。调用方仅需提供容器、运行环境和业务参数。

多个业务包由同一 monorepo 管理，共用构建与本地调试工具，同时保留各自的参数模型、功能与版本，避免在不同系统中重复实现业务逻辑和环境适配。

• 技术：JavaScript · Webpack · Monorepo
• 职责：SDK 设计 · 构建工具 · 核心开发 · 版本管理

统一 Web 与小程序的支付流程、状态和接入方式。

不同宿主、终端和支付渠道存在差异，交易流程又包含多个异步阶段。分别实现会导致状态、回调与异常处理逐步分化。

我负责收银接入层的关键改造，将流程状态、渠道适配、结果查询和页面渲染分离，并统一输入、输出、回调与错误格式；渠道差异集中由适配层处理。

• 技术：React · Taro · Webpack 5 · Rollup
• 范围：多种 Web 形态 · 主流小程序平台

统一组织业务单据、审批、结算和财务结果的处理流程。

我负责平台早期的前端架构与关键交互。系统将多来源业务单据接入审批、调整、结算与分析流程，减少在线下表格和多个系统之间的重复核对。

功能按业务对象和处理阶段组织；用户打开详情或审批任务时，列表上下文仍然保留。统一的页面约定也便于团队继续扩展模块。

• 技术：React · Webpack · Axios · 内部设计系统
• 职责：架构设计 · 关键代码 · 团队开发

将常用交互、设计变量和文档整理为可复用组件包。

我发起并搭建设计系统，将表格、表单、筛选、导航与反馈实现为带类型约束的 React 组件，并通过设计变量统一颜色、状态和布局。

组件、示例和文档按版本发布，变更通过预览与检查进行验证。多个财务与运营后台可复用同一套组件。

• 技术：React · TypeScript · Less · Storybook
• 职责：项目发起 · 初版搭建 · 设计变量 · 日常维护

我基于存量系统的实际约束设计新架构，明确页面模型、宿主接口、叠层生命周期与分阶段迁移方式。设计确定后，我带领团队完成任务拆分、关键代码实现、代码评审和页面迁移。

• 完成 src_v3 核心架构及宿主、页面、Presenter / Modal 的责任边界设计
• 实现关键链路，并带团队完成页面迁移和缺失功能
• 将分散的开发方式统一到接入约定、方案评审和 Code Review
• 完善版本管理、发布回滚和日常质量检查

业务应用和页面可独立发布，公共部分通过 SDK、适配层和组件复用，渠道与宿主差异集中于明确的适配位置。该架构目前仍在运行，后续财务项目也继续使用。

内部业务数据无法公开，因此本案例仅陈述本人直接参与并在生产环境中持续维护的工程结果。

独立应用会增加版本兼容、跨应用通信和公共组件升级成本，因此并非所有页面都适合拆分。边界选择主要依据独立发布需求、复用价值与维护责任。

支付和财务场景仍需严格的权限、审计与异常处理；前端接口统一不能替代业务合规要求和服务端校验。