手上做过好几个带 NFC 交互的线下项目，从门店会员卡到展台打卡，客户的需求描述几乎一模一样：手机贴一下，装了 App 就直接打开，没装就跳到应用市场去下载。这句话说出口只要三秒，但真正落到 Android 和 iOS 两端去实现，你会发现两者的能力边界差了整整一个数量级。Android 这边，只要在标签里写一条android.com:pkg的 AAR 记录，系统就会主动帮你完成"未安装跳应用市场"这件事；iOS 那边，iPhone 压根不允许第三方标签在用户没确认的情况下把 App 拉起来，你能做到的最好效果是弹一条通知横幅，等用户抬手点一下。
这篇内容我打算把这条链路上所有的关键环节摊开讲：NDEF 记录的字节结构怎么算、AAR 到底放在消息的第几条、iOS 的 Universal Link 要配哪几个文件、落地页的 UA 判断怎么写、国内几家安卓厂商的应用市场 scheme 长什么样、以及我踩过的那些"明明写了卡就是没反应"的坑。适合正在做线下硬件联动 App 的开发者、做活动物料的运营同学，以及第一次接触 NFC 标签、还在纠结买 NTAG213 还是 NTAG216 的朋友。代码以 Android（Kotlin）和 iOS（Swift）为主，关键配置直接给可复制的完整片段，你照着改包名和域名就能跑。
1. 需求拆解：一句话需求背后的三种技术路径
1.1 "贴一下自动打开"到底是谁在干活
很多人第一次做这个需求时的直觉是：我在 App 里开个 NFC 读取会话，检测到标签就跳转不就行了。这个思路在 Android 上勉强能用，但在 iOS 上基本等于白做，因为 iOS 的后台标签读取根本不会把控制权交给你的 App，它由系统直接处理。
真正让"贴一下打开 App"成立的，是操作系统内置的 NDEF 标签分发机制，而不是你的 App 主动去读卡。流程是这样的：手机的天线感应到场强变化，NFC 控制器被唤醒，系统框架层读到标签里的 NDEF 消息，然后拿这条消息去问一句"在场有没有哪个应用愿意处理这个内容"。有，就启动那个应用并把数据递过去；没有，就看消息里有没有指向应用商店的线索。
理解这个顺序非常重要，它决定了你做这件事的着力点根本不在客户端代码，而在标签里写什么。客户端要做的只是"声明我愿意处理这类内容"和"处理完别忘了埋点"。
所以整个方案可以拆成三块：标签数据的构造、App 侧的接收声明、以及"没装 App 时怎么把用户送到正确的商店"。第三块在两端差异最大，也是这篇文章的重点。
1.2 三种路径的能力对照
把常见做法列一下，你能直观看出为什么最后大家都会收敛到 NDEF + 落地页这个组合。
| 实现路径 | Android 可行性 | iOS 可行性 | 关键限制 |
|---|---|---|---|
| 系统 NDEF 分发 + 自定义 URL Scheme | 可用 | 不可用于后台读取 | Scheme 无兜底，未安装直接失败 |
| 系统 NDEF 分发 + AAR 记录 | 官方支持，可跳商店 | 无此机制 | AAR 是 Android 独有 |
| 系统 NDEF 分发 + Universal Link | 可用（App Links） | 官方推荐 | 必须配 AASA 文件且走 HTTPS |
| App 内常驻前台读卡 | 可用但体验差 | 仅 App 处于前台时可用 | 用户得先打开 App，逻辑上死循环 |
| HCE 卡模拟 | 可用 | 仅限特定场景 | 方向反了，这是被读不是读 |
看到这里结论就很清楚了：Android 主推 AAR + URI 双记录，iOS 只能靠 Universal Link + 服务端落地页分流。一套标签同时服务两端完全可行，代价是标签里要多塞一条记录，容量得算清楚。
1.3 标签芯片选型：别买回来才发现写不下
NFC 标签的容量指的是用户可写数据区，不是标称的"总容量"。常见的 NTAG 系列实际可用空间如下：
| 型号 | 用户区容量 | 实际可写 NDEF 消息约 | 适用场景 |
|---|---|---|---|
| NTAG213 | 144 字节 | 约 137 字节 | 只写一条短 URL 或一条 AAR |
| NTAG215 | 504 字节 | 约 492 字节 | URL + AAR + 业务参数，推荐 |
| NTAG216 | 888 字节 | 约 872 字节 | 参数很多、带签名校验串 |
| Mifare Classic 1K | 1024 字节 | 约 700+ 字节 | 兼容性一般，不推荐新项目用 |
为什么推荐 NTAG215？因为它刚好覆盖了"一条 https 落地页 URL + 一条 AAR + 几个业务参数"这个最典型的组合，价格也就比 213 贵几毛钱。NTAG213 在只有短域名的时候够用，但你的 URL 一旦带上渠道号和活动 ID，很容易顶到上限。I2C 那一类带加密的芯片（比如 NTAG 424 DNA）在防复制上有优势，但读写工具和手机兼容性都要单独验证，不是所有安卓机都认。
NFC 的通信距离通常只有 2 到 4 厘米，标签贴纸的安装位置要避开金属背板和电池仓。贴在金属上必须用抗金属标签，否则场强被吸收，手机贴上去毫无反应，这个坑我第一次做门店桌贴的时候就踩过。
2. Android 端实现：AAR 是唯一能让系统帮你跳市场的钥匙
2.1 Android 的 NDEF 分发优先级到底怎么排
Android 系统在读到标签后会依次尝试三种 Intent，优先级从高到低是ACTION_NDEF_DISCOVERED、ACTION_TECH_DISCOVERED、ACTION_TAG_DISCOVERED。前一个没匹配到应用，才会降级尝试下一个。这个设计的意义在于：能理解内容的应用优先，只能理解标签物理技术的应用兜底，什么都不懂的才走最末一级。
实际开发中最容易出问题的是"匹配到多个应用"。比如你写了 https 链接，而手机上装了好几个浏览器、微信、支付宝，系统就会弹一个选择器让用户挑。用户看到弹窗的那一瞬间，你精心设计的"无感"体验就碎了。这就是为什么必须用 AAR。
AAR 全称 Android Application Record，它在 NDEF 里的类型名固定是android.com:pkg，载荷就是你的应用包名。系统读到这条记录后，行为链条是这样的：
- 先用 NDEF 里的其他记录（比如 URI）构造 Intent，看有没有应用能接。
- 如果能接的应用就是 AAR 指定的那个包，直接启动它，不弹选择器。
- 如果没匹配到任何应用，或者匹配到的不是指定包，就尝试直接按包名启动该应用。
- 如果这个包名的应用根本没装，系统会构造一个应用市场的 Intent（本质上是
market://details?id=包名），交给设备上处理该协议的应用。
第 4 步就是"未安装跳应用市场"的免费实现。你什么都不用写，系统替你做完了。
AAR 记录必须放在 NDEF 消息的最后一条。放在中间会导致它后面的记录被忽略，这是 Android 的既定行为，很多教程没提，结果写完卡测试时发现参数丢了，排查半天。
2.2 NDEF 记录的字节结构拆解
动手写卡之前，先搞清楚一条 NDEF 记录长什么样，出问题时你才能看懂工具报的错。
每条记录由三部分组成：头部（Header）、类型字段（Type）和载荷（Payload）。头部通常 3 字节（短记录模式），第一个字节是标志位，第二个字节是类型字段长度，第三个字节是载荷长度。
第一个字节的位定义是这样的：最高位MB（Message Begin）标记消息的第一条记录，次高位ME（Message End）标记最后一条，接着是CF（分块标志）和SR（短记录标志），再往下是IL（ID 长度标志），最低三位是TNF（类型名格式）。
按这个规则算一下：
- URI 记录用知名类型，TNF 为 1，类型字段是单个字符
U（0x55）。它如果不是最后一条，标志位是MB=1, ME=0, SR=1，合成十进制就是 0x91。 - AAR 记录用外部类型，TNF 为 4，类型字段是 15 个字节的字符串
android.com:pkg。它是最后一条，标志位是MB=0, ME=1, SR=1，合成 0x54。
URI 记录的载荷还有一个额外规则：第一个字节是 URI 前缀缩写码，用来省空间。常见对照如下：
| 前缀码 | 对应的 URI 前缀 |
|---|---|
| 0x00 | 无前缀，原样解析 |
| 0x01 | http://www. |
| 0x02 | https://www. |
| 0x03 | http:// |
| 0x04 | https:// |
| 0x05 | tel: |
所以你写https://nfc.example.com/c/12345时，实际字节只有缩写码 0x04 加上nfc.example.com/c/12345，省掉了 8 个字节。标签容量紧张的时候这几字节很关键。
2.3 Manifest 与 Activity 的完整配置
先说声明部分。业务 Activity 需要在 AndroidManifest 里注册两类 intent-filter，一类是针对 URI 内容的，一类是针对物理技术的兜底。
<activity android:name=".nfc.NfcEntryActivity" android:exported="true" android:launchMode="singleTask" android:excludeFromRecents="true"> <intent-filter android:priority="100"> <action android:name="android.nfc.action.NDEF_DISCOVERED" /> <category android:name="android.intent.category.DEFAULT" /> <data android:scheme="https" android:host="nfc.example.com" /> </intent-filter> <intent-filter> <action android:name="android.nfc.action.TECH_DISCOVERED" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> <meta-data android:name="android.nfc.action.TECH_DISCOVERED" android:resource="@xml/nfc_tech_filter" /> </activity>launchMode用singleTask是有讲究的。用户贴卡的场景下，如果 App 已经在后台，你肯定不希望再开一个新实例把用户之前的操作状态冲掉。excludeFromRecents是顺手加上的，让这个入口 Activity 不出现在最近任务列表里，用户回退时不会看到一个空白页。
nfc_tech_filter.xml的内容：
<?xml version="1.0" encoding="utf-8"?> <resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2"> <tech-list> <tech>android.nfc.tech.NfcA</tech> <tech>android.nfc.tech.Ndef</tech> </tech-list> </resources>tech-list里写多个tech是"与"关系，必须同时满足；写多个tech-list才是"或"关系。NTAG213/215 用的是 NfcA 协议，这里必须写 NfcA，只写 Ndef 在部分 ROM 上匹配不到。
2.4 接收 Intent 与解析参数
Activity 里要处理两条入口：冷启动走onCreate，热启动走onNewIntent。两个都要写，否则 App 在后台时贴卡没反应。
class NfcEntryActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) handleNfcIntent(intent) } override fun onNewIntent(intent: Intent) { super.onNewIntent(intent) setIntent(intent) handleNfcIntent(intent) } private fun handleNfcIntent(target: Intent?) { target ?: return val action = target.action ?: return if (action != NfcAdapter.ACTION_NDEF_DISCOVERED && action != NfcAdapter.ACTION_TECH_DISCOVERED && action != NfcAdapter.ACTION_TAG_DISCOVERED ) return val tagId = target.getParcelableExtra<Tag>(NfcAdapter.EXTRA_TAG) ?.id?.joinToString("") { "%02X".format(it) } val rawMessages = target.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES) val uri = rawMessages ?.filterIsInstance<NdefMessage>() ?.flatMap { it.records.asList() } ?.firstOrNull { it.tnf == NdefRecord.TNF_WELL_KNOWN && it.type.contentEquals(NdefRecord.RTD_URI) } ?.toUri() // uri 里带着渠道参数，tagId 用于后续埋点去重 routeToTarget(uri, tagId) } private fun routeToTarget(uri: Uri?, tagId: String?) { // 解析 path 和 query，决定跳首页、活动页还是详情页 } }这里有几个经验点值得单独说。tagId一定要取，它是标签的物理 UID，用来做"同一张卡一天只记一次"的埋点去重，不然用户反复贴卡会把你的事件量刷爆。另外toUri()在解析失败时会抛异常，生产代码一定要包一层 try-catch，我见过因为标签被写过奇怪内容导致入口页直接崩溃的线上事故。
2.5 未安装时跳应用市场的三条备选路线
AAR 带来的系统级跳转是最省事的，但它有个副作用：跳哪个商店由系统决定，通常就是设备预装的厂商商店。这对大多数项目来说没问题，但如果你有强渠道诉求，就需要额外的兜底逻辑。
第一条路线是 AAR 裸用，什么都不加。适合"随便哪个商店都行"的场景，代码零成本。
第二条路线是在 NDEF 里把 URI 指向你自己域名的落地页，落地页里用 JS 依次尝试各家市场的 scheme。这样做的前提是你的 App 已经安装了能接住这些 scheme 的应用，但用户没装你的 App，所以这条路只能靠落地页兜底，而不是靠标签。
第三条路线是 App Links 兜底。把 https 域名配好autoVerify="true"，标签里的 URI 指向这个域名，用户装了 App 并且系统校验通过时直接打开 App 对应页面，没装就走浏览器打开落地页，落地页再做分流。这条路和第一条并不冲突，事实上我通常两个都配：AAR 负责"装了就直接进"，URI 负责"没装时有网页兜底"。
<intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="https" android:host="nfc.example.com" /> </intent-filter>autoVerify需要服务端在https://nfc.example.com/.well-known/assetlinks.json提供校验文件。
[ { "relation": ["delegate_permission/common.handle_all_urls"], "target": { "namespace": "android_app", "package_name": "com.example.myapp", "sha256_cert_fingerprints": ["你的签名证书 SHA256 指纹"] } } ]指纹从签名 keystore 里取，用keytool -list -v -keystore your.jks就能看到。注意这里要填的是正式签名的指纹，很多人调试用的 debug 签名跑通了，换成正式包就失效，原因就在这里。多环境（测试、正式）需要把两个指纹都列进数组。
3. iOS 端实现：Universal Link 是唯一靠谱的答案
3.1 后台读取的硬件门槛和那道绕不过的通知横幅
先泼一盆冷水：iOS 上做不到 Android 那种"贴一下直接进 App"。iPhone 的后台 NFC 标签读取由系统统一接管，第三方 App 没有机会干预决策过程。
硬件门槛也得说清楚。前台读取（App 打开着）从 iPhone 7 和 iOS 11 开始支持，需要你的 App 调用 CoreNFC 会话；后台读取（App 没开）要求 iPhone XS、XR 及之后的机型，因为需要 A12 及更新的芯片配合。老机型用户贴上去毫无反应，这不是你的代码问题。
再说那个通知横幅。即使机型支持，iOS 13 及之后的系统会在读到标签后先弹一条通知，写着"已检测到 NFC 标签"，用户点一下才会继续处理链接。这意味着你的转化链路上天然多了一次点击，做数据预估的时候必须把这个损耗算进去，别拿着 Android 的转化率去套 iOS。
还有一个容易被忽略的细节：iPhone 在亮屏状态下才响应标签。熄屏放着不动是读不到的，用户需要按一下电源键把屏幕点亮，或者把手机拿起来触发抬手唤醒。这个行为对线下物料的引导文案设计影响很大，桌贴上最好加一句"点亮屏幕后贴一下"。
3.2 Universal Link 从 AASA 文件到 Associated Domains
iOS 侧的核心是把标签里的 URI 写成一个能被 Universal Link 接住的地址。整个配置分四步。
第一步，写 AASA 文件，放在https://nfc.example.com/.well-known/apple-app-site-association。注意这个路径没有扩展名，Content-Type 要是application/json，而且必须能通过 HTTPS 直接访问，不能有任何重定向。很多 CDN 默认会把无扩展名的文件当成 404 处理，这是配置失败的常见原因。
{ "applinks": { "details": [ { "appIDs": ["ABCDE12345.com.example.myapp"], "components": [ { "/": "/nfc/*", "comment": "NFC 标签入口" } ] } ] } }appIDs是 Team ID 加包名拼起来的，中间用点连接。Team ID 在开发者账号后台的 Membership 页面能看到，是 10 位大写字母数字。新版本的 AASA 格式推荐用components而不是老的paths，因为components支持排除规则和查询参数匹配，控制粒度更细。
第二步，在 Xcode 里给 App 打开 Associated Domains 能力，添加一条applinks:nfc.example.com。注意这里不带https://，也不带路径。
第三步，App 里处理入口。用 SwiftUI 的话是onContinueUserActivity，用 UIKit 的话是application(_:continue:restorationHandler:)。
.onContinueUserActivity(NSUserActivityTypeBrowsingWeb) { activity in guard let url = activity.webpageURL else { return } // url.host 应该是 nfc.example.com // url.path 形如 /nfc/12345 let channel = URLComponents(url: url, resolvingAgainstBaseURL: false)? .queryItems?.first(where: { $0.name == "ch" })?.value router.open(path: url.path, channel: channel) }第四步，验证。Xcode 里没有直接的调试面板，我的做法是把 Universal Link 地址发到备忘录里，点击后看是否跳转。如果跳的是 Safari 而不是 App，九成是 AASA 文件的问题。
苹果有个 AASA 的 CDN 缓存，文件更新后不会立刻生效，通常需要几分钟到几小时。调试期间如果反复改 AASA 都没反应，别怀疑人生，换个域名路径或者等一等。开发阶段可以用
?mode=developer这类技巧绕过，但正式环境一定要走正常路径。
3.3 标签里到底写什么
iOS 系统读取标签时，会解析 NDEF 消息里的 URI 记录。所以标签内容对 iOS 来说比 Android 简单得多：一条指向你的 Universal Link 域名的 https 记录就够了。
关键在于同一份数据要同时喂饱两端。我的标准做法是标签里写两条记录：
- 第一条：URI 记录，内容是
https://nfc.example.com/nfc/12345?ch=storeA。 - 第二条：AAR 记录，内容是
com.example.myapp。
Android 端两条都能用上，iOS 端忽略第二条只认第一条。这样统一物料，仓库管理也简单，不会出现"这批卡是给安卓的、那批是给苹果的"这种让运营抓狂的情况。
3.4 落地页分流：一段 UA 判断省掉一半麻烦
当用户没装 App 时，Universal Link 会老老实实打开 Safari 加载你的落地页。这时候页面要负责把用户送到正确的商店。
最稳的判断方式是在服务端做一次 UA 识别，而不是纯靠前端 JS。服务端拿到 User-Agent 后，返回不同的跳转指令，能规避一部分浏览器对 JS 跳转的拦截。
// 前端兜底逻辑，服务端已判断过则可直接跳过 const ua = navigator.userAgent; const isIOS = /iPhone|iPad|iPod/i.test(ua); const isAndroid = /Android/i.test(ua); if (isIOS) { // 苹果只有唯一商店，直接跳 location.replace('https://apps.apple.com/cn/app/id你的数字ID'); } else if (isAndroid) { // 安卓按厂商分流，具体 scheme 见下一节 location.replace('/download/android?ch=' + channel); }iOS 这块反而最简单，因为 App Store 只有一个地址，https://apps.apple.com/cn/app/idXXXXXXXX里的数字 ID 在 App Store Connect 里能查到。安卓就麻烦多了，下面单独说。
4. 实操全流程：从写卡到真机验证
4.1 用脚本生成 NDEF 字节流
批量做卡的时候，一条条手写不现实。我一般用 Python 生成原始字节流，再通过读写器批量烧录。核心是两个构造函数。
def build_uri_record(uri: str, is_last: bool) -> bytes: prefix_map = { "https://www.": 0x02, "http://www.": 0x01, "https://": 0x04, "http://": 0x03, "tel:": 0x05, } payload = None for prefix, code in prefix_map.items(): if uri.startswith(prefix): payload = bytes([code]) + uri[len(prefix):].encode("utf-8") break if payload is None: payload = bytes([0x00]) + uri.encode("utf-8") mb = 0x00 if is_last else 0x80 me = 0x40 if is_last else 0x00 header = bytes([mb | me | 0x10 | 0x01, 0x01, len(payload)]) return header + b"U" + payload def build_aar_record(package_name: str) -> bytes: type_bytes = b"android.com:pkg" # 长度 15 payload = package_name.encode("utf-8") header = bytes([0x40 | 0x10 | 0x04, len(type_bytes), len(payload)]) return header + type_bytes + payload msg = build_uri_record("https://nfc.example.com/nfc/12345?ch=storeA", False) msg += build_aar_record("com.example.myapp") print("NDEF 消息长度:", len(msg), "字节") print(msg.hex(" "))这段脚本里最值得盯的是那两个标志位字节。URI 记录如果不是最后一条，MB位置 1、ME位保持 0，算出来就是 0x91；AAR 是最后一条，MB位归 0、ME位置 1，配合 SR 和 TNF=4，得到 0x54。算错一位，写进去的标签要么解析不出来，要么只识别前半段。
4.2 容量核算与写入方式
拿一个真实例子算笔账。包名com.example.myapp是 18 个字符，那么：
| 记录 | 计算过程 | 字节数 |
|---|---|---|
| URI 记录头 | 3 字节固定 | 3 |
| URI 类型字段 | 单个字符 U | 1 |
| URI 载荷 | 前缀码 1 字节 +nfc.example.com/nfc/12345?ch=storeA共 35 字节 | 36 |
| AAR 记录头 | 3 字节固定 | 3 |
| AAR 类型字段 | android.com:pkg共 15 字节 | 15 |
| AAR 载荷 | 包名 18 字节 | 18 |
| 合计 | 76 |
再加 TLV 封装头（1 字节 Tag + 长度字段 1 到 2 字节）和终止符 1 字节，总共大概 80 字节出头。NTAG213 的 137 字节可用空间完全够用，甚至还有余量加个十几字节的签名参数。
如果 URL 里要带长参数（比如带 JWT 或者 base64 加密串），一条记录就能涨到一百多字节，这时候就必须上 NTAG215。我的建议是直接按 NTAG215 报价做预算，别为了省几毛钱反复拉锯，项目后期加需求再换芯片，返工成本远高于材料差价。
写入方式有两种。小批量（几十张）直接用手机上的第三方写卡工具，选 NDEF 写入模式，手动填 URI 和 AAR，一次一张，胜在零成本。大批量（几百张以上）需要 USB 读写器和 PC 端工具，把上面的 Python 脚本产生的字节流批量写入，效率差几十倍。注意写卡工具里的"锁卡"选项，一旦锁定标签就永久只读，写错了只能作废，除非项目明确需要防篡改，否则不要锁。
4.3 真机测试矩阵
不要只拿自己那台手机测一遍就上线，NFC 的兼容性问题非常分散。我一般按下面的矩阵过一遍，每个组合至少测三张卡。
| 测试维度 | 覆盖项 | 关注点 |
|---|---|---|
| 系统版本 | Android 9 / 11 / 13 / 14 | 权限模型和分发行为变化 |
| 品牌 | 华为、小米、OPPO、vivo、荣耀、三星 | 厂商商店 scheme 与分发优先级差异 |
| 装机状态 | 未装 / 已装未运行 / 已装后台运行 / 已装前台 | 冷启动、热启动、状态保持 |
| iOS 机型 | iPhone XR 及以后 / XR 以前 | 后台读取是否可用 |
| 贴卡姿态 | 手机上半部、中部、天线位置 | 有效感应区差异 |
| 环境 | 金属桌面、塑料外壳、厚手机壳 | 场强衰减 |
实测下来最常见的失败场景是"已装 App 但后台运行"时贴卡没反应。这种情况八成是onNewIntent没写，或者launchMode用的是standard导致每次新开一个实例。另一个高频问题是在小米和 OPPO 上弹出了选择器而不是直接进 App，这是 URI 匹配到了多个应用，需要靠 AAR 收口。
5. 踩坑记录与排查速查表
5.1 Android 侧的高频问题
贴卡后没有任何反应。先确认手机的 NFC 开关是否打开，这个听起来很傻，但我遇到过不止一次是用户自己在设置里关掉了。排除后检查 Manifest 里的android:host是否和标签里的域名完全一致，少一层子域都不行。再确认tech-list里写了android.nfc.tech.NfcA。
弹出了应用选择器。说明 URI 匹配到了多个应用且没有 AAR 收口。要么加 AAR 记录，要么把 URI 的域名收窄到一个只有你的 App 会声明的路径上。
能打开 App 但参数丢了。九成是 AAR 记录的位置放错了，它必须是最后一条。另外检查EXTRA_NDEF_MESSAGES的读取方式，有些低版本 ROM 返回的是Parcelable[]而不是NdefMessage[]，需要做类型判断。
未安装时跳的商店不对。AAR 的跳转目标由设备默认处理market://的应用决定。想指定商店，只能走落地页方案，自己按厂商分流。
重复贴卡启动多次。检查launchMode，并在onNewIntent里做时间戳去重，同一次会话内 2 秒以内的重复触发直接忽略。
5.2 iOS 侧的高频问题
AASA 文件更新后不生效。检查路径是否带扩展名、Content-Type 是否为application/json、是否存在重定向。三样都对还是不行，就等 CDN 刷新，或者临时换个路径验证。
Universal Link 在 Safari 里能打开但 App 接不到。大概率是 Associated Domains 没配对，注意这里填的格式是applinks:域名，不带协议头和路径。另外必须用真机测试，模拟器不支持。
老机型贴卡完全没反应。iPhone XR 之前的机型不支持后台读取，这个没法通过代码解决。物料上可以做机型适配提示，或者干脆把老机型引导到手动路径。
锁屏状态下读不到。iPhone 需要亮屏才响应标签，这是系统行为。线下物料加一句操作引导能显著提升成功率。
弹了通知但点进去没到指定页面。检查 App 的路由解析逻辑，webpageURL在不同系统版本上的 query 保留行为有差异，稳妥做法是把关键参数放在 path 里而不是 query 里。
5.3 上线前必须过的检查项
防复制这件事必须在业务层做。标签里的内容是明文的，任何人都能用手机读取并原样写到另一张空白卡上。所以不要把积分、金额、权限标识这类敏感信息直接写进标签，标签里只放一个随机 ID，真正的业务校验交给服务端去查。如果项目对防伪要求高，考虑用带动态加密能力的芯片，但成本和兼容性都要重新评估。
安卓厂商商店的跳转协议要真机验证。各家协议在不同版本上都有变化，下面这张表是我最近一次项目中实测的常见形式，仅供参考，务必用你的目标机型复测。
| 厂商 | 常见跳转协议形式 | 备注 |
|---|---|---|
| Google Play | market://details?id=包名 | 系统级通用协议 |
| 华为 | appmarket://details?id=包名 | 网页版为 appgallery.huawei.com |
| 小米 | mimarket://details?id=包名 | 部分版本需带 back=true |
| OPPO | oaps://mk/dt?pkg=包名 | 版本差异较大 |
| vivo | vivomarket://details?id=包名 | 部分机型回落到 market:// |
| 应用宝 | tmast://appdetails?pname=包名 | 需安装应用宝 |
落地页里的通用写法是：先尝试厂商 scheme，设一个 500 毫秒到 1 秒的定时器，如果页面还在前台（说明 scheme 没被接住），就回落到对应的 https 下载页。这个"尝试加超时回落"的模式比单纯跳一个链接稳得多。
不要把跳转逻辑做成死循环。我见过一个落地页，用户从微信打开后一直在"跳转中"和"打开 App"之间反复横跳，原因是 scheme 跳转被拦截后定时器又触发了一次。加个只跳一次的标志位，一秒钟的事。
埋点要从入口 Activity 就开始上报。用户贴卡到 App 完全启动之间有几百毫秒到两秒的窗口，如果等首页加载完才上报，会丢掉一部分中途退出的用户。把 tagId、路径参数、时间戳在入口 Activity 的第一时间就投递出去。
物料文案要写清楚操作姿势。我在门店项目里做过一轮 A/B 测试，桌贴上加不加"点亮屏幕后贴一下"这句提示，成功率差了将近三成。安卓用户的 NFC 开关状态也是个变量，物料上留一个"没反应？点这里手动打开"的二维码兜底，能挽回一批流失。
我个人在这个方向做了两年多，最大的体会是：技术实现其实不难，难的是一套物料同时喂饱 Android 和 iOS、同时照顾装了和没装、同时兼容各种品牌和系统版本。所以我的固定套路是标签只写最基础的两条记录（URI 加 AAR），所有分流和降级逻辑全部放在服务端的落地页里，通过配置中心下发。这样一旦某家厂商的跳转协议变了，改后端配置就能生效，不用重新做卡、不用重新发版，这才是线下硬件项目真正扛得住迭代的做法。
