Microsoft ｜React Native Windows 源码审阅：从 2774 个文件看跨平台桌面应用的工程落地能力

本文基于 Microsoft react-native-windows 固定源码快照进行只读静态审阅，重点分析项目的语言构成、模块边界、构建体系、测试证据和企业落地路径。
审阅提交：115226a6a85567af3b3d855b47ae7e665f80d91e
本文未执行构建、测试、依赖安装、性能测试或漏洞扫描。所有结论均来自可复现源码快照中的静态证据。
评测对象：React Native Windows 开源源码
评测类型：证据驱动的只读静态工程审阅
评测边界：本文未执行项目构建、测试、依赖扫描或运行时验证，结论仅适用于指定源码快照。
作者：Valhalla Matrix治理实验室

摘要

React Native 解决了跨平台应用开发中的一部分重复建设问题，但当目标平台从移动端扩展到 Windows 桌面时，开发团队仍然需要面对原生窗口、系统 API、C++ 扩展、构建工具链、应用打包和平台兼容性等工程问题。

react-native-windows 是 Microsoft 维护的 React Native Windows 平台实现。它的价值不仅在于让 React Native 应用运行在 Windows 上，也在于连接 JavaScript/TypeScript 应用层与 Windows 原生运行时。

本文基于固定提交的源码静态证据，分析以下问题：

  • 项目由哪些技术栈组成；
  • packages 与 vnext 分别承担什么阅读入口；
  • C++、JavaScript、TypeScript 和 C# 如何共同构成平台实现；
  • 构建、测试和 CI 证据说明了什么；
  • 企业采用前还需要完成哪些验证。

一、结论先行：工程证据较完整，但不能替代 Windows 实机验证

根据当前源码快照，项目具备以下静态特征：

指标 静态观测结果
受支持源文件 2774 个
C/C++ 相关文件 932 个
C++ 文件 741 个
JavaScript 文件 641 个
TypeScript 文件 332 个
C# 文件 123 个
一级模块根 6 个
构建或依赖文件线索 30 个
测试文件线索 100 个

从工程证据来看，项目具有较清晰的模块边界，并且存在构建配置、锁文件、测试目录和 CI 相关线索。四个治理维度均有静态证据：

  • 模块化：可观测；
  • 可测试性：可观测；
  • 交付自动化：可观测；
  • 依赖可追踪性：可观测。

但需要严格区分：

配置文件存在 ≠ 构建成功
测试文件存在 ≠ 测试全部通过
依赖锁文件存在 ≠ 依赖没有漏洞
支持某个平台 ≠ 满足所有企业桌面场景

因此，本文适合作为技术尽调、源码阅读和 PoC 规划的依据，不构成生产上线、性能达标或安全放行结论。

二、项目定位：React Native 与 Windows 原生能力之间的桥梁

React Native Windows 的核心目标，可以概括为：

JavaScript / TypeScript 应用代码
              ↓
React Native Windows 平台层
              ↓
Windows 原生运行时

它并不是一个独立的业务应用框架，也不是通用的 Windows 桌面开发平台。更准确地说，它承担的是 React Native 跨平台抽象与 Windows 原生能力之间的适配职责。

企业采用时，需要将以下概念区分开：

能力 React Native Windows 是否直接解决
React Native UI 开发 主要解决
Windows 原生控件适配 主要解决
JavaScript 与原生模块通信 主要解决
业务状态管理 需要团队自行选择
企业身份认证 需要业务系统接入
自动更新 需要结合发布体系验证
Windows 应用打包 需要结合目标方案验证
性能和资源治理 需要目标环境实测
企业设备管理 不由框架单独解决

因此，项目的真正工程价值在于：

为 React Native 应用提供 Windows 平台实现，同时保留 JavaScript 层开发效率和原生能力扩展空间。

三、源码概览：多语言协同，而不是单一前端项目

当前快照中的语言指纹如下：

语言或分类 文件数量
C/C++ 932
C++ 741
JavaScript 641
TypeScript 332
C# 123
Python 4
C 1

需要注意，静态扫描结果中的 C/C++ 与 C++ 属于工具输出分类，可能存在分类口径差异，不应简单相加后当作完全互斥的语言统计。

从整体构成看，项目属于典型的多层平台工程：

JavaScript / TypeScript
        ↓
React Native Windows API 与工具链
        ↓
C# / C++ 原生适配层
        ↓
Windows 系统能力与底层运行时

这对研发团队提出了更高要求：

  • 前端开发人员负责 JavaScript 或 TypeScript 层；
  • 原生开发人员负责 C++、C# 和 Windows API；
  • 构建人员需要理解 Node.js、Yarn、CMake 以及 Windows 工具链；
  • 测试人员需要覆盖 JavaScript 行为与原生平台行为；
  • 发布人员需要验证 Windows 应用打包和签名流程。

