如果你是在准备技术方案、项目复盘或者面试，可以把 React Native 跨端项目的痛点归纳成一句话：

RN 最大的价值是“业务代码复用”，最大的代价是“平台差异并没有消失，只是从 UI 层转移到了工程、原生能力、性能和发布体系”。

下面我按实际项目里比较容易踩坑的角度讲。

1. 跨端最核心的痛点：并不是“真正一次开发，到处运行”

通常可以做到：

• JS/TS 业务逻辑：70%～90% 复用

• 页面 UI：60%～90% 复用

• 网络、状态管理、数据处理：基本复用

• 原生能力：很难 100% 复用

• 极致性能/平台特色 UI：往往需要平台代码

所以第一个坑就是：

坑：一开始把 RN 当成 Web

例如：

<View>
  <Text>你好</Text>
</View>

看起来像 Web，但实际上：

React
  ↓
RN Runtime
  ↓
iOS Native / Android Native

最终还是：

View
Text
ScrollView
Image
Gesture
Animation

这些都受到 iOS / Android 自身机制影响。

解决

项目初期就建立：

shared
├── business
├── hooks
├── services
├── store
└── utils

platform
├── ios
└── android

对于平台差异，不要强行写成一套代码。

例如：

const paddingTop = Platform.select({
  ios: 20,
  android: 16,
});

更复杂的时候直接：

Button.ios.tsx
Button.android.tsx
Button.tsx

不要为了追求代码复用率，把平台差异硬揉成一团。

---

2. 最大的坑之一：Android / iOS UI 不一致

这是 RN 项目非常常见的问题。

例如：

• 字体渲染不同

• 行高不同

• Text 垂直对齐不同

• Shadow 不一样

• Border 不一样

• Keyboard 行为不同

• StatusBar 不一样

• SafeArea 不一样

• ScrollView 行为不同

• Modal 不一样

• 图片裁剪不同

一个设计稿：

高度 48
字体 16
lineHeight 24

iOS 看起来正常：

┌──────────────┐
│    Button    │
└──────────────┘

Android 可能变成：

┌──────────────┐
│     Button   │
└──────────────┘

文字上下偏移几个 px。

解决方案

不要单纯依赖：

<Text style={{ lineHeight: 24 }}>

而是建立自己的 Design System：

Typography
Spacing
Colors
Radius
Shadow
Button
Input
Modal
List

例如：

const typography = {
  title: {
    fontSize: 20,
    lineHeight: 28,
    fontWeight: '600',
  },

  body: {
    fontSize: 16,
    lineHeight: 24,
  },
};

再通过 iOS / Android 做少量 platform override。

真正跨端的不是“所有代码一样”，而是“抽象层一样”。

---

3. 性能：列表是最容易翻车的地方

比如商品列表：

FlatList
  ↓
1000 items
  ↓
每个 item 里面
Image
Text
Button
Animation
Touchable

开发环境可能没问题。

到了真实用户：

Android 中低端机
↓
FPS 掉
↓
滑动卡顿
↓
JS Thread 忙

常见原因

① render 太重

<FlatList
  data={data}
  renderItem={({ item }) => (
    <HeavyComponent item={item} />
  )}
/>

每次 state 更新，都可能导致大量组件重新计算。

② key 不合理

keyExtractor={(item, index) => index.toString()}

列表增删时容易造成额外重渲染。

应该尽量：

keyExtractor={(item) => item.id}

③ 图片太大

比如服务器给你：

2000 x 2000

但手机上只显示：

100 x 100

依然下载大图。

④ JS Thread 被阻塞

例如：

JSON.parse(veryLargeJson)

或者：

array.map(...)
array.sort(...)

一次处理几十万数据。

解决

列表重点关注：

FlatList
↓
getItemLayout
keyExtractor
initialNumToRender
windowSize
maxToRenderPerBatch
removeClippedSubviews

同时：

React.memo
useMemo
useCallback

但不要滥用 memo。

更重要的是：

先定位到底是 JS 慢、UI 慢、图片慢还是网络慢，再优化。

对于超长列表，可以考虑使用更专业的虚拟列表方案，例如 Shopify 的 FlashList。

---

4. 动画也是一个大坑

早期 RN 项目经常遇到：

JS Thread
   ↓
Animated
   ↓
Native

如果动画过程中 JS Thread 很忙：

JS 卡
↓
动画掉帧

比如：

onScroll={(event) => {
  // 大量 JS 计算
}}

同时做动画：

Animated.View

就可能出现卡顿。

解决

尽可能让动画脱离 JS Thread。

