新手更新长期未维护React-Native(Expo)旧应用的调试思路

结论先行：优先定位修复崩溃、功能异常问题，绝对不要在项目基线不稳定的时候全量升级依赖、清理deprecated代码。
18个月未维护的Expo React Native项目，跨版本的breaking change密度极高，贸然升级依赖大概率会把「基本能跑、只有偶发问题」的项目直接搞成完全无法启动/构建，连问题排查的对照基线都丢掉，反而会大幅拉长迭代周期。
这类存量旧RN项目的标准迭代流程可以按两个阶段推进：

• 首先锁死当前项目状态：把lock文件（package-lock.json/yarn.lock/pnpm-lock.yaml）完整提交到版本库，这个阶段不要动任何依赖版本，先把所有已知的偶发崩溃、功能异常整理成台账，标注复现路径、出现概率、影响范围。
• 逐个排查问题根因：这类停更18个月的项目，偶发崩溃基本集中在几类场景：新系统版本（iOS16+、Android13+）权限/API变更导致旧原生模块调用失败、JS线程长任务阻塞、全局监听/定时器未卸载引发的内存泄漏、长列表未做回收导致的OOM。排查过程中遇到deprecated代码，只要它不是当前问题的触发源，就统一记录到技术债清单，不要临时修改。
• 所有高优崩溃、核心路径功能异常修复完成后，打一个可稳定运行、可随时回滚的基线版本包留存，再进入下一阶段。

• 严格遵循逐版本升级原则，不要跨大版本跳升：Expo升级不要直接从旧版本拉到最新SDK，要按照官方升级指引逐版本迭代（比如从SDK 45→46→47依次升级），每次升级只做对应版本要求的最小代码改动，跑完核心流程回归测试没问题，再升下一个版本，出问题立刻回滚到上一个可运行状态。
• 依赖升级按优先级分层推进：先升级Expo SDK、React Native核心库，再升级带原生代码的社区依赖（比如react-native-reanimated、react-native-screens、导航库这类），最后升级纯JS实现的工具类依赖，每升级完一批依赖就做一轮核心功能验证。
• deprecated代码清理跟随升级节奏推进：不用单独抽时间全量扫deprecated代码，等升级到对应版本时，再把该版本标记废弃、下版本即将移除的API替换成新写法即可，既不会提前改出兼容问题，也不会等到API被移除导致项目报错。

• 不要看到控制台的deprecated警告就随手修改：大部分deprecated提示只是告知未来版本会移除API，当前版本下可以稳定运行，无目的的修改很容易引入新的未知问题。
• 任何改动前都要确保有可回滚的稳定版本：旧项目迭代最忌讳改到一半项目无法启动，又记不清之前可运行状态的配置。
• 不要随意修改Expo托管的原生构建配置：Expo的原生配置默认和SDK版本绑定，手动篡改很容易引发云构建、本地打包失败，等熟悉全项目依赖逻辑后再做定制调整。

内容的提问来源于stack exchange，提问作者ttsssss