四、六个主要阅读入口

当前快照中识别到 6 个一级模块根：

.ado
beachball.config.js
jest.config.js
lage.config.js
packages
vnext

可以建立如下源码阅读地图：

react-native-windows

.ado

beachball.config.js

jest.config.js

lage.config.js

packages

vnext

4.1 packages

packages 目录包含多个 JavaScript、TypeScript 和工具链相关包。当前抽样路径包括：

packages/@react-native-windows/automation-commands/src/index.ts
packages/@react-native-windows/automation/src/index.ts
packages/@react-native-windows/cli/src/index.ts
packages/@react-native-windows/cli/src/generator-common/index.ts
packages/@react-native-windows/cli/src/generator-windows/index.ts

从这些文件名来看，packages 主要涉及：

  • CLI；
  • 项目生成；
  • 自动化命令；
  • Windows 工程模板；
  • 开发工具支持。

4.2 vnext

vnext 是当前源码快照中非常重要的阅读入口。相关证据包括：

vnext/package.json
vnext/ReactCommon/
vnext/src-win/
vnext/external/

从目录命名可以推断，vnext 可能承载较新的 React Native Windows 实现、原生代码、第三方组件和平台相关测试。

需要强调：目录名称只能用于建立阅读导航，不能替代完整模块调用关系分析。

4.3 工程配置文件

以下文件反映出项目的工程组织方式：

beachball.config.js
jest.config.js
lage.config.js

它们通常分别与以下职责相关：

  • 版本和变更管理；
  • JavaScript 测试；
  • 多包任务调度和构建编排。

.ado 目录则提示项目存在 Azure DevOps 相关工程自动化线索。

五、架构阅读模型：从 JavaScript 到 Windows 原生层

可以将项目的核心工作流抽象为：

React Native 应用代码

JavaScript/TypeScript 包

React Native Windows 平台适配层

C++ / C# 原生模块

Windows 控件与系统 API

桌面应用运行结果

这个模型适合帮助技术负责人安排源码阅读顺序：

  1. 先看 CLI 和项目生成逻辑；
  2. 再看 JavaScript/TypeScript API 层；
  3. 然后进入 vnext/src-win 等 Windows 平台目录；
  4. 最后追踪 C++、C# 和 React Common 相关实现；
  5. 对照测试，确认跨层契约如何被验证。

跨层项目最需要关注的不是单个函数，而是边界：

JS 调用如何进入原生层？
参数如何转换？
异常如何返回？
线程如何切换？
生命周期如何管理？

六、从抽样源码看工程复杂度分布

本次抽样阅读了 12 个非测试源码文件，静态结构计数如下：

指标 数量
声明 30
分支 82
循环 20
异常路径 24
异步线索 37

这些数据只能作为源码导航指标，不是复杂度评分，也不能直接推导代码质量。

抽样文件中，结构较明显的路径包括：

packages/@react-native-windows/cli/src/generator-common/index.ts
packages/@react-native-windows/cli/src/generator-windows/index.ts
packages/@react-native-windows/cli/src/index.ts

6.1 CLI 生成器是一个重要风险边界

generator-common 和 generator-windows 中观察到较多分支、循环和异常路径，声明线索包括：

walk
resolveContents
copyAndReplace
copyBinaryFile
resolveRnwPath
copyProjectTemplateAndReplace
CodedError

从命名来看，这些代码可能负责：

  • 遍历文件；
  • 解析模板内容；
  • 复制项目文件；
  • 替换项目配置；
  • 处理生成过程中的错误。

项目生成器并不直接属于业务运行时，但它会影响开发者能否成功创建项目。因此，企业 PoC 中应重点验证：

  • 生成的工程是否完整；
  • 模板替换是否正确；
  • 自定义项目名和路径是否正常；
  • Windows SDK、Node.js 和依赖版本不匹配时是否有清晰错误；
  • 生成失败后是否会留下半成品目录。

6.2 异步与 I/O 线索值得优先阅读

抽样源码中观察到：

  • 并发或异步：37 次符号线索；
  • 文件或网络 I/O：25 次符号线索。

这些线索可能与以下区域有关：

  • 文件系统操作；
  • 工程生成；
  • 原生模块调用；
  • 异步事件处理；
  • 开发工具通信。

但它们不能直接证明：

  • 线程安全；
  • 并发性能；
  • I/O 性能；
  • 网络服务能力；
  • 生产环境稳定性。

七、测试证据：100 个测试文件线索