现在项目里一般会重点考虑：

Reanimated
Gesture Handler
UI Thread
Worklet

典型思路：

Gesture
   ↓
UI Thread
   ↓
Animation

而不是：

Gesture
   ↓
JS Thread
   ↓
Animation

这也是为什么现代 RN 项目通常会更加依赖 Reanimated 这一套。

---

5. Native Module 是跨端项目最容易失控的地方

一开始：

RN
+
少量 Native

后来业务不断加：

支付
地图
推送
蓝牙
相机
文件
生物识别
WebView
分享
音视频
埋点
推送

最后：

JS/TS
├── iOS Native
├── Android Native
├── 第三方 SDK
├── CocoaPods
└── Gradle

这时候你会发现：

RN 不是消灭 Native，而是让前端开发者必须理解 Native。

---

6. CocoaPods / Gradle 是非常典型的“玄学坑”

例如：

pod install

突然：

error

Android：

./gradlew assembleRelease

突然：

Could not resolve...

常见原因：

RN version
↓
React Native dependencies
↓
Xcode
↓
iOS SDK
↓
CocoaPods
↓
Node
↓
JDK
↓
Gradle
↓
Android Gradle Plugin
↓
Android SDK

其中任何一个版本不匹配，都可能导致构建失败。

解决方法

不要让项目依赖：

“我电脑上能跑”

而是建立明确的：

Node version
JDK version
Ruby version
CocoaPods version
Xcode version
Android Studio version
Gradle version
RN version

并使用：

.nvmrc
Gemfile
Podfile.lock
package-lock / yarn.lock / pnpm-lock
gradle wrapper

把环境固定下来。

---

7. RN 升级是非常痛苦的一件事

比如：

RN 0.68
↓
0.71
↓
0.73
↓
0.76

可能涉及：

Android
iOS
Hermes
New Architecture
Fabric
TurboModule
Metro
Flipper
第三方 Native Module

最麻烦的是：

你升级 RN，往往不是升级一个 npm package，而是在升级整个移动端基础设施。

解决

不要：

半年不升级
↓
一次性升级 5 个大版本

更推荐：

小版本持续升级
↓
CI 验证
↓
灰度
↓
再升级

同时把第三方 Native Module 做版本兼容矩阵。

---

8. New Architecture 是一个重要的坑点

现代 RN 已经越来越强调：

Fabric
TurboModules
JSI
Hermes

传统架构：

JS
 ↓
Bridge
 ↓
Native

大量数据需要跨 Bridge。

新架构希望减少这种通信成本：

JS
 ↓
JSI
 ↓
Native

因此一些老 Native Module：

第三方库
 ↓
老 Bridge API
 ↓
New Architecture

可能直接出现兼容性问题。

实际经验

新项目：

尽量选择明确支持 New Architecture 的库。

老项目：

不要为了“技术先进”直接强开，然后让几十个 Native Module 一起爆。

应该：

升级 RN
↓
检查依赖
↓
逐个验证 Native Module
↓
打开 New Architecture
↓
CI + 真机测试

---

9. WebView 是另一个巨坑

很多业务会想：

“这个页面 Web 做就好了，直接 WebView。”

短期非常爽：

RN
 ↓
WebView
 ↓
H5

长期容易出现：

RN ↔ WebView

通信。

例如：

RN
 ↓
postMessage
 ↓
Web
 ↓
业务处理
 ↓
postMessage
 ↓
RN

然后开始出现：

登录态
Token
Cookie
返回
跳转
支付
键盘
文件上传
图片选择
页面生命周期
网络状态

解决

如果使用 WebView，最好从一开始定义 Bridge 协议：

type WebMessage =
  | {
      type: 'LOGIN';
      payload: {};
    }
  | {
      type: 'CLOSE';
      payload: {};
    }
  | {
      type: 'PAY';
      payload: {};
    };

不要：

postMessage(JSON.stringify({
  xxx: 123,
  aaa: 'hello',
}))

然后半年以后没人知道这个字段是什么意思。

---

10. 键盘问题非常多

尤其：

TextInput
+
KeyboardAvoidingView
+
ScrollView
+
Android

很容易出现：

键盘弹出
↓
页面整体上移
↓
输入框又上移
↓
Footer 消失
↓
Android/iOS 表现不一致

还有：

adjustResize
adjustPan
windowSoftInputMode

各种组合。

解决

表单页面不要简单粗暴：

KeyboardAvoidingView

全部包起来。

而应该根据：

iOS
Android
页面是否 Scroll
输入框位置
底部按钮
Safe Area

分别处理。

