React 项目实践

如何把遗留 React 应用渐进式迁移到现代架构？

迁移的目标不是一次性重写，而是在业务持续交付中逐步降低风险和旧架构的约束。

适合阶段：资深前端 / 技术负责人核心能力：迁移策略 · 风险控制 · 组织协作

面试官想考什么

• 为什么不直接重写？ 考察成本和风险判断。
• 如何划分迁移边界？ 考察领域和依赖分析。
• 如何保证新旧代码共存？ 考察兼容层和发布策略。
• 如何证明迁移有收益？ 考察指标和复盘能力。

一句话回答

遗留 React 迁移应先建立基线和约束，按路由或领域渐进替换，通过适配层、契约测试、灰度和回滚控制新旧系统共存风险。

面试回答详解

1. 先盘点而不是先升级

记录 React、路由、状态库、构建工具、浏览器支持、第三方依赖、错误率、构建时间、bundle 和关键用户旅程。识别高耦合模块和不能一次变更的边界。

2. 选择迁移切片

优先选择边界清晰、收益明显、流量可控的领域或路由。通过 adapter 隔离旧 API 和新模块，避免新代码直接扩散旧模式。组件库和请求层可以作为横向基础设施逐步替换。

3. 控制共存风险

新旧状态不能同时成为事实来源；定义数据归属和同步方向。路由、样式、埋点和错误监控要支持两套实现。契约测试保证接口、事件和权限行为一致。

4. 迁移验收

除了版本升级成功，还要看构建、bundle、Web Vitals、错误率、开发效率、缺陷率和发布回滚。迁移计划应有 kill switch、旧模块保留周期和明确删除条件。

可直接背诵的 30 秒回答

我不会从全量重写开始，而是先盘点版本、依赖、耦合、性能和关键用户旅程，建立基线。然后按路由或领域切片，通过 adapter 和契约测试让新旧实现共存，先迁移边界清晰、收益可见的模块。发布配合灰度、feature flag 和回滚，最后用错误率、构建、性能和交付效率证明迁移收益。

扩展知识

迁移阶段

盘点基线 -> 划分切片 -> 建立适配层 -> 双轨验证
-> 灰度发布 -> 扩大流量 -> 删除旧实现

面试官追问链

追问一：什么时候值得全量重写？

• 考察点：是否会做经济性判断。
• 回答方向：只有旧系统无法继续承载安全、性能、交付或运行时要求，且领域边界和资源足够清晰时才考虑；仍应拆分可验证阶段。

追问二：新旧状态不一致怎么办？

• 考察点：是否理解双写风险。
• 回答方向：明确唯一事实来源，使用 adapter 或事件同步；避免长期双写，给出冲突检测、回滚和删除旧状态的时间表。

追问三：迁移指标如何设计？

• 考察点：是否能量化技术收益。
• 回答方向：技术指标看构建、bundle、错误和 Web Vitals，交付指标看开发周期、缺陷率、回滚率和新功能接入成本。

推荐阅读

• React Upgrade Guide
• React lazy
• React 项目实践