01｜React Native 到底是从哪里切进来的？
写到这里，跨端这条线已经很清楚了。
Hybrid 的最大吸引力是：
- Web 团队现成可用
- 开发速度快
- 复用率高
可它最深的短板也同样清楚：
你写出来的界面，最终还是要靠 WebView 去解释。
这会带来两个很现实的问题。
第一，
一旦交互变重，WebView 很容易露底。
第二， 你永远像在借一层本来就不是为 App 级体验设计的地板硬撑。
这就是 React Native 真正切进来的位置。
它没有说：
“我来做一个更快的 WebView。”
它说的是：
既然 WebView 这层解释器太重，那我为什么不把 JavaScript 留着，把视图解释权交还给原生宿主？
这一步非常关键。
因为它第一次把跨端问题重新拆层了：
- 逻辑未必要分开写
- 但界面未必要继续交给浏览器解释
也就是说，
React Native 最重要的地方，
不是“它更接近原生”这么简单。
而是：
它开始系统性承认：跨端不一定要统一所有层。
02｜官方一上来就不肯喊 write once
这条线一定要先立住。
因为今天很多人一提起 React Native，
脑子里最容易自动浮现的就是：
“一套代码跑 iOS 和 Android。”
可如果你回到 2015 年 React 官方博客那篇 Introducing React Native，
你会发现它最重要的一句原话反而是：
我们并不追求 write once, run anywhere。
而它给出的说法是：
learn once, write anywhere
这句话太重要了。
因为它不是文案细节。
它几乎就是整个现代跨端史里最关键的一次承诺收缩。
它等于公开承认：
- 平台不会完全一样
- 体验也不会完全一样
- 你还是得写离平台更近的东西
只是， 你不必再为每个平台先学习一套完全陌生的思维方式。
这意味着什么？
意味着 React Native 一开始就比 Flash 和很多早期 Hybrid 路线更现实。
它不是在承诺：
彻底抹平差异。
它承诺的是：
让同一批工程师，用更接近的一套心智，分别去碰不同宿主。
这和“写一次到处跑”其实是两种完全不同的政治。
03｜它到底是在统一移动端，还是在重划边界？
理解 React Native，
最不该用的方式，
就是把它理解成：
“JavaScript 终于征服移动端。”
这会把它写歪。
更准确的说法其实是：
React Native 重新协商了 JavaScript 和原生宿主的边界。
它大概在做这样一件事：
- 用 JavaScript / React 保留熟悉的开发心智
- 用宿主原生控件保留平台感和性能空间
- 用桥接把两边缝起来
这一步为什么有历史意义？
因为它几乎是跨端第一次大规模把“统一开发”翻译成了：
不是你来取代宿主。
而是你来借宿主。
这会直接带来两种后果。
好的那一面是：
- 你不再像
Hybrid那样完全赌WebView - 你更容易获得平台原生感
- 很多常见业务界面看起来终于不像“网页套壳”
可坏的一面也会立刻冒出来：
一旦你承认宿主很重要，你就不可能真的完全摆脱宿主差异。
这也是为什么 React Native 看起来比上一代更现实，
但也更容易让人失去幻想。
因为它从一开始就在告诉你：
“差异不会消失，只能被管理。”
04｜WebView 的债，后来全转成了桥接税
这是写这篇时最重要的一层。
因为很多人后来谈 React Native，
会不自觉把它写成一种更先进、更正确的跨端方案。
其实它没有消灭代价。
它只是重新分配代价。
以前 Hybrid 最痛的地方是：
WebView- 渲染
- 动画
- 宿主浏览器碎片化
而 React Native 最终更痛的地方，
慢慢会变成：
- 桥接
- 序列化
- 原生模块生态
- 平台差异修补
- 升级和依赖兼容
- 团队需要同时理解 JS 世界和原生世界
也就是说， 它并没有把跨端的复杂度蒸发掉。
它只是把旧债从浏览器解释层， 搬到了：
宿主映射层和生态协同层。
这也是为什么桥接后来会成为 React Native 史上最敏感的话题之一。
因为一旦：
- 列表很重
- 动画很多
- 交互频繁
- 数据往返密集
你就会很快撞到一个现实：
这层把 JavaScript 和原生世界缝起来的桥，本身就会变成瓶颈。
所以 React Native 这条路线真正留下来的，
不是“终于更像原生”这么简单。
而是另一条更重要的判断：
跨端真正难的，从来不是“能不能让 JavaScript 参与”，而是“JavaScript 和宿主之间那层中间抽象到底要付多少税”。
05｜Airbnb 把问题从技术写成了组织
2018 年 Airbnb 官方宣布 sunset React Native，
这件事后来之所以会这么有震动，
不是因为它单独证明了 React Native 不行。
而是因为它非常典型地暴露了一件事：
跨端在大组织里，最容易从技术问题外溢成组织问题。
如果你只看小团队语境，
React Native 的吸引力其实非常强：
- 一套熟悉心智
- 更高复用
- 产品交付更快
可当团队变大之后， 问题会开始变形：
- 你要同时维护 iOS、Android、React Native 三种世界的能力
- 你需要有人懂桥接、懂原生模块、懂宿主差异
- 版本升级和依赖兼容会吃掉越来越多基础设施时间
- 组织边界会变得非常别扭：这到底算前端问题、移动问题，还是平台问题
所以 Airbnb 的意义不在于：
“大厂弃用 = 技术失败。”
真正更值得记住的是：
一项跨端技术如果不能把组织摩擦一起压下去，它在大组织里就会越来越像同时维护三套世界，而不是少维护一套世界。
这就是为什么 Airbnb 这条线特别适合写进跨端史。
它把很多原本只会被讲成“技术细节”的东西， 直接公开暴露成：
- 团队结构
- 招聘现实
- 基础设施负担
- 跨组织协作
这些更难躲开的账。
06｜问题这么多，React Native 还是活着
如果只看桥接瓶颈和 Airbnb 退出， 你又会很容易得出另一个过头的判断：
那 React Native 不也失败了吗？
也不是。
因为它真正留下来的东西非常重要。
它给整个行业带来了一次认知升级：
跨端不必再假装自己统一一切。
这听上去像退步。
其实更像成熟。
因为从它之后， 行业越来越能接受一件事：
- 逻辑可以尽量共享
- 组件心智可以尽量共享
- 但体验和宿主边界不可能彻底共享
这就是为什么后来即便有桥接问题、生态问题、升级问题，
React Native 仍然没有像早年很多路线那样迅速被历史扫走。
它没有提供终局。
但它提供了一种更长久的跨端现实主义：
不是消灭差异，而是管理差异。
后来新架构为什么会出现， 也正说明这条路线不是死了。
而是它自己也承认：
旧中间层太贵了， 得继续重写。
07｜它到底给现代跨端留下了什么规矩？
回头看 React Native，
最不该记住的，
不是某个版本引入了什么能力，
也不是哪一年桥接快了多少。
更该记住的是这句：
React Native 最重要的历史，不是它多像原生，而是它第一次把现代跨端写成了“收缩承诺”的现实主义。
React Native 真正把行业教会的，
不是怎样把 JavaScript 继续推向更多端。
而是怎样在还想统一开发时，学会先把话说小一点。
别再说“彻底统一”。
别再说“差异可以消失”。
先承认宿主还在，先承认桥接会贵，先承认组织也要跟着付账。
也正因为它先把口号收回去， 它才没有像很多更激进的旧路线那样，直接死在自己的承诺上。
编者注（事实核对）：文中关于 React Native 一开始就不追求 write once, run anywhere，主要依据 React 官方 2015 年博客 Introducing React Native 与 Meta 工程博客同期表述。关于 Airbnb 退出 React Native，主要依据 Airbnb 工程博客 2018 年文章 Sunsetting React Native。关于桥接瓶颈和社区对旧架构的长期争议，主要依据 React Native 官方仓库与社区长期讨论材料。
关键人物速览
- Sophie Alpert：理解 React 官方如何公开定义
React Native的定位，绕不开她。 - Tom Occhino：理解 Meta 当年为什么把 React 心智带到移动端，绕不开他。
- Airbnb 移动团队：理解
React Native如何从技术问题外溢成组织问题，绕不开他们。 - React Native 社区维护者：理解桥接、原生模块和新架构这些后续摩擦，绕不开他们。
参考与延伸阅读
Introducing React Native
https://legacy.reactjs.org/blog/2015/03/26/introducing-react-native.htmlReact Native: Bringing modern web techniques to mobile
https://engineering.fb.com/2015/03/26/android/react-native-bringing-modern-web-techniques-to-mobile/React Native for Android
https://reactnative.dev/blog/2015/09/14/react-native-for-androidSunsetting React Native
https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30aReact-native: why JS bridge is the performance bottleneck
https://github.com/facebook/react-native/issues/19678