React Native跨平台交付：把共享逻辑和平台差异写进同一张验收表

一个移动应用在两种手机上都能打开，并不代表每个功能走的是同一段实现。外包交付或团队接手时，如果说明只有“已支持双端”，后来修改界面的人就难以判断哪些地方可以一起改、哪些需要分别验证。可以从一项具体功能开始，把共享部分与平台差异放在同一张表里。

先认识两种组织方式

React Native官方文档介绍了两种常用方式：在代码中使用Platform模块，以及用平台专用文件扩展名区分实现。文档将小范围差异与较复杂的平台实现分开讨论，并展示了.ios.和.android.文件的选择方式。[1] 这些机制说明代码如何组织，不能单凭采用了某一种机制就认定双端体验已经一致。

从一个按钮开始做交接

下面是自拟的讨论情境：应用里有一个“选择文件”按钮，两端的页面文案相同，但打开后的交互不同。交接表第一栏写共同目标，例如“让用户选择一个允许上传的文件”；第二栏列实现位置；第三栏说明各平台观察到的行为与尚未验证的情况。这里没有声称任何具体应用具备这些功能，只演示如何把需求和证据对上。

如果差异在同一文件的条件分支里，就标出分支位置和存在原因。如果拆成两个平台文件，就把共同接口和两个文件一并记录。不要只列一个文件名，让下一位开发者误以为另一端没有实现；也不要因为两个文件很相像就删掉其中之一。是否能合并，需要结合实际项目再判断。

测试说明要能看见未完成项

为每个平台分别留出设备或模拟器环境、操作步骤、预期结果、实际结果和测试日期。比如“Android已验证，iOS待验证”是一条有用的记录；把它缩写成“按钮正常”则丢失了范围。截图可以辅助说明界面，但不能替代对取消、返回以及输入为空等具体流程的观察。

涉及版本判断时，先核对字段的含义。官方文档特别说明，Android上的Platform.Version表示API版本，而不是Android系统营销版本名称；iOS相关值的表达方式也不同。[1] 交接表应保留实际字段和值的来源，不把两套编号放进一列后直接比较大小。

把差异的来由留下来

每一项平台分支都可以附一句原因：是系统能力不同、界面约定不同，还是项目历史遗留。无法确认的原因写“待原开发者解释”，而不是补一个听起来合理的故事。后续修改时，先回到共同目标，再分别核对两端结果，这张表才能持续有用。

本文提出的是自拟交接方法，没有在读者项目上运行测试。参考来源：[1] React Native，Platform-Specific Code，页面更新于2026年8月12日；本文于2026年10月7日查阅。实际项目还应核对自己所用的框架版本。