Expo SDK49托管流生产环境登录崩溃，报错-[__NSCFNumber length]

错误本质分析 #

这个报错-[__NSCFNumber length]: unrecognized selector sent to instance的核心是iOS原生层把一个NSNumber类型对象当成NSString调用了length方法，本质是JS层传递给原生的参数类型不匹配。生产环境的代码压缩、优化逻辑和开发环境存在差异，才会导致问题仅在TestFlight/App Store出现。

调试步骤 #

1. 模拟生产环境复现问题 #

• 构建生产模式的开发客户端：执行expo build:development-client --no-dev --minify，这个包会模拟生产环境的代码压缩和优化逻辑，用它测试登录流程，大概率能复现崩溃。
• 对齐生产环境配置：检查app.json/app.config.js中的环境变量、插件配置，确保开发构建时和生产环境完全一致（比如关闭开发环境专属的调试插件、启用生产环境的配置项）。
• 使用生产环境API：直接调用正式的登录接口，避免测试接口返回数据和生产环境的差异导致问题无法复现。

2. 关键节点加日志定位 #

• 在登录流程的全链路加详细日志：包括请求参数、接口返回数据、传递给原生模块（如登录SDK、AuthSession）的所有参数，用console.log输出每个字段的类型+值（比如console.log('userID type:', typeof userID, 'value:', userID)）。生产环境可以把日志上传到自建服务，或者用expo-logger收集。
• 重点排查字符串相关字段：比如用户手机号、token、用户ID这类需要传递给原生的字段，确认是否在某些场景下被转换成了数字类型（比如接口返回的数字ID未转成字符串就传给了原生）。

3. 排查依赖与插件兼容性 #

• 检查登录相关依赖：比如expo-auth-session、第三方登录SDK等，确认版本是否与Expo SDK49兼容，查看官方文档或GitHub issues是否有类似生产环境类型不匹配的问题。
• 核对SDK49变更：查看Expo SDK49的官方变更日志，重点关注iOS端原生参数处理、类型转换相关的改动，是否存在开发/生产环境的行为差异。

4. 利用Expo工具辅助调试 #

• 执行expo diagnostics检查项目依赖、环境配置是否存在异常，确保没有版本冲突或配置错误。
• 用expo start --no-dev --minify启动项目，以生产模式加载代码，连接到开发客户端测试，观察是否能复现崩溃。

5. 解析崩溃日志 #

• 从TestFlight或App Store后台下载完整的崩溃报告，用expo symbolicate命令解析日志，将原生堆栈映射到JS代码行，精准定位触发错误的具体代码位置。

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