当前快照中识别到 100 个测试文件线索，部分路径包括：

vnext/ReactCommon/TEMP_UntilReactCommonUpdate/jsi/jsi/test/testlib.cpp
vnext/src-win/Libraries/NativeModules/specs/NativeDialogManagerWindows.js
vnext/src-win/Libraries/__tests__/ViewWindows-test.js
vnext/external/fmt/test/args-test.cc
vnext/external/fmt/test/std-test.cc
vnext/external/fmt/test/os-test.cc

从测试目录分布来看，测试覆盖线索包含：

  • JavaScript 组件；
  • Windows Native Modules；
  • JSI 相关能力；
  • C++ 原生代码；
  • 第三方库测试；
  • Windows 平台特定行为。

这说明项目不是只有前端层测试，而是同时存在 JavaScript 和原生层测试证据。

不过，测试文件存在并不等于：

  • 当前提交中的测试全部通过；
  • Windows 不同版本均经过验证；
  • 不同 CPU 架构均有覆盖；
  • 构建产物与源码行为完全一致；
  • 企业业务场景没有兼容问题。

八、构建与依赖证据：Node.js、CMake 与多包工程协同

当前快照中识别到 30 个构建或依赖文件线索，部分包括：

yarn.lock
package.json
vnext/package.json
vnext/external/fmt/CMakeLists.txt
vnext/external/fmt/test/CMakeLists.txt
vnext/external/fmt/test/cuda-test/CMakeLists.txt
vnext/external/fmt/test/gtest/CMakeLists.txt

从这些文件可以看出，项目至少涉及以下工程体系：

Yarn / Node.js
      +
JavaScript / TypeScript
      +
CMake
      +
C++ 原生构建
      +
Windows 开发工具链

企业落地时，不能只验证：

yarn install

还需要确认：

  • Windows 版本；
  • Visual Studio 和 MSVC 版本；
  • Windows SDK 版本；
  • Node.js 版本；
  • Yarn 版本；
  • CMake 版本；
  • React Native 版本；
  • C++ 编译环境；
  • 目标 CPU 架构；
  • 是否需要特定工作负载或 SDK。

对于跨平台原生项目来说，环境矩阵通常比单一构建命令更重要。

九、静态审阅能说明什么，不能说明什么？

可以说明的内容

  • 项目是 JavaScript/TypeScript 与 C++/C# 协同的多语言工程；
  • packages 和 vnext 是主要源码阅读入口；
  • 项目存在 Node.js 和 Yarn 相关配置；
  • 项目存在 CMake 和原生代码构建线索；
  • 项目存在 JavaScript、C++ 和 Windows 平台测试线索；
  • 抽样源码中存在较多异步、I/O、分支和异常处理结构。

不能说明的内容

  • Windows 应用是否能够成功构建；
  • 所有 React Native 版本是否兼容；
  • 不同 Windows 版本是否表现一致；
  • 原生模块是否存在内存安全问题；
  • 应用在高负载下是否稳定；
  • 启动速度和交互性能是否达标；
  • 第三方依赖是否没有漏洞；
  • 生产应用是否可以直接采用。

静态审阅的作用是确定验证重点，而不是替代构建、测试和安全审计。

十、企业采用前最需要验证的五类问题

10.1 环境兼容性

至少建立如下验证矩阵：

维度 需要确认的内容
Windows 目标 Windows 版本
编译器 Visual Studio、MSVC
SDK Windows SDK 版本
Node.js 版本与包管理器
React Native 目标 React Native 版本
架构 x64、ARM64 等
构建 Debug、Release、Packaged

10.2 原生模块稳定性

需要测试：

  • 原生模块初始化；
  • JS 与原生层参数传递；
  • 异步回调；
  • 线程切换；
  • 页面卸载；
  • 应用挂起和恢复；
  • 原生异常返回；
  • 长时间运行。

10.3 工程生成能力

CLI 和模板生成流程需要覆盖：

  • 新建空项目；
  • 自定义项目名；
  • 自定义包名；
  • 启用或禁用原生模块；
  • 重新生成；
  • 依赖升级；
  • 生成失败后的恢复。

10.4 发布与升级

企业还需要验证：

  • Windows 应用打包；
  • 签名；
  • 自动更新；
  • 版本回滚；
  • 增量升级；
  • 原生依赖升级；
  • 旧版本系统兼容性。

10.5 依赖供应链

建议补充：

  • lockfile 校验；
  • npm 依赖漏洞扫描；
  • C++ 第三方库扫描；
  • 构建来源追踪；
  • 发布制品清单；
  • 许可证审查。

十一、推荐的 PoC 验证路径

建议固定源码版本后，在隔离 Windows 环境执行验证。

