1. 为什么要在OpenHarmony上用React Native读写NFC先说结论这个组合能让你用一套JS/TypeScript代码同时覆盖Android、iOS以及OpenHarmony三条业务线NFC标签读取这种硬件能力则通过桥接层交给原生侧处理。我最早接触这个需求是给一款工业巡检设备做配套App。设备跑的是OpenHarmony标准系统但团队里大部分前端同学只会React技术栈如果按传统方式全部用ArkTS重写业务估算下来光UI层就要多写两个月。当时正好OpenHarmony开源社区在推进React Native的适配工作就把RN引了进来。真正让我决定用它做NFC读取的原因有三点第一RN在OpenHarmony上的架构已经能把原生能力暴露成普通JS模块NFC这种系统服务调用起来比想象中顺第二NFC标签解析本身是纯逻辑操作TS写起来比ArkTS更顺手而且生态里现成的解析库可以直接搬第三同一套业务代码后面还能复用到Android平板和iOS手机上对多端交付是实打实的减负。当然这个方案也有代价。OpenHarmony的RN适配版本目前还落后官方主版本一大截很多新特性不能用遇到问题往上排查时可以参考的资料也少。所以这篇文章我不会只讲“怎么做”还会把适配过程中踩过的坑和判断依据一起写出来。无论你是做工业巡检、智慧零售、设备配网还是门禁权限管理只要涉及在OpenHarmony设备上读取RFID/NFC标签这套框架都能给你一个可落地的起点。1.1 这个组合能解决什么实际问题把RN和NFC放一起最典型的场景是这么几类巡检/点检设备上贴NFC标签App靠近即可读取设备编号、上次维保时间判断是否到期。库存/资产管理仓库货架贴标签手机或手持终端一扫弹出物料信息不用人工录入。配网/初始化路由器或智能家电贴标签App读取标签里的Wi-Fi SSID和密码字段一键完成配置。展陈/零售互动商品标签里存URL或智能海报扫码枪和NFC手机都能触发跳转。这些场景里NFC读取只是一个“入口动作”真正的业务跑在UI、网络、数据库这些层。用RN做上层的好处是团队里写业务页面的同学完全不用关心硬件细节只需要调一个readTag()方法拿到对象然后按类型渲染即可。底层是OpenHarmony还是Android对业务代码来说几乎透明。1.2 方案选型背后的三个关键考量很多人第一反应会问OpenHarmony自己明明有NFC接口为什么非要套一层RN我的理由有三个。第一是团队成本。会ArkTS的开发者数量远少于会React的招人、培养都贵而且业务页面一旦复杂起来ArkTS的开发效率并不比RN高。第二是跨端复用。同一个巡检App南方工厂用OpenHarmony手持机北方仓库可能用Android旧平板差异只存在于启动时的平台判断业务代码完全复用。第三是生态。RN的NFC解析库、表单组件、图表组件极其丰富这些在OpenHarmony原生生态里还很薄弱与其自己造轮子不如直接站到RN生态的肩膀上。但我也要提醒一句如果你们的产品只跑OpenHarmony一个平台而且团队里没有React经验那我建议直接用ArkTS写。引入RN会带来JS引擎开销、包体积增加、版本适配滞后等问题单一平台场景下是纯粹的负资产。选RN的前提是“多端一致”的需求真实存在而不是为了技术炫技。2. NFC标签技术基础读数据之前先弄懂这五件事NFC和RFID经常被人混着说其实它们是包含关系。RFID是射频识别技术的统称工作频率覆盖低频、高频、超高频NFC是RFID在高频13.56MHz段的一个子集特点是通信距离近通常小于10cm、支持点对点通信和卡模拟。在OpenHarmony和Android上做标签读取我们打交道的主要是符合ISO 14443/15693标准的Type A/B/V标签以及NFC Forum定义的Type 1到Type 5标签。2.1 标签类型与协议家族要把NFC数据读对第一步是搞清楚你面前的是哪种标签。我在项目里整理过一个速查表标签类型底层协议典型芯片常见用途NDEF支持Type 1ISO 14443ANXP Topaz票务、名片只读为主Type 2ISO 14443ANXP NTAG213/215/216智能海报、防伪支持Type 3ISO 18092 / JIS X 6319-4Sony FeliCa交通卡、电子钱包支持Type 4ISO 14443A/BNXP DESFire、Mifare Plus门禁、支付支持Type 5ISO 15693NXP ICODE SLIX图书管理、药品追溯部分支持OpenHarmony的NFC接口会通过getTagInfo()返回标签的协议类型一般在nfcA、nfcB、nfcF、nfcV、isoDep、ndef等字段里做判断。实际业务里我最常见的是Type 2的NTAG系列因为便宜、稳定、写入流程简单库存和巡检场景用得最多。如果你要做的功能是往标签里写数据优先选Type 2或Type 4如果只是读Type 1也够但兼容性要现场实测。2.2 NDEF数据格式解析绝大多数NFC标签存取的数据是NDEFNFC Data Exchange Format消息。NDEF本质上是一个TLVType-Length-Value结构一条NDEF消息由一个或多个NDEF记录组成每个记录由记录头、类型、载荷长度、可选ID和载荷构成。一个NDEF记录的头部第一个字节拆开看是这样的Bit 7MB消息起始记录1表示这是第一条记录。Bit 6ME消息结束记录1表示这是最后一条记录。Bit 5CF链式记录标志载荷太长被拆分时置1。Bit 4SR短记录标志1表示载荷长度只有1字节0表示用4字节表示长度。Bit 3ILID长度字段是否存在。Bit 2-0TNFType Name Format即类型名格式。这个字节我一开始也是死记硬背后来写了个简单的解析函数才知道SR那位特别容易忽略。很多标签芯片在写入时如果载荷小于256字节会用短记录格式你按4字节去读就把长度算错了。MB和ME同样重要。一个标签里可能有连续多个NDEF记录比如智能海报就是“标题文本记录URI记录Action记录”拼在一起。解析时必须根据MB和ME判断边界否则会把两条记录彻底搅在一起。2.3 命名格式TNF与常用RTD类型TNF字段决定了类型字段怎么解释。NFDEF记录头里TNF的取值范围和含义如下0x00空记录类型和载荷都无效。0x01NFC Forum well-known type类型字段是RTDRecord Type Definition。0x02MIME媒体类型比如text/plain、application/json。0x03绝对URI类型字段就是完整URI。0x04外部类型通常以urn:nfc:ext:domain:type形式存在。0x05未知类型载荷无类型定义。0x06未更改类型用于链式记录的场景。0x07保留。实际项目里TNF0x01的well-known type最常用其中RTD字段又分三种T文本记录载荷前1字节是语言码长度和编码标志bit 7为0表示UTF-81表示UTF-16后面跟着语言码如en、zh和实际文本。UURI记录载荷前1字节是URI标识符前缀索引0x04代表https://0x03代表http://后面才是真正URI。Sp智能海报载荷里嵌套了一个完整的NDEF消息需要递归解析。我在解析“U”记录时吃过一次亏。URI前缀代码表里0x00是“没有前缀”后面直接跟完整URI但如果标签写入工具帮你写了完整https://而前缀索引又填了0x04就会拼出https://https://。这种情况通常不是解析代码的问题而是标签写入工具各自的习惯不同。稳妥的做法是解析完拼接后用正则校验一下把重复协议头的情况拦掉。2.4 标签能力集差异不是所有标签都能写也不是所有标签都能读NDEF。比如Mifare Classic常用于门禁走的是私有协议很多手机和OpenHarmony设备并不把它当作标准NDEF标签暴露出来DESFire要选择应用ID和文件ID才能读到NDEF而且需要先认证涉及密钥交换的部分还是留在原生层处理比较合适。这些标签的读取权限、写入权限、密码保护策略都各不一样做方案设计时一定要提前问清楚现场用的是什么芯片否则代码写完了到现场发现标签类型不匹配整个功能直接废掉。3. 从零搭建RNOpenHarmony开发环境环境搭建是整套流程里最容易让人放弃的一步因为网上资料少、版本杂。我把自己验证过的一整套流程写出来照着做能省不少时间。先说明一下我用的组合是OpenHarmony 4.0 Release标准系统 DevEco Studio 4.0 react-native-ohos 0.72.x分支。这个组合不是最新的但胜在稳定社区反馈和样例代码最全。3.1 开发板与系统版本选择OpenHarmony不是所有设备都支持NFC这一点特别容易被忽略。我最初用的DAYU200开发板系统默认不带NFC驱动翻了半天资料才发现要自己在源码里加NFC芯片驱动并重新编译系统。如果你不想折腾系统编译直接买市面上的OpenHarmony商用设备比如带NFC的扫码手持终端、RK3566/RK3588方案的面板通常出厂系统已经带好NFC功能。系统版本建议选标准系统StandardAPI Level大于等于9。OpenHarmony的NFC Tag接口在API 6就有了但API 9之后才把权限模型稳定下来API 8及以下很多接口行为不一致排查起来很痛苦。客户端设备建议用API 9或10。3.2 环境依赖安装需要装的有这些Node.js 18建议LTS版本RNOH的工具链对Node版本比较敏感太新的版本偶尔会有兼容告警。OpenHarmony SDK通过DevEco Studio的SDK Manager下载注意勾选API 9或10的SDK。react-native-ohos相关CLI工具react-native-ohos/cli。开发板连接电脑用的串口工具或HDC工具OpenHarmony的调试工具类似Android的adb。安装完成后确认hdc list targets能看到设备就说明连接正常。NDK方面OpenHarmony的NDK路径通常和DevEco Studio装在一起CMake和交叉编译工具链也需要提前备好编译原生模块时要用。3.3 工程初始化与目录结构用CLI初始化工程npx react-native-ohos/cli init RNNfcDemo cd RNNfcDemo初始化完成后工程结构和标准RN项目很接近多出的关键是harmony目录里面放的是OpenHarmony的entry模块和原生代码。RNOH开发的原理是把RN的C核心、JS引擎、渲染器等编译成OpenHarmony的动态库然后在ArkTS侧创建一个容器组件来承载RN页面。NFC这样的原生能力通过自定义原生模块的方式暴露给JS层调用。这个架构决定了目录里有两个需要注意的入口harmony/entry/src/main/ets/: 这里面是ArkTS写的入口和容器组件RN页面会挂在某个组件上。harmony/entry/src/main/cpp/: 这里放C层代码NAPINative API的注册和桥接工作在这里完成。3.4 跑通Hello World的检验清单初始化后先别急着写NFC功能把基础工程跑通再说。我在首次运行时遇到的问题是启动白屏这是RNOH社区里的高频问题后面会在排查章节详细写。这里先列一个我自己用的检验清单[ ]hdc shell param get const.product.name能返回设备型号[ ] 工程能成功编译出entry-default-signed.hap[ ] 通过DevEco Studio安装HAP点击图标能进入RN页面[ ] 打开DevEco的日志面板能看到RNOH加载完成的日志比如RNOH: ReactApplicationContext created之类[ ] 在RN页面里随便写个Text带中文和Emoji确认渲染正常这五步都过说明RNOH基础链路是通的后面加原生模块只是在这个框架上做增量。4. 原生侧NFC模块实现NFC读取这件事必须放在原生侧做原因很简单RN层拿不到OpenHarmony的NFC系统服务。所以我们先写一个ArkTS模块负责扫描标签、解析NDEF数据再用NAPI把它暴露成JS层可调用的方法。4.1 权限声明与Tag发现回调在module.json5里声明NFC相关权限{ module: { requestPermissions: [ { name: ohos.permission.NFC_TAG_READ } ] } }如果后面要做写入功能还要加ohos.permission.NFC_TAG_WRITE。注意权限名字的大小写写错了编译不报错但运行时拿不到标签。OpenHarmony的NFC标签发现是回调机制。在ArkTS侧我们通过ohos.nfc.tag模块注册监听import nfcTag from ohos.nfc.tag; import { BusinessError } from ohos.base; // 获取tagInfo需要先启动NFC扫描 function startNfcScan(): void { nfcTag.on(notify, (tagInfo: nfcTag.TagInfo) { // 标签靠近时触发 const tagId tagInfo.tagId; // 判断是否支持NDEF if (tagInfo.ndefSupported) { // 读取NDEF数据 } }); }这里的tagInfo对象里有一个非常重要的字段tagInfo.ndefSupported它在底层是通过轮询标签的ATQA、SAK和协议能力综合判断的。有些标签虽然物理上支持NDEF但状态损坏或写入了非法数据这个字段可能为false这时候别硬读让用户换一张标签更合理。4.2 NDEF消息解析的ArkTS实现拿到NDEF标签后最核心的工作是解析NDEF消息。这里补一段ArkTS侧的解析代码import nfcTag from ohos.nfc.tag; import ndef from ohos.nfc.tag.ndef; import { util } from kit.ArkTS; class NdefRecord { tnf: number 0; type: Uint8Array new Uint8Array(); id: Uint8Array new Uint8Array(); payload: Uint8Array new Uint8Array(); } function parseNdefMessage(tag: nfcTag.TagInfo): NdefRecord[] { const ndefTag ndef.getNdefTag(tag); if (ndefTag null) { return []; } const msg ndefTag.getNdefMessage(); if (msg null) { return []; } const records: NdefRecord[] []; msg.forEach((record) { const r: NdefRecord { tnf: record.tnf, type: record.type, id: record.id, payload: record.payload }; records.push(r); }); return records; }注意这里record.type和record.payload返回的是Uint8Array不是字符串。很多刚接触的人直接对record.payload做toString()结果得到一长串数字和逗号。正确做法是先用UTF-8解码再按NDEF规则解析。文本类型还要处理语言码和编码标志位URI类型则要查前缀表。我把NDEF记录的解析收敛成一个纯函数这样方便在ArkTS和JS层共用一套测试用例。解析文本记录时UTD-8和UTF-16的判断要严格按payload首字节的bit 7来很多国产标签写入器默认写UTF-8但也有用UTF-16的判断错了整段文本都是乱码。4.3 NAPI桥接层映射原生能力要暴露给RN层需要通过NAPI注册一个模块。RNOH的桥接方式和标准RN略有不同它基于ArkTS的NativeModule能力封装了一套turboModule协议。我们在ArkTS侧定义方法NativeModule export class NfcModule { Method readNdefTag(): Promisestring { // 内部实现... } }然后在RN侧通过TurboModuleRegistry.get或NativeModules获取import { NativeModules } from react-native; const { NfcModule } NativeModules;读取后的结果我用JSON字符串传递因为只传序列化数据最容易保证跨语言边界一致。结构体直接传对象虽然NAPI也支持但字段多了容易踩“undefined被认为是0”的坑不如JSON字符串干脆。原生侧每次读取完会返回一个对象{ tagId, records, rawMessage }其中records是一个数组里面每个元素包含tnf、type、payloadText、payloadUri这些解析后的字段。JS层拿到后基本不需要再做二进制处理直接渲染即可。5. JS侧业务逻辑与界面原生侧把数据吐出来以后真正干活的是JS层。这也是用RN做这个项目最爽的部分——业务逻辑用TypeScript写类型清晰测试方便。5.1 封装NFC读取工具类我在JS层封装了一个NfcManager工具类统一管理“开始扫描”“停止扫描”“读取标签”这三件事import { NativeModules, NativeEventEmitter } from react-native; const { NfcModule } NativeModules; const nfcEmitter new NativeEventEmitter(NfcModule); export type NdefRecordType { tnf: number; type: string; payloadText?: string; payloadUri?: string; }; export type NfcTagData { tagId: string; records: NdefRecordType[]; }; class NfcManager { private scanning: boolean false; startScan(): void { if (this.scanning) return; NfcModule.startScan(); this.scanning true; } stopScan(): void { if (!this.scanning) return; NfcModule.stopScan(); this.scanning false; } readTag(): PromiseNfcTagData { return NfcModule.readNdefTag(); } onTagDetected(callback: (data: NfcTagData) void) { return nfcEmitter.addListener(onTagDetected, callback); } } export default new NfcManager();这里有个设计细节值得说NFC扫描是一个持续动作不应该每读一次就开一次关一次。标签靠近后系统触发回调数据读出来以后可以继续扫描等待下一张标签。所以startScan和stopScan是成对的生命周期管理在页面useEffect里启动页面卸载时停止。NativeEventEmitter用于原生向JS侧主动推送“标签已检测到”的事件比轮询更优雅。轮询方案在低端设备上会频繁唤醒NFC模块耗电且容易漏事件不推荐。5.2 按NDEF类型动态解析文本、URI、智能海报原生侧返回的records已经做了初步解析但JS侧还是需要按tnf和type字段做二次分发。比如tnf1且typeU的记录payload是一个URItnf1且typeT的记录payload是文本tnf1且typeSp是智能海报里面嵌套的NDEF消息会以JSON字符串形式放在payload里JS侧要再解析一次。我把整个解析流程写得像一个管道function parseNdefRecords(records: NdefRecordType[]): ParsedContent[] { return records.map((record) { if (record.tnf 1) { const type record.type.toLowerCase(); switch (type) { case t: return { kind: text, content: record.payloadText || }; case u: return { kind: uri, content: record.payloadUri || }; case sp: return { kind: smartposter, content: JSON.parse(record.payloadText || {}) }; default: return { kind: unknown, content: record.payloadText || }; } } if (record.tnf 2) { // MIME类型比如text/plain return { kind: mime, content: record.payloadText || }; } return { kind: unknown, content: record.payloadText || }; }); }这段代码在实际业务里可以根据场景扩展。比如读到一个URI前端可以直接渲染成可点击的链接读到一个文本可以匹配正则判断是不是设备序列号是的话自动跳转到对应的设备详情页。我把“解析”和“业务动作”分开解析只负责把NDEF转成业务对象业务动作由页面层根据对象类型自己去分发这样更符合React的组件化思维。5.3 防重复扫描与节流处理NFC标签在感应区内停留时系统可能连续上报十几次“标签已检测到”。如果每次回调都去刷新页面列表会疯狂闪烁。我一开始没注意这个问题现场演示时一贴上标签页面内容跳了好几遍非常尴尬。解决方案是加节流。在NfcManager里维护一个lastReadAt时间戳两次读取之间至少间隔1.5秒private lastReadAt: number 0; private readonly throttleMs 1500; onTagDetected(callback: (data: NfcTagData) void) { return nfcEmitter.addListener(onTagDetected, (data) { const now Date.now(); if (now - this.lastReadAt this.throttleMs) { return; } this.lastReadAt now; callback(data); }); }另外还有一个“是否同一张标签”的判断。因为在巡检场景里用户可能扫完A标签后不小心又晃到B标签需要区分是重复上报同一张还是新标签。我简单用tagId做去重如果同一张标签连续上报直接忽略如果tagId变了立即刷新。节流间隔不宜设太长否则用户快速连续扫两张不同标签时会漏掉第二张。1.2到1.5秒是现场实测比较舒服的区间既不会防抖过头也不会重复刷新。5.4 业务界面示例以巡检为例一个最简页面是这样import React, { useEffect, useState } from react; import { View, Text, TouchableOpacity, ScrollView } from react-native; import NfcManager from ./NfcManager; export function NfcReaderScreen() { const [tagInfo, setTagInfo] useStateNfcTagData | null(null); const [scanning, setScanning] useState(false); useEffect(() { const sub NfcManager.onTagDetected((data) { setTagInfo(data); }); return () { sub.remove(); NfcManager.stopScan(); }; }, []); const start () { NfcManager.startScan(); setScanning(true); }; return ( View style{{ flex: 1, padding: 20 }} TouchableOpacity onPress{start} disabled{scanning} Text{scanning ? 扫描中... : 开始扫描}/Text /TouchableOpacity {tagInfo ( ScrollView style{{ marginTop: 20 }} Text标签ID: {tagInfo.tagId}/Text {tagInfo.records.map((rec, idx) ( Text key{idx} {rec.payloadText || rec.payloadUri || 未知内容} /Text ))} /ScrollView )} /View ); }页面逻辑非常简单因为复杂的事情都在原生解析和工具类里做掉了。实际项目中我还会加一个“已扫描设备列表”把每次读到的标签按时间戳存进列表方便回看。这个列表可以直接用SectionList来做按天分组。6. 常见问题与排查实录RNOH加NFC这套组合网上可搜到的踩坑记录不多很多问题只能现场试错。我把实际遇到的高频问题整理成了一份速查表按排查顺序排列。现象可能原因排查方法标签贴近开发板完全无反应NFC服务未开启或驱动未加载系统设置查看NFC开关hdc shell hidumper -s NFC查看服务状态能扫描到标签但拿不到NDEF数据标签未格式化或为空标签用专业写入工具先写入一条合法NDEF记录再测试读出来的文本乱码UTF-8/UTF-16编码判断错误检查payload首字节bit 7标志位连续扫描时页面重复刷新缺少节流/去重在NfcManager里加时间戳和tagId去重RN页面首次打开白屏RNOH加载慢或日志没输出排查JS bundle路径、等待时间、重启App编译报错NAPI类型不匹配ArkTS和C类型映射错误统一用string和JSON.stringify传参权限请求成功但读取失败动态权限二次确认未处理在页面启动时主动申请并确认授权结果6.1 扫描无响应的五步排查如果标签贴近设备后RN页面什么事都没发生我的排查顺序是第一步确认真机NFC开关是开的。OpenHarmony的部分开发板默认关闭NFC而且不提示用户这个坑最浅但最容易忽略。第二步确认权限有加且已动态授权。OpenHarmony的权限模型要求运行时弹窗确认如果用户点了拒绝后面所有调用都是静默失败。第三步用系统自带工具验证标签。找一台Android手机装个NFC Tools把同一张标签贴上如果Android也读不到说明标签坏了或者格式不对。第四步看HDC日志里有没有NFC服务报错。hdc shell hilog | grep NFC是最直接的排查手段错误信息里通常会写明协议不匹配或超时。第五步检查标签类型。如果标签是FelicaType 3而设备NFC天线只适配了Type A/B读不到是正常的。这个排查顺序能覆盖90%以上的“无反应”问题。别一上来就怀疑代码硬件和系统层面的问题概率更大。6.2 NDEF数据读出来是乱码乱码问题的根源几乎都在编码判断上。NDEF文本记录的第一字节bit 7为0表示UTF-8为1表示UTF-16。很多标签写入器在写中文时默认用UTF-8但部分进口工具默认用UTF-16而文本长度记录的是字节数不是字符数解析错编码会直接导致乱码或截断。我在原生解析代码里加了一个回退机制如果按UTF-8解码后发现包含大量不可见字符比如UFFFD替换符就尝试按UTF-16解码一次。这个策略在实测里能把兼容性拉高不少。但要注意回退解码只能用于展示型场景不能用于后续的逻辑匹配因为不可靠。生产环境还是要靠写入端约定统一的编码标准。6.3 TagLost与超时错误TagLost是NFC开发中特别常见的异常意思是“标签在通信过程中离开了感应区”或“设备在等待标签响应时标签已移走”。这个问题在手持设备上尤其明显因为人手会难免抖动。遇到TagLost正确做法不是报错而是提示用户重新贴近。我在原生层捕获TagLostException后会向JS层抛一个友好错误码TAG_LOSTJS侧拿到后弹一个Toast“请重新贴近标签”同时保持扫描状态不变。这样用户体验会自然很多而不是直接退出页面。6.4 真机调试与日志查看技巧RN页面和OpenHarmony原生日志是两套体系排查时要两边一起看。RN侧的console.log可以通过DevEco Studio的Log面板看到因为RNOH会把JS日志转发到hilog。但注意console.info和console.warn的输出级别不同DevEco默认过滤了verbose级别的日志有时候看不到是级别问题不是没打印。原生侧日志统一用hilog查看hdc shell hilog -r hdc shell hilog | grep -i nfc hdc shell hilog | grep -i ndef如果怀疑RNOH本身有问题可以开RNOH的调试模式看RNOH_LOG级别的输出。常见白屏问题里最多的是JS bundle路径配置错误或者双端OpenHarmony和RN的版本不匹配日志里通常会有明确的Unable to load script或Dependency mismatch字样。我还建议在原生解析代码里加上分阶段日志收到onNotify打一条、检查到NDEF能力打一条、解析完成打一条。这样一旦出现问题通过日志能快速定位是“没检测到”“不支持NDEF”还是“解析异常”。这种埋点习惯在嵌入式平台上特别管用因为现场排查往往没有断点调试条件。写在最后的一点个人体会NFC读取这种功能说难不难无非是“拿到tag、解析NDEF、渲染数据”三步。但真要落到OpenHarmony加RN这套组合上细节却比想象中多得多。我个人最大的体会是跨语言边界传数据时一定要收敛数据结构能传字符串绝不传对象能JSON序列化绝不裸传。这个原则帮我躲过了很多NAPI类型映射的暗坑。另外一点如果你打算在项目里批量写入标签比如给一批库存商品快速写入初始信息我强烈建议把写入能力也做成原生模块和读取放到同一个模块里统一管理。写入逻辑比读取复杂需要校验标签状态、按区块写入、验证写入结果用RN写纯逻辑还可以但涉及底层扇区操作最好还是留在ArkTS侧。一个库里把读写都封好后续维护起来会轻松很多。最后再分享一个小技巧开发期间准备三张不同厂商的标签放在桌上一张Type 2、一张Type 4、一张只支持RFID不支持NDEF的。每次改完代码三张全扫一遍能让你在30秒内发现兼容性回归。这个习惯我在做NFC项目时一直保留建议你也试试。