企业官网建设流程全解析

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）。随机地址又进一步划分为三种：静态随机地址、不可解析私有地址、可解析私有地址。加起来就是我们常说的四种地址类型。下表可以快速建立一个整体印象：

公共地址的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的生成与解析机制

可解析私有地址的核心是一把叫IRK（Identity 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后，系统可以帮助你在地址变化的情况下仍然识别设备。绑定之后，即使设备重启后换了RPA，Central端也能够通过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端明确两件事：第一，是否保存设备地址用于自动回连？如果保存，必须把地址类型也保存下来；第二，设备重启后如果地址变了，扫描列表里能不能通过设备名称、广播数据识别出来？如果只靠地址比对，那就很容易误判。我在量产项目里见过不少这种问题，最后大多是通过固定模块地址或者广播里加标识解决的。地址这事，看着不起眼，真踩上了坑，往往要折腾好几天。至少在做技术方案时，提前问自己一句：这个设备的地址，明天还是这个吗？