React Native工程化落地：从环境搭建到生产就绪的实战路径
你有没有经历过这样的场景？刚敲下npx react-native init MyApp，终端滚动出一长串警告和错误：xcode-select: error: tool 'xcodebuild' not found、Could not find tools.jar、Metro failed to load module……你以为只是“配个环境”，结果花了三天还在跟ANDROID_HOME和Pods的符号链接死磕。
这不是你的问题——这是 React Native 工程本质的第一次真实叩问：它从来不是一个“开箱即用”的框架，而是一套需要你亲手组装、校准、调试的跨端开发操作系统。它的底层不是 JavaScript，而是 Xcode 的构建图谱、Gradle 的依赖解析树、Metro 的模块图谱、Hermes 的字节码调度器，以及 iOS 与 Android 原生线程模型之间那条微妙的桥接带宽。
所以，我们不讲“五步搭建环境”，也不列“必备工具清单”。我们直接钻进三个真正决定项目生死的关键系统：CLI 构建链如何让 JS 代码最终变成一个能上架的.ipa或.apk；Navigation 如何在声明式写法下，依然精准控制每个页面的生命周期与内存驻留；Redux Toolkit 又是怎样把“写十个文件才能改一个状态”的旧范式，压缩成一段可读、可测、可回溯的纯函数逻辑。
这才是你在技术评审会上该说清楚的事。
CLI 不是脚手架，是双平台构建调度中枢
很多人把react-native init当作创建项目的“快捷键”，但它的真正角色，其实是一个运行在 Node.js 上的跨平台构建调度器（Build Orchestrator）——它不编译代码，但它决定谁来编译、何时编译、用什么参数编译。
当你执行npx react-native run-android，CLI 干了三件事：
- 启动 Metro 打包服务：监听
App.tsx及其依赖，生成一个包含所有 JS 模块的index.android.bundle； - 触发 Gradle 构建流程：调用
./gradlew app:assembleDebug，将bundle注入android/app/src/main/assets/index.android.bundle，并打包app-debug.apk； - 安装并启动 App：通过
adb install安装 APK，再用adb shell am start启动 Activity。
而npx react-native run-ios则走另一条路：
- 进入
ios/目录，执行pod install安装原生依赖（如React-Core、RCTAnimation）； - 调用
xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 15' -configuration Debug编译原生代码； - 将
index.ios.bundle注入main.jsbundle，启动模拟器并加载 App。
关键在于：CLI 本身不持有任何平台能力，它靠环境变量和命令行工具链的“契约”来工作。
-JAVA_HOME必须指向 JDK 17（Android Gradle Plugin 8.0+ 强制要求）；
-ANDROID_HOME必须包含platform-tools/adb和emulator/emulator；
-xcode-select --install不仅要装命令行工具，还得确保xcode-select -p指向正确的 Xcode 路径（尤其当你装了多个 Xcode 版本时）；
-node_modules/.bin/react-native是软链接，实际指向@react-native-community/cli的build命令——这个命令才是真正的调度核心。
这也是为什么react-native doctor是你每天打开终端第一件事。它不是“体检报告”，而是一份实时验证的平台契约清单。它检查的不是“有没有”，而是“能不能被 CLI 正确识别和调用”。
✅ 真实经验：某次 CI 构建失败，
doctor显示✓ Android SDK，但run-android仍报错。深挖发现：CI 机器上ANDROID_HOME指向的是sdk/目录，而sdk/platform-tools/adb权限为600（只读），导致 CLI 无法执行adb devices。修复只需一行：chmod 755 $ANDROID_HOME/platform-tools/adb。
