react/react-native 是什么？

React Native 是 Meta 维护的跨平台移动框架，用 JavaScript 渲染原生 UI。本文基于 0.87 版本仓库文档，拆解它的架构、上手路径、维护成本，以及它与 Flutter 这类自绘引擎的本质区别。

react/react-native 可以商用吗？

可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。

react/react-native 还在维护吗？

在维护。仓库在最近一天内有新的提交。

react/react-native 是用什么编程语言写的？

主要是 C++（依据 GitHub 的语言统计）。

React Native 0.87 评测：架构、上手、维护成本与替代方案

Q: react/react-native 还在维护吗？

在维护。仓库在最近一天内有新的提交。

秒懂

它是什么？: React Native 是 Meta 维护的跨平台移动框架，用 JavaScript 渲染原生 UI。本文基于 0.87 版本仓库文档，拆解它的架构、上手路径、维护成本，以及它与 Flutter 这类自绘引擎的本质区别。
适合谁用？: React Native 适合两类人：一是已经熟悉 React 的前端团队，想用同一套组件模型覆盖 Android 和 iOS；二是需要大量调用平台原生 API 的应用，因为 Native Modules 提供了同步、类型安全的桥接通道。不适合的场景包括：团队没有 React 经验却想快速做移动端，或者应用对滚动列表、动画的极致性能有硬性要求，这类需求在文档中并未给出优于自绘方案的证据。
能商用吗？: 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
还在维护吗？: 在维护。仓库在最近一天内有新的提交。
用什么语言写的？: 主要是 C++（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月4日 · react/react-native

它解决的是重复造轮子的痛点

移动开发的老问题是写两遍：一套 Swift 或 Kotlin，一套 Java 或 Objective-C。React Native 把 UI 描述从平台语言里抽出来，用 React 的声明式组件来写，最终渲染时却调用各平台的原生控件。文档里明确说，它的原语渲染到原生平台 UI，手势、文本缩放、无障碍行为都按每个操作系统的习惯来。这意味着用户看到的不是网页套壳，而是真正的原生界面。适合谁？已经会用 React 的团队，或者想从 Web 前端平滑切入移动端的开发者。不是给完全不懂 React 的人准备的入门工具，那应该先去学 React 本身。

JavaScript 写逻辑，原生代码画界面

架构核心是双线程分离。JavaScript 负责业务逻辑和组件树，原生线程负责实际渲染和交互。两者之间通过桥接通信，Native Modules 允许你从 JavaScript 直接调用平台代码，文档强调这是同步且类型安全的。数据流是单向的：React 组件状态变化触发重渲染，diff 结果通过桥接传给原生层，原生层更新真实视图。Fast Refresh 是这套架构的副产品，改动 JavaScript 代码后，几秒内就能在模拟器或真机上看到变化，不需要重新编译原生工程。但要注意，这个机制只覆盖 JavaScript 改动，如果你改了原生模块或配置文件，仍然要走完整的构建流程。

从零开始的两条路：框架和裸用

官方文档给了两条明确路径。第一条是推荐路线，用 Expo 框架，一条命令就能起项目：npx create-expo-app@latest。Expo 自带文件路由和一批标准原生模块，适合大多数新应用。第二条是不用框架，直接初始化 React Native 项目，文档里叫 Getting Started Without a Framework。官方态度很直接：大多数开发者应该受益于框架，因为导航、原生依赖、平台工具链这些问题生态已经解决了。如果你要集成到现有 App 里，文档提供了 Integration with Existing Apps 的入口，可以增量采用。实际动手时，环境配置是第一个坎，Android 需要 Android Studio 和 SDK，iOS 需要 Xcode，这些在 environment-setup 指南里有详细步骤。

原生模块是双刃剑

React Native 的扩展能力靠 Native Modules。你可以自己写原生代码，暴露给 JavaScript 调用，也可以从 reactnative.directory 上找现成库，文档说那里有数千个。这个设计很灵活，但代价是维护复杂度。每升级一次 React Native 主版本，原生模块可能就要跟着适配，尤其是那些没跟上社区节奏的第三方库。文档里的 Upgrading 指南专门讲这个过程，说明升级不是无痛的。另一个限制是，如果你需要极高性能的列表或复杂动画，JavaScript 桥接那一层会成为瓶颈。文档没有提供性能基准数据，但从架构上看，每次交互都要跨线程通信，这比纯原生直接操作视图多了开销。对于大部分业务应用这不是问题，但对游戏或高频刷新的 UI 就是硬伤。

与 Flutter 的本质差异：桥接对自绘

常见替代方案是 Flutter，但两者思路完全不同。React Native 的 UI 组件映射到各平台的原生控件，所以外观和行为天然贴近系统，但跨平台一致性要靠桥接和适配。Flutter 则是自绘引擎，用 Skia 直接画所有控件，不依赖系统组件，所以视觉效果在 iOS 和 Android 上完全一致，代价是包体积更大，而且某些系统级交互需要额外处理。选择取决于你的优先级：如果追求平台原生手感，React Native 更合适；如果团队只有 Dart 经验且想要像素级一致，Flutter 更直接。React Native 的优势在于 React 生态，文档强调 React 的 hooks、Suspense 都能复用，这对前端团队是实打实的资产。

版本节奏和升级成本

仓库显示 0.87.1 在 0.87.0 发布两周后就出了补丁，0.86.3 也在维护中，说明社区保持活跃的发布节奏。升级成本是明确的：每次主版本升级都可能涉及原生代码重新编译，以及第三方库的兼容性检查。文档把 Upgrading 单独列为一节，说明这不是自动完成的事。好在 MIT 许可证下你可以自由修改和分发，但要注意，如果你深度定制了原生层，升级时合并冲突会更多。建议在升级前先看 release notes，确认没有破坏性变更，并且在测试设备上跑完整回归。

维护状态与社区支撑

这不是一个孤立的开源项目。仓库由 React Foundation 支持，文档提到许多公司和独立贡献者共同维护。代码行为主语言是 C++，因为底层渲染和桥接逻辑用 C++ 实现，JavaScript 只是暴露给开发者的接口层。这意味着如果你要贡献核心代码，需要懂 C++，不是纯前端能搞定的。社区讨论分散在 react-native-community/discussions-and-proposals 和 reactwg/react-native-releases 两个仓库，发布计划在后者里讨论。这种治理结构的好处是决策透明，坏处是重大改动需要跨多个仓库协调，周期可能较长。对于普通使用者，你不需要参与这些，但了解这些能帮你判断遇到问题时该去哪里找答案。

编辑结论

React Native 适合两类人：一是已经熟悉 React 的前端团队，想用同一套组件模型覆盖 Android 和 iOS；二是需要大量调用平台原生 API 的应用，因为 Native Modules 提供了同步、类型安全的桥接通道。不适合的场景包括：团队没有 React 经验却想快速做移动端，或者应用对滚动列表、动画的极致性能有硬性要求，这类需求在文档中并未给出优于自绘方案的证据。采用前先验证三件事：你的原生依赖是否在 reactnative.directory 上有维护版本，升级到 0.87 时是否愿意处理原生代码的重新编译，以及你的团队是否能接受 Fast Refresh 只对 JavaScript 改动生效、原生改动仍需完整构建这一限制。

官方来源

社区笔记