项目深挖：ERP App 的 React Native 架构迁移

这篇文档用于面试复习。只讲自己能确认的事实：项目目标、负责范围、迁移中的问题、验证方式和上线结果。AI 可以作为实现工具，但不能替代对方案和结果的理解。

一句话定位

这是一个持续迭代近三年的企业级 ERP 移动应用，覆盖采购、销售、财务、客户、供应商、后勤和 OA 等业务域。我的核心工作不是单纯开发页面，而是负责客户端架构演进、基础能力建设和跨版本交付。

面试时可以先说：

我负责 ERP App 的客户端架构和持续交付。项目从旧版 React Native 工程迁移到 RN 0.86 新架构，重点解决 OTA、异常监控、依赖兼容和多平台发布问题，同时保证原有接口和核心业务流程不变。

为什么要迁移

旧工程的业务已经稳定，但工程能力逐渐成为瓶颈：

OTA 接入成本高，业务代码修复需要等待应用商店审核。
线上异常缺少统一的版本、设备和请求上下文，定位依赖用户描述。
旧版依赖和导航框架对新 iOS 版本的兼容性不足。
启动、网络、推送和消息通知等基础能力与业务页面耦合，继续扩展的成本越来越高。

迁移的目标不是为了追新版本，而是建立一套能持续交付的客户端基础设施。

迁移范围

这次迁移涉及：

React Native 0.72.5 升级到 0.86。
React 18 升级到 19。
React Navigation 6 升级到 7。
约 850 个页面文件和业务模块迁移到新工程。
启动、网络、推送、消息通知等基础能力抽离。
继续复用原有接口协议，减少服务端和业务数据变化。

RN 0.86 默认处于 New Architecture 体系，迁移时需要按 Fabric 兼容性重新检查第三方组件和 Native Module。这里的“新架构”应明确指 RN New Architecture，而不是泛泛地说“换了一个 RN 版本”。

我怎么拆迁移工作

先迁基础能力

先验证启动、导航、网络、存储、推送和消息通知，再进入业务页面。基础能力如果没有稳定，后面的页面问题很难区分是业务回归还是工程底座问题。

再按模块迁移

旧项目已经把公共组件、业务组件和页面模块分离，因此迁移时可以按业务域逐步推进。迁移过程中保持接口协议不变，主要观察页面渲染、导航、原生能力和系统行为是否发生变化。

处理依赖兼容

第三方依赖分成三类：可以直接升级的、自研组件需要适配的、没有稳定新架构支持需要替换的。典型问题包括：

第三方下拉刷新组件在 Fabric 下不可用，Android 侧改用官方刷新能力，iOS 侧保留交互并重写样式。
原有 FastImage 的 loading 效果在新架构下失效，图片区域出现渲染异常，最后替换为兼容性更好的图片组件，并重新验证占位、缓存和失败状态。
React Navigation 升级后，部分页面在新旧架构下的可用高度测量不同，导致底部统计区域被挤压到导航区域，需要按页面容器和安全区域重新调整布局。

发布前如何控风险

这不是“迁移完直接发全量”，而是三层控制：

迁移前后对照：接口协议保持不变，按公共组件、基础能力和核心业务链路做回归。
测试组验证：先由测试组覆盖登录、导航、采购、扫码和核心业务流程。
分阶段发布：通过应用商店的 7 天分阶段发布逐步放量，观察新版本稳定性后再扩大范围。

上线后重点观察 Crash、JavaScript 异常、接口错误和设备分布。最终新版本 Crash 率稳定在 0.5% 以下。

OTA 与监控怎么配合

OTA 链路

业务修复主要针对 JS Bundle，不需要每次都等待应用商店审核。客户端读取服务端 manifest，比较版本后下载更新包，校验完整性，通过后再加载；失败时保留当前可用版本，并支持回滚。

面试表述：

我自研了 OTA 发布链路，包含 Bundle 版本管理、SHA-256 完整性校验、灰度发布和失败回滚，把适合热修复的业务代码发布从数天缩短到分钟级。涉及原生代码、权限或依赖变化时，仍然必须走完整 APK 商店发布。

异常上下文

监控不能只收集一条错误信息，还要带上：

App 版本和构建号。
设备型号、系统版本和平台。
页面或业务动作。
请求接口、网络状态和异常堆栈。

这样才能回答“哪个版本、哪些设备、哪条业务链路受影响”，并支持版本回溯。

面试中的职责边界

推荐说法：

我负责迁移方案、基础能力拆分、依赖兼容处理、业务迁移和发布验证。部分代码实现使用了 AI 辅助，但我负责确认接口和架构约束、检查生成结果、处理真机兼容问题，并通过测试组和分阶段发布验证最终结果。

不建议说：

“AI 把 850 个页面全部自动迁移了。”
“新架构上线后完全没有问题。”
“只要升级 RN，所有性能都会变好。”

这些说法会让面试官继续追问，而你很难证明自己的判断和控制过程。

高频追问速答

为什么不直接重写？

业务规模大、接口和页面数量多，直接重写风险高。迁移时保持接口和业务逻辑兼容，优先替换工程底座，再按模块验证，可以控制影响面。

为什么不用 OTA 更新原生能力？

OTA 适合 JS Bundle 和业务逻辑修复，不能替代原生代码、权限、SDK 和依赖升级。原生变化必须通过完整版本发布。

如何证明迁移没有破坏业务？

通过接口协议不变、基础能力先验证、核心链路回归、测试组验证、分阶段发布和线上监控共同证明，而不是只依赖一次手工测试。

AI 在里面做了什么？

AI 主要帮助生成迁移代码、排查报错和整理重复修改；架构边界、依赖取舍、真机验证、发布策略和最终质量由我负责。

这段项目最后怎么收尾

这次迁移的结果不是单纯把 RN 版本升上去，而是把一个难以扩展的存量工程，升级成具备监控、OTA、灰度和回滚能力的持续交付工程，同时保持业务用户平滑迁移。