并且一定要真机测试。

---

11. 权限也是一个跨端坑

比如相机权限：

iOS：

Info.plist

Android：

AndroidManifest.xml
+
Runtime Permission

不同 Android API Level 又有变化。

例如：

Camera
Photo
Location
Notification
Bluetooth
Storage

每一种都可能存在：

iOS ≠ Android

所以不要把权限逻辑散落在业务页面：

if (...)
  requestPermission()

if (...)
  requestPermission()

if (...)
  requestPermission()

最好封装：

PermissionService

业务层只关心：

const granted = await PermissionService.camera();

---

12. 发布流程比 Web 项目复杂很多

Web：

npm build
↓
deploy

RN：

JS Bundle
+
Native Binary
+
iOS Signing
+
Android Signing
+
Provisioning Profile
+
Certificate
+
App Store
+
Google Play

还会遇到：

OTA 更新
CodePush 类方案
Native version
JS version
热更新兼容

这里特别容易踩一个坑：

JS 可以热更新，不代表 Native 能热更新。

比如：

JS
调用
Native Module A

如果线上 Native 没有 A：

OTA 推送新 JS
↓
JS 调用 A
↓
App Crash

解决

建立版本兼容：

JS Version
Native Version

例如：

JS 1.5
要求 Native >= 1.3

发布 OTA 前做兼容检查。

---

13. 真机问题比模拟器多得多

这是我认为 RN 项目特别容易被忽略的一点。

模拟器：

网络好
CPU 好
内存大

真实用户：

Android 低端机
弱网
低内存
后台恢复
系统杀进程
各种 ROM

所以：

RN 性能一定要看真实 Android 设备，而不是只看 iPhone 模拟器。

尤其测试：

列表
启动
图片
动画
输入框
WebView
后台恢复
弱网
低内存

---

14. 工程化方面，我比较推荐这样设计

如果让我重新做一个 RN 跨端项目，我会把架构大概设计成：

                    App
                     │
              ┌──────┴──────┐
              │             │
             iOS          Android
              │             │
              └──────┬──────┘
                     │
                  RN Layer
                     │
       ┌─────────────┼─────────────┐
       │             │             │
    Business       UI          Services
       │             │             │
   ┌───┴───┐    ┌────┴────┐   ┌────┴─────┐
   │       │    │         │   │          │
  API    Store  Design    Form Network  Native
                System             │
                                   │
                           ┌───────┴───────┐
                           │               │
                         iOS             Android

核心原则：

① 业务逻辑最大化复用

TS
Hooks
Store
API
Utils
Business

② UI 尽量复用

Button
Input
List
Card
Modal

③ Native 能力统一封装

CameraService
LocationService
PushService
PaymentService

④ 平台差异显式存在

xxx.ios.ts
xxx.android.ts

而不是：

if (Platform.OS === 'ios') {
   // 500 行
} else {
   // 500 行
}

---

15. 如果是面试，我会这样总结“踩坑”

你可以直接用下面这个框架回答：

我做 RN 跨端项目时，最大的体会是跨端并不意味着完全抹平平台差异。

第一类问题是 UI 一致性，比如 iOS 和 Android 在字体、SafeArea、Keyboard、Shadow、ScrollView 等方面表现不同。我们的解决方案是建立 Design System，同时通过 .ios.tsx / .android.tsx 做平台隔离，而不是在业务代码里堆大量 Platform 判断。

第二类是 性能问题，尤其是长列表、大图片和复杂动画。我们会重点关注 JS Thread 和 UI Thread，列表使用虚拟化、稳定 key、memo 等手段，动画尽量使用 Reanimated 放到 UI Thread。

第三类是 Native 依赖和版本管理。RN 项目一旦涉及支付、推送、地图、WebView 等 Native Module，升级 RN 就不再只是升级 npm 包，还会涉及 Xcode、CocoaPods、Gradle、Android SDK 等。所以我们会固定开发环境和依赖版本，并通过 CI 做 iOS、Android 双端构建验证。

第四类是 RN 升级和新架构兼容。我们不会一次跨多个大版本升级，而是逐步升级，并提前检查第三方 Native Module 对 Fabric、TurboModule、Hermes、New Architecture 的支持情况。

最后一个比较深的经验是，跨端真正应该复用的是业务和抽象，而不是强行复用所有代码。对于平台差异，应该允许它存在，并通过架构把差异隔离起来。

如果你是在准备RN 面试，这套内容还可以继续往下扩展成「10 个高频 React Native 面试题 + 标准回答 + 项目实战案例」，会比单纯背痛点更有用。