1. 固定提交并记录环境

git clone https://github.com/microsoft/react-native-windows.git
cd react-native-windows

git checkout 115226a6a85567af3b3d855b47ae7e665f80d91e
git rev-parse HEAD
git status --short

同时记录：

Windows 版本
Node.js 版本
Yarn 版本
Visual Studio 版本
Windows SDK 版本
CMake 版本
React Native 版本
目标 CPU 架构

2. 先确认官方脚本

cat package.json
cat vnext/package.json

重点确认：

  • 安装脚本；
  • 构建脚本；
  • 测试脚本；
  • 包管理器要求；
  • workspace 或多包任务配置；
  • 原生构建入口。

3. 创建最小 Windows 项目

建议使用最小业务场景：

一个页面
一个原生模块
一个异步调用
一个列表组件
一个窗口交互

先验证开发态，再验证 Release 和打包态。

4. 建立跨层测试

至少覆盖：

JS 调用 Native Module
Native Module 返回结果
异步异常处理
页面卸载
应用挂起和恢复
多次初始化
重复调用
错误参数

5. 记录可复现结果

每次验证记录：

  • 完整命令；
  • 环境版本；
  • 构建耗时；
  • 测试数量；
  • 失败日志；
  • 生成物；
  • 安装和启动结果；
  • 运行时异常；
  • 性能指标。

十二、适合与不适合的场景

更适合优先评估的场景

  • 已有 React Native 团队需要扩展到 Windows；
  • 企业内部工具和桌面工作台；
  • Windows 优先的跨平台业务应用；
  • 需要复用 JavaScript/TypeScript 业务层；
  • 需要调用 Windows 原生能力；
  • 已经具备 Windows 原生开发和构建能力的团队。

需要谨慎评估的场景

  • 强依赖复杂 Windows 原生控件；
  • 对启动速度和内存占用要求极高；
  • 需要长期兼容多个 Windows 版本；
  • 需要高度定制的系统集成；
  • 团队没有 C++、C# 或 Windows 构建经验；
  • 需要严格受控的企业桌面发布和升级体系。

十三、最终结论

基于提交：

115226a6a85567af3b3d855b47ae7e665f80d91e

的只读静态源码证据，可以形成以下判断：

  1. react-native-windows 是一个多语言、跨层次的 Windows 平台工程；
  2. 项目包含 2774 个受支持源文件；
  3. C/C++、JavaScript、TypeScript 和 C# 共同构成主要实现基础；
  4. packages 和 vnext 是最重要的源码阅读入口；
  5. 项目存在 Yarn、Node.js、CMake 和 Windows 原生构建线索；
  6. 测试证据覆盖 JavaScript、C++、JSI 和 Windows 平台相关区域；
  7. 抽样源码中异步、I/O、分支和异常处理线索较为集中；
  8. 项目具备较完整的工程证据，但仍需 Windows 实机和目标环境验证。

最重要的结论是：

React Native Windows 的核心工程挑战，不只是“能否运行 React Native”，而是 JavaScript 应用层、原生模块、Windows 系统能力和多工具链之间能否稳定协作。

企业采用前，建议优先验证：

  • 目标 Windows 版本兼容性；
  • Node.js、Yarn、Visual Studio 和 Windows SDK 版本；
  • JavaScript 与原生层之间的调用稳定性；
  • Release 构建和应用打包；
  • 原生模块异常、生命周期和线程行为；
  • 依赖供应链和升级回滚能力。

静态源码审阅可以帮助团队快速确定阅读重点，降低技术尽调成本；但最终的性能、稳定性、安全性和生产适配结论，仍必须通过构建、测试、压测和人工审阅获得。

参考资料

  1. Microsoft react-native-windows 官方仓库
    https://github.com/microsoft/react-native-windows

  2. 本文审阅源码快照
    115226a6a85567af3b3d855b47ae7e665f80d91e

  3. React Native Windows 官方文档
    https://microsoft.github.io/react-native-windows/

  4. React Native 官方文档
    https://reactnative.dev/

# microsoft # react native # windows # javascript
Logo
开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

cover

OpenHarmony 标准系统到底是什么？—【万物智能之开源鸿蒙 OpenHarmony 系统实战开发系列教程】

avatar 开源鸿蒙跨平台开发者社区
cover

原来 GitHub Actions 还能直接打包 EXE、IPA、DMG、APK：不用本地搭环境，也不一定需要 Mac

avatar 开源鸿蒙跨平台开发者社区
cover

认识RK3568嵌入式智能设备—【万物智能之开源鸿蒙 OpenHarmony 系统实战开发系列教程】

avatar 开源鸿蒙跨平台开发者社区