1. 从“一串MAC”说起BLE设备地址的真面目做BLE开发这些年被问得最多的问题除了“为什么连不上”就是“为什么同一个设备每次扫描到的蓝牙设备地址都不一样”。很多人想当然地把蓝牙设备地址当成网卡MAC地址来管理结果在设备去重、回连、白名单这些环节里踩了一堆坑。这篇文章我把BLE设备地址这件事从头到尾拆开讲一遍它到底有哪几种形态各自在什么场景出现手机系统又是怎么拿它来识别设备的以及实际开发里用地址做连接和设备管理时最容易掉进去的坑。1.1 地址在BLE协议栈里的作用BLE协议栈的链路层是地址真正的“使用者”。设备在广播态时会把自己的地址放进广播报文里扫描端收到广播包第一眼拿到的识别信息就是发送端地址。等双方进入连接流程时连接请求报文里同时携带扫描到的目标设备地址和发起方自己的地址链路层靠这一对地址把连接“锁定”下来。也就是说在BLE的世界里地址是通信双方最基础的寻址方式所有高层的数据交互都建立在链路层连接之上而这条连接从建立到释放始终离不开地址。很多人会直接把链路层设备地址叫成“蓝牙MAC地址”这个叫法不算全错但容易让人误解。BLE的设备地址虽然也是48位、6字节和传统以太网MAC长得一模一样但它的含义和分配方式比MAC复杂很多。传统MAC地址通常由IEEE的OUI字段和厂商自定义字段组成一个网卡烧录一个固定值基本不会变。而BLE设备地址里“随机地址”占了很大比例它们可能变、可能不变也可能每次广播都换一个完全取决于设备的设计。正因为这样开发时如果只按“一串固定编号”的思路去处理地址很容易在业务逻辑上出现偏差。1.2 四种地址类型怎么区分BLE核心规范把设备地址分成两大类公共地址Public Address和随机地址Random Address。随机地址又进一步划分为三种静态随机地址、不可解析私有地址、可解析私有地址。加起来就是我们常说的四种地址类型。下表可以快速建立一个整体印象地址类型是否固定典型使用场景说明Public Device Address通常固定出厂烧录、高可靠性设备类似传统MAC包含OUI适合长期标识设备Static Random Address上电周期内固定大多数量产BLE模组随机生成但多数模组重启后保持不变可能重新生成Non-resolvable Private Address周期性变化临时广播、防止被跟踪接收方无法通过地址反向识别设备Resolvable Private Address周期性变化开启隐私功能的手机/设备配合IRK密钥可被已绑定设备解析出真实身份公共地址的48位由两部分组成前24位是IEEE分配给公司的OUI后24位由厂商自己分配。这种地址一旦出厂就固定了理论上全球唯一。只要设备不换主芯片、不改固件地址就不会变。对于需要做设备资产管理、长期绑定、离线找回这类场景公共地址是最省心的选择。但代价是厂商要申请OUI而且地址是明文广播的任何人都能通过这个地址长期跟踪一台设备隐私性比较差。静态随机地址是BLE规范里非常有意思的设计。它由设备在首次上电时随机生成之后在每一次上电周期内保持不变。规范并不强制要求它重启后永久不变只强调“每次上电后需要保持且禁止修改”但很多厂商的模组为了简化逻辑会在出厂时把静态随机地址固定下来甚至允许用户通过AT指令重新配置。从类型标记上看静态随机地址的最高两位是“11”所以抓包时看到地址第一个字节在0xC0以上的设备基本可以判断是静态随机地址。市面上大量低功耗蓝牙温湿度计、体脂秤、智能手环用的都是这种地址。不可解析私有地址和可解析私有地址则完全是另一种思路它们存在的意义不是“标识设备”而是“隐藏设备”。不可解析私有地址会定时变化而且不携带任何可反查的信息接收方拿到这个地址无法判断它到底是谁唯一能确定的是“有这么一个设备在广播”。可解析私有地址也定时变化但它内部用密钥算法藏了真实身份信息已经和它配对过、拥有密钥的设备可以解出来。这里要特别提醒一句不要把“公共地址”和“静态随机地址”搞混。前者是IEEE分配的后者是随机生成后保持不变的。在BLE的许多高层应用里两者都可以用来当作设备的“长期身份”但从链路层角度看一个是public一个是random发起连接时地址类型字段不能填错。2. 为什么地址会“变来变去”可解析私有地址与绑定识别如果你用手机扫描一个开启了隐私功能的BLE设备比如iPhone或者某些新款的Android手机大概率会发现一个问题同一个设备第一次扫描看到的是AA:11:22:33:44:55过一会儿再扫变成了BB:22:33:44:55:66。如果你把这两个地址都存进后台设备表就会产生两条记录但实际它们指向的是同一个物理设备。要理解这个问题得明白可解析私有地址RPA的生成与解析机制。2.1 RPA的生成与解析机制可解析私有地址的核心是一把叫IRKIdentity Resolving Key身份解析密钥的128位密钥。设备在支持隐私功能时会维护一个自己的真实身份地址通常是公共地址或静态随机地址并生成一把IRK。广播或者扫描时它不会直接暴露这个身份地址而是用IRK对一个随机数做AES加密把加密结果的前24位作为哈希值和另外24位随机数组合成一个48位地址这个地址就是RPA。从协议栈视角看RPA的48位由两部分构成前24位是hash值后24位是随机数prand。prand的最高两位携带了地址类型标记指向“可解析私有地址”。对于不知道IRK的普通设备来说这个地址就是一个普普通通的随机地址但对于拥有这把IRK的已配对设备来说收到RPA后只需要做一次反向运算——取出后24位随机数用自己保存的IRK做同样的AES加密再比对前24位是否一致。一致就说明广播方是自己曾经配对过的那个设备。这套机制的巧妙之处在于地址本身看起来是随机的但隐藏了可验证的身份信息。不过要注意解析只有在双方完成配对、交换过IRK之后才可能发生。如果你的应用没有做配对绑定也没有保存IRK那你永远只能看到一个随时变化的随机地址无法在后台把它识别成“原来那台设备”。RPA的定时更新周期由设备自身决定规范没有硬性统一常见的设计是15分钟到24小时之间。对用户而言这就意味着手机后台扫到两个不同地址完全可能是同一个设备在两次不同时间里发出的广播。这也是很多开发者第一次做BLE设备管理时最容易困惑的地方。2.2 绑定后系统是怎么“认出”设备的配对绑定过程里除了交换加密密钥SMP安全管理协议还会交换身份信息内容包括身份地址和IRK。Central端把这些信息存进系统蓝牙协议栈的设备数据库里。之后不管对端设备用RPA广播多少次系统都能通过IRK把RPA解析回身份地址并判断出“这台设备是已绑定的XXX”。这解释了为什么很多现成的BLE SDK里已绑定设备的连接几乎感觉不到“地址变了”的问题。系统层已经替你把RPA翻译成真实身份了应用层拿到的、用于后续连接的目标地址实际上是系统维护的逻辑标识而不是扫描时看到的那串变化中的地址。但在实际工程里很多开发者没有做配对绑定只把扫描到的裸地址直接存进自己的数据库然后第二天再拿来回连。这种做法在小规模、固定地址的设备上能跑通一旦设备用的是RPA或者每次上电重新生成静态随机地址第二天回连就会发现“设备找不到了”。这背后的问题不是设备坏了而是你存的那个地址已经过期了。3. 开发中最容易踩的地址坑扫描、存储、回连地址相关的坑绝大多数不是协议层面的而是出现在应用层对地址的“错误假设”上。我见过最典型的情况有三种把iOS返回的UUID当成蓝牙MAC、把后台存的扫描地址当作永久设备ID、以及忽略了扫描地址类型直接发起连接。下面逐个拆开说。3.1 Android、iOS、uni-app拿到的地址差异不同的操作系统、不同的应用框架对“设备地址”的暴露程度完全不一样。Android端在调用BLE扫描接口后BluetoothDevice.getAddress()通常能拿到一个形如XX:XX:XX:XX:XX:XX的地址。但它可能是一个公共地址、静态随机地址、甚至RPA取决于设备端在广播时使用的地址类型。从Android 6开始扫描蓝牙设备通常还需要定位权限从Android 12开始又引入了附近的蓝牙设备权限但即便如此应用层能拿到的地址格式本身没有变。iOS端则是另一套逻辑。CoreBluetooth没有向开发者暴露任何蓝牙MAC地址CBPeripheral.identifier是一个由系统生成的UUID字符串。这个UUID和底层的BLE设备地址没有任何换算关系它只是iOS系统内部用来标识“某个外设实例”的映射值。应用的本地数据库存了这个UUID下次还能用它找到同一个外设但应用卸载重装、系统还原、或者换一台iPhone这个UUID就可能不再是同一个值。uni-app这类跨平台框架里接口统一成了deviceId但背后的含义却随平台而变化。Android上deviceId通常是蓝牙MAC地址iOS上deviceId则是系统UUID。这就带来一个很现实的问题如果你在Android后台存了一个设备地址再把同一套数据拿到iOS上用是没法直接发起连接的因为格式和含义都对不上。反过来说iOS上保存的deviceId也不能拿到Android设备上当作设备标识用。3.2 不要拿地址当“设备唯一ID”直接把BLE地址当“设备唯一ID”是新手最高频的坑尤其是对接非自研硬件时最容易中招。举个例子某款温湿度计模组为了方便出货没有申请公共地址用的是每次开机随机生成的静态随机地址。你在测试环境里连着用了三天地址没变觉得没问题第四天设备断电重启地址突然变了后台系统里出现两台“温湿度计”其中一台原来的设备彻底连不上了。用户找过来你还以为设备坏了。正确做法是如果设备支持在广播数据里携带厂商自定义数据Manufacturer Specific Data就尽量在里面放产品序列号、固件版本、设备型号这类业务标识。扫描到设备后先用业务标识去关联后台数据再用当前扫描到的地址做即时连接。地址在这里只承担“发快递时填的门牌号”角色而不是“身份证号”。只有设备内部保存的业务ID才适合作为长期唯一标识。另外还要考虑一种边界同一个厂商的多台同型号产品广播内容完全一样只有地址不同。如果地址又老变你就很难区分它们。这种场景下要么在固件里加一个可读的序列号特征值等连接后主动读取要么在广播数据里把产品实例ID放开。单独依赖地址做区分风险非常高。3.3 iOS的deviceId能不能直接建连答案与替代方案很多人会问uni-app在iOS上可以根据蓝牙的deviceId建立连接吗答案是可以但这里的deviceId不是蓝牙MAC地址它是系统生成的一个UUID。uni.createBLEConnection({ deviceId })接口接收的deviceId必须来自uni.onBluetoothDeviceFound或uni.getBluetoothDevices返回的那个值。把它当作一把“临时钥匙”来发起连接没问题但它不能用来做跨设备、跨系统的设备身份识别。如果你希望在iOS端实现“这台硬件设备已经绑定过我的账号”这样的语义最稳妥的方案是在广播数据里增加固定的业务标识符。应用扫描到设备后读取广播数据中的厂商自定义字段反查后台用户绑定关系。确认已绑定就用系统返回的deviceId发起连接。整个过程不要碰“从广播地址反推真实MAC”这类操作因为iOS从系统层面就不支持。如果设备已经支持配对绑定也可以利用CoreBluetooth自动保存绑定信息的能力让系统帮你维护“这台设备是可信的”。但要注意即使配对了应用层拿到的依然可能是UUID而不是硬件地址。所以设计后台数据模型时请从一开始就把“设备业务ID”和“当前会话连接标识”分开两个字段存别把iOS的UUID塞进“MAC地址”栏里。4. 排查实战地址相关的故障定位链路地址问题通常不会写在报错信息里而是表现为“扫描不到”“连不上”“连上了但认错设备”。下面分享几个我实际排查过的故障场景以及每一步的定位思路。4.1 扫描到了却连不上先看地址类型是否匹配一次典型的故障Android手机能扫描到某个BLE设备但调用connectGatt一直失败报错码是133或者干脆超时。排查了一天最后发现App里把设备地址写死成了公共地址而设备端广播的是静态随机地址。链路层发起连接时连接请求里的目标地址类型字段要能匹配上设备当前广播地址的类型。设备广播用的地址类型是random连接请求里给的地址类型是public设备端会直接忽略这个连接请求。解决办法很简单不要手动拼地址和地址类型发起连接。扫描到BluetoothDevice对象后直接拿这个对象去连接系统会自动把地址类型带进去。如果用的是原生Android别在代码里做“按字符串对比设备地址”这种自作主张的事尽量保存BluetoothDevice引用或者至少保存address type两个字段。在nRF Connect这类调试App里扫描列表会明确显示地址类型分别是Public、Random Static、Random Private等连接时它会原样传给协议栈。如果你要自研扫描器也一定要把地址类型一起暴露到上层别只返回一个格式化字符串。4.2 设备重启后地址变了怎么办还有一类故障表现在固件设备上上一秒还连得好好的设备断电重启后手机就回连不上了。用nRF Connect重新扫描发现设备还在广播但地址和之前不一样了。这类设备用的多半是“每次上电重新生成”的静态随机地址或者干脆是RPA。如果你以为静态随机地址一定不变就会在这里翻车。定位思路是分两步走先用抓包工具确认设备每次重启后的地址变化情况再检查广播数据中是否存在可识别的业务字段。如果广播数据里有厂商ID序列号App完全可以在扫描到新地址后用业务字段识别设备并更新本地保存的最新地址。如果广播数据里什么都没有只能靠配对绑定解决否则无解。从固件设计角度如果产品没有做配对功能尽量把静态随机地址固定下来并支持用户配置这样才能避免“每次开机都变一个新设备”的体验问题。4.3 怎么用抓包确认地址是public还是random排查地址问题手上最好有一个BLE抓包工具。我常用的是nRF52840 USB dongle配合nRF Sniffer插件在Wireshark里抓包。抓广播包时可以看广播报文中的Advertiser Address字段同时打开Address Type列确认它是public还是random。如果是random类型结合最高两位判断是Static、Non-resolvable还是Resolvable。抓连接请求时可以看CONNECT_IND里的AdvA和InitA两个字段同样都带地址类型标记。这种抓包方式特别适合定位“为什么这个地址看起来是随机的”这类问题。例如设备开启隐私功能后抓包会看到广播地址每隔一段时间变化一次但配对过程中SMP报文里会明确传输一次Identity Address那才是设备的真实身份地址。如果你在破解设备身份核心是去抓配对过程、保存IRK但如果你只是做产品调试看到RPA也完全不用慌系统层会自动解析你只需要理解它背后发生了什么。4.4 白名单过滤的正确打开方式BLE链路层有个白名单功能可以限制哪些设备能够扫描或连接自己。很多开发者第一次用的时候直接填一个地址字符串结果发现不管用。原因很简单白名单条目并不是“一个地址”而是“地址地址类型”的组合。设备用的是Random Static地址你在白名单里做成Public控制器一对比发现不匹配直接过滤掉。更复杂的情况是RPA。白名单里如果只放身份地址而没有配置Resolving List当对端用RPA广播时控制器不知道这个RPA对应的是白名单里的谁同样会过滤。正确的做法是对支持配对的设备把IRK放进链路层的Resolving List让控制器自行解析RPA对不支持配对、只用固定地址的设备白名单里必须同时保证地址值和类型都正确。在Android/iOS应用层如果无法直接操作Controller白名单就自己在扫描回调里写过滤逻辑拿广播数据里的业务字段判断而不是比对裸地址。应用层过滤虽然耗电高一点但可控性最好也最容易调试。5. 工程落地建议设备管理不能只靠一张地址表地址问题本质上是“设备身份识别”问题。看完前面的坑其实解决方案已经比较清晰了不要把地址当成唯一真相要在更高层建立一套可长期使用的设备业务ID再用地址完成即时通信。5.1 优先“绑定地址”双保险如果设备是你的自有硬件强烈建议把配对绑定功能做进去。绑定不仅让链路得到加密保护更重要的是交换IRK后系统可以帮助你在地址变化的情况下仍然识别设备。绑定之后即使设备重启后换了RPACentral端也能够通过IRK解析地址自动关联到原来的设备记录。这个体验对用户来说非常自然几乎无感。对于不打算做配对的低成本产品至少要在广播数据里加一个固定业务ID。比如“厂商ID产品序列号”组成的Manufacturer Specific Data字段。扫描阶段就能读取这个字段用来做设备列表去重和后台绑定校验。这样即使在Android、iOS跨平台场景下只要业务ID不变应用都能稳定识别设备。地址就只是“当前广播使用的临时门牌号”。5.2 地址变化场景下的Mesh与Remote Provisioning注意点如果做的是蓝牙Mesh相关项目地址问题会多一层复杂性。Mesh网络内部的节点地址是16位的单播地址由配网器分配和BLE链路层设备地址不是一回事。但配网阶段、尤其是远程配网Remote Provisioning场景依然依赖底层BLE广播发现未配网设备。此时未配网设备如果使用随机地址或RPA扫描端不能只靠链路层地址做设备去重必须结合广播数据里的Device UUID或者Mesh Beacon信息来判断是谁。我在实际调试中遇到过一种情况两个同型号的Mesh灯使用相同的广播数据模板链路层地址又都是动态变化的导致扫描列表里看起来“设备在疯狂跳动”。最后是把广播数据里的临时设备标识和产品UUID一并显示在调试界面上才真正把两台设备区分开。所以Mesh项目里建议从一开始就把地址、Device UUID、产品序列号分开建模千万不要只用地址做主键。5.3 如果只做“一主一从”的透传还需要关注地址吗很多开发者觉得我就做一块蓝牙串口透传模块手机连上就收发数据地址这块不用深究。体感上确实如此但有一个场景一定会遇到模块断电重启后手机App里的“已连接设备列表”里那台设备重新去回连结果连不上。原因无外乎模块重启后重新生成了静态随机地址或者广播地址类型变化了。这时候如果App里没有“重新扫描并让用户重新选择设备”的逻辑用户就会以为产品坏了。所以哪怕是最简单的透传应用也建议在App端明确两件事第一是否保存设备地址用于自动回连如果保存必须把地址类型也保存下来第二设备重启后如果地址变了扫描列表里能不能通过设备名称、广播数据识别出来如果只靠地址比对那就很容易误判。我在量产项目里见过不少这种问题最后大多是通过固定模块地址或者广播里加标识解决的。地址这事看着不起眼真踩上了坑往往要折腾好几天。至少在做技术方案时提前问自己一句这个设备的地址明天还是这个吗