企业官网建设流程全解析

做BLE调试的人，十有八九都在“蓝牙地址”这四个字上栽过跟头。同样是扫出来的一串MAC，有时能用、有时连不上；同一个设备，Android手机和iOS手机上显示的地址完全不一样；到了RPA自动录入场景，Excel里留着的那串地址又可能因为大小写、横线、冒号格式不同，让整套流程直接崩掉。这篇内容我想把BLE的蓝牙地址机制、连接过程，以及RPA在处理这类设备数据时的实战写法放在一起讲清楚，适合正在做蓝牙产品调试、测试自动化，或者想把设备信息从Excel搬到后台系统的RPA工程师参考。读完你至少能搞明白四件事：BLE地址有哪些类型、连接过程里地址怎么变化、ESP32和Mesh场景下的地址问题，以及用影刀这种RPA工具做设备数据录入时怎么避免踩坑。

1. 先看全局：BLE地址、连接过程与RPA的关联在哪

很多教程喜欢一上来就列协议栈，结果读者看完只知道“BLE很省电”，到了实际项目里照样看不懂日志。我个人的经验是先想清楚一个问题：你手里拿到的“蓝牙地址”到底是从哪个环节拿到的，它是不是当前连接过程真正会用到的那一列数据。

1.1 蓝牙地址到底是什么，为什么RPA要关心它

BLE全称Bluetooth Low Energy，蓝牙低功耗，工作在2.4GHz频段。它把80MHz带宽切成了40个信道，其中3个是广播信道，37个是数据信道。设备一开机就在广播信道上发广播包，手机或网关扫描到之后，如果满足条件，就发起连接，双方再跳到数据信道上通信。这个“跳到哪个信道、用哪个地址回应”，都由链路层按固定规则决定，而链路层数据包最前面那一长串身份标识，就是蓝牙地址。

做RPA的人通常不会写蓝牙协议栈，但只要你做过硬件测试自动化，多半会遇到这样的场景：测试结果Excel里有一列“MAC地址”，后台管理系统里也有一个“蓝牙地址”输入框，RPA要做的就是把这一列数据一个一个填到网页上。如果不懂BLE地址的分类和格式，你很可能会把“扫描到的随机地址”当成固定MAC存进数据库，结果第二天设备重启之后地址变了，系统里同一台设备就出现了两条重复记录，后面的盘点、远程升级、售后查询全部对不上。

1.2 地址在BLE协议栈里的位置

BLE协议从下往上大概可以分成物理层、链路层、HCI、L2CAP、ATT/GATT和GAP。蓝牙地址主要出现在链路层，它解决的是“这一个包是发给谁的、来自谁”的问题。到了应用层，iPhone、Android App经常拿到的是GATT服务、特征值、设备名称和系统分配的UUID，不一定直接暴露链路层MAC。

所以你会发现一个奇怪现象：用nRF Connect这类工具能看到设备的MAC地址，但用uniapp写App时拿到的deviceId经常是一串UUID；Windows设备管理器里的“蓝牙地址”有时和手机扫描到的还不一样。这不是设备坏了，而是不同系统出于隐私保护，把底层地址包装成了另一层标识，或者用了可轮换的随机地址。搞明白这个区别，才能在RPA自动录入时选择正确的字段。

2. 蓝牙地址的四种类型与识别方法

BLE规范的蓝牙地址一共分成四种，不夸张地说，一半的“连不上”问题都是因为把四种地址混为一谈。

2.1 四种地址类型速查

重点说一下第二类和第四类。ESP32这类开发板默认生成的地址，看起来像固定MAC，但你千万别当成产品唯一标识。它每次烧录固件后可能都一样，但换一个板子可能生成出完全不同的值。如果想做成产品，最好在出厂时把地址写入NVS或efuse，并在RPA流程里同时记录设备SN，用“SN+BLE地址”双字段去后台比对，不然返修回来刷一次固件，地址就变了。

2.2 “魔方蓝牙MAC地址怎么设置”到底怎么答

有相当多人搜“魔方蓝牙MAC地址怎么设置”，其实问的是开发板或者量产模块能不能自定义MAC。这个问题要分两层看：

• 如果产品用的是ESP32、nRF52这类可编程芯片，厂家可以在项目里调用底层驱动接口设置MAC。例如在ESP32上，可以在初始化蓝牙前调用esp_base_mac_addr_set()传入自定义地址，然后重启蓝牙控制器。要注意这个接口必须在射频初始化之前调用，而且设置完后要确认返回值，否则可能会设置失败但不报错。
• 如果产品是量产智能硬件，尤其像智能魔方、智能锁这种消费级设备，MAC地址一般出厂就烧写好了，用户和普通开发人员改不了。通过App看到的那串地址也不一定等于芯片底层MAC，可能只是厂商定义的“设备标识”。

所以网上教程再怎么讲“设置MAC”，都绕不开一个问题：你的芯片和固件到底允不允许改。以ESP32为例，设置地址的代码很简单，但验证环节经常被人忽略：

#include "esp_bt.h" esp_bd_addr_t new_addr = {0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF}; esp_err_t err = esp_base_mac_addr_set(new_addr); if (err == ESP_OK) { // 重启后生效 esp_restart(); } else { // 通常是ESP_ERR_INVALID_ARG或ESP_ERR_INVALID_VERSION ESP_LOGE("demo", "set mac failed: %s", esp_err_to_name(err)); }

从RPA或自动化测试的角度看，我更建议你在Excel里多留一列“是否自定义地址”。如果设备允许自定义，测试脚本还能通过发送AT指令或调用调试接口，把地址改成不易冲突的固定值，方便仓库管理。否则就老老实实以扫码或App读取的结果为准。

2.3 iPhone 13、iOS与uni-app里的deviceId问题

每次有人问“iPhone 13为什么扫描不到BLE设备的MAC地址”，我都要重复一遍：iOS从CoreBluetooth层面开始就不开放底层MAC，任何第三方App都拿不到。系统返回的peripheral.identifier是一个UUID，它由系统生成、通常不会变，但和蓝牙链路层地址是两回事。

在uni-app里也是一样。uni.getBluetoothDevices返回的deviceId在iOS上是UUID，在Android上很多是MAC地址，但官方文档明确要求开发者把它当成“当前平台的设备标识”，不要试图解析成MAC。如果有人在问“uni-app ble iOS 可以根据蓝牙的deviceid建立连接吗”，答案是可以用，而且就应该这样用。连接时直接把这个deviceId传给uni.connectBLEDevice，不需要自己拼MAC。

uni.openBluetoothAdapter({ success() { uni.startBluetoothDevicesDiscovery({ success() { uni.onBluetoothDeviceFound((devices) => { const device = devices[0]; console.log(device.deviceId, device.name); // iOS：deviceId是UUID，直接连 // Android：常见为MAC，也不要手动改格式 uni.connectBLEDevice({ deviceId: device.deviceId, success() { console.log('连接成功'); }, fail(err) { console.error('连接失败', err); } }); }); } }); } });

这个结论对RPA测试特别重要：真机自动化里千万不要用字符串拼接的方式去构造iOS的deviceId，也不要让RPA脚本把Excel里的MAC地址强行填到iOS自动连接步骤里。跨平台方案只能是“把设备名称、广播服务UUID、deviceId三者一起做匹配”。

3. BLE连接过程拆解：广播、扫描、连接和地址变化

RPA工程师写测试用例时，经常要把“扫描设备、发起连接、检查连接结果”整个流程自动化。如果你不了解BLE连接过程，脚本写出来往往是“扫描三秒就连”，结果偶尔成功偶尔失败，还查不出原因。

3.1 一次标准BLE连接过程

一次完整连接大概分五步：

1. 广播设备按广播间隔（如100ms）在37、38、39三个信道上轮流发广播包，包里带有设备地址、设备名称（可选）、服务UUID（可选）。
2. 扫描设备扫描到广播包后，可以选择发送扫描请求，广播设备再回复扫描响应，携带额外信息。
3. 连接发起方根据广播包里的地址和通道信息，发送连接请求，双方进入连接状态。
4. 连接建立后，双方按协商的connection interval在数据信道上通信，此时地址可能变成连接中使用的身份地址。
5. 如果需要安全通信，再做配对和绑定，交换密钥。绑定后，有些设备会改用可解析私有地址。

你会发现地址在不同阶段可能不固定。广播阶段用的是“广播地址”，连接阶段可能用“身份地址”，绑定后还可能轮换成可解析私有地址。所以RPA脚本在做地址比对时，不能假设Excel里的地址等于实时广播地址；更可靠的办法是连上之后再读设备信息服务里的“设备名”或“模块序列号”，用第二层字段做最终确认。

3.2 ESP32轻度睡眠下怎么保住BLE连接

低功耗蓝牙产品经常会遇到一个问题：设备进入轻睡眠后，蓝牙连接掉了。ESP32上打开轻度睡眠，如果蓝牙射频进入睡眠模式，连接间隔又太长，对端设备就会认为连接超时。常见做法是在初始化时调用蓝牙睡眠使能，并配合合适的唤醒源：

esp_bt_controller_init(); esp_bt_controller_enable(ESP_BT_MODE_BTDM); esp_bt_sleep_enable(); // 配置唤醒源，例如定时器或GPIO esp_sleep_enable_timer_wakeup(10 * 1000); // 10ms

但这里有个坑：不同版本的ESP-IDF，API名称可能不同，有的需要配置esp_pm电源管理，不能照抄老代码。而且如果BLE和Wi-Fi同时工作，睡眠策略会更复杂。经验是：如果设备在睡眠期间还要能被远程唤醒，最好把连接间隔短一些，比如30ms到50ms；如果只是定时上报数据，干脆设计成“睡一段时间→唤醒→快速连上→发完再睡”，比硬抗睡眠断连要稳定得多。

从RPA测试的角度，自动化用例不要只测“连接成功”，也要测“设备睡眠过程中连接是否断、断后能否自动重连”。把这类用例交给影刀或自定义脚本定时跑，能省下大量手工测试时间。

3.3 BLE Mesh Remote Provisioning 与地址编排

BLE Mesh适合大规模设备组网，它和普通BLE最大的区别之一，就是引入了“节点地址”的概念。Mesh网络里的设备不再依赖传统的蓝牙MAC作为唯一标识，而是由Provisioner给每个节点分配一个16位单播地址。另一个重点就是Remote Provisioning，即“远程配网”：当一个未配网设备离Provisioner太远，或者藏在金属箱里无法直接通信时，已经入网的节点可以作为中继，转发配网包，完成远程入网。

这个场景对RPA非常有价值：大规模Mesh设备入网时，运维人员不可能拿着一台手机挨个到设备旁边点配网，常见方案是写一个后台脚本，配合RPA操作配网工具，批量读取未配网设备列表，分配节点地址，再记录到Excel。Excel里至少要有三列：设备MAC/DeviceUUID、Mesh单播地址、入网时间。后续RPA巡检时，就按单播地址去查在线状态，而不是傻傻地去匹配合成MAC。

4. RPA实战：从Excel里的蓝牙地址到自动化操作

RPA工具很多，常见的有影刀RPA、金智维、Ui.Vision，它们解决的核心问题都是“让软件机器人代替人反复操作网页、Excel和桌面软件”。放到BLE硬件场景里，RPA最常做的就是三件事：读取测试数据、录入后台、生成报告。

4.1 什么样的RPA流程会用到蓝牙地址

最典型的是设备信息录入。产线测试完一批蓝牙模块，会导出一张Excel表，里面有设备SN、蓝牙名称、MAC地址、信号强度、固件版本。后台上货系统需要一个一个录入，如果纯手工点，键盘都能点出火星子。用RPA可以这样设计：

1. 打开Excel，读取指定Sheet里的数据行。
2. 把蓝牙地址统一格式化为大写、去掉分隔符，方便后台识别。
3. 打开后台设备管理页面，循环填入设备名、蓝牙地址、备注。
4. 每次保存后截图，并把“已录入”状态回写到Excel，避免重复提交。
5. 遇到失败时记录错误原因，最后汇总一份失败清单。

影刀RPA里组件非常多，这个流程基本不需要写复杂代码，只需要“打开Excel”“读取区域”“循环”“填表”“点击”“截图”这些基础组件就够了。如果你更习惯代码化实现，也可以导入pandas去清洗Excel地址列，但要注意影刀在读取大量数据时要提前把Excel文件关闭，否则会提示文件占用。

4.2 用影刀RPA写一个“Excel读取→网页录入”的最小流程

下面是我在实际项目中落地过的一套简化流程，组件顺序可以供参考：

1. 打开Excel文件：D:\test_result.xlsx 2. 从“Sheet1”读取A2:C100，存为“表格数据” 3. 对于每一行数据： a. 格式化地址 = 去空格，去掉冒号/横线，转大写 b. 打开网页：https://console.example.com/devices/add c. 等待“设备名称”输入框出现 d. 填入设备名称、蓝牙地址、备注 e. 点击“保存” f. 等待保存成功提示 g. 在表格数据里标记“成功” 4. 最后把结果写回新的Excel文件

很多人第一次写RPA会把网页自动化想得太复杂，其实核心只有三步：打开、填、点。难点在元素识别和等待。影刀的“网页元素”可以自动抓取，但要是抓错了，常见原因是元素没有唯一id，或者页面有iframe。这时就要改用CSS选择器或XPath。另外一定要加“等待元素出现”，不要用固定sleep，网络抖动一下，脚本就崩了。

关于“影刀RPA拼多多自动上架教学”里的套路，其实和上面的流程一样。如果把“设备信息”换成“商品标题、价格、库存”，把“蓝牙地址”换成“商品编码”，你已经会拼多多自动上架了。真正决定项目成败的往往不是RPA工具本身，而是Excel数据清洗和网页元素定位的稳定性。

4.3 RPA+手机真机的BLE连接测试怎么搭

如果你想更进一步，把“手机扫蓝牙并连接”也自动化，可以分成两种做法。

一种是手机端做UI自动化，用Appium或AirTest控制测试App，输入设备地址、点击扫描、点击连接、读取结果。这种方案适合在真实系统环境里验证App交互，但维护成本高。

另一种是PC端RPA加ADB命令协同。先把手机用USB连到电脑，RPA通过ADB启动测试App，再用adb input输入MAC地址，最后抓取App日志确认连接状态。举例：

adb shell am start -n com.example.bletest/.MainActivity adb shell input text "01:23:45:67:89:AB" adb shell screencap -p /sdcard/screen.png adb pull /sdcard/screen.png ./logs/screen.png

这种方式不是传统意义上的RPA，但很多RPA工程师都在用。它的好处是可以把“硬件设备准备”“App操作”“Web后台录入”放在同一条流水线上，做到真正意义上的产测自动化。注意每次连接前要清理手机蓝牙缓存，否则手机可能错误地连接旧设备。

5. 调试与落地中的常见问题速查

实际项目中，无论是BLE代码调试还是RPA流程落地，问题都集中在下面几张表里。我按“症状—原因—解法”整理了一下，方便你直接排查。

另外还有一个很容易踩的坑：RPA循环录入大量设备时，网页后台如果响应太慢，脚本会连续点击导致重复提交。我习惯在保存成功提示出现后才标记“成功”，并且给每次点击加一个1到2秒的“防抖”延时。宁慢勿错，否则数据库里一堆重复设备，后面清理更麻烦。

6. 关于BLE设备自动化的几点个人体会

最后再说几个我踩过坑之后才形成的习惯，不算标准答案，但对大多数人应该有用。

第一，Excel里的“MAC地址”列一定要在进入RPA流程前清洗完，不要指望RPA脚本里做复杂判断。用Excel公式或Python把这列转成统一格式，RPA只负责搬运，复杂逻辑越少越稳定。

第二，iOS设备身份字段不要死记硬背。不管是uniapp还是原生开发，deviceId就按iOS给的UUID用，Android按平台给的地址用，两边都别强行“归一化”。系统层的隐私保护你是绕不过去的，绕过之后App上架审核也有风险。

第三，做BLE连接测试自动化，别只盯着连接成功概率。把“连接失败时RPA怎么处理”设计好，比成功路径更重要。我通常会在流程里加一个“失败重试两次，第三次记录日志并截图”，这样第二天看结果时，根本不用翻一堆截图，只要看错误码汇总就行。

第四，如果你们业务里既有硬件测试又有电商上架，完全可以共用一套RPA模板。你给拼多多后台填商品参数，和给设备管理系统填蓝牙MAC地址，本质上都是“读Excel—填网页—保存”。先把一个流程跑通，再复制给另一个场景，RPA工程师的成长速度会快很多。

按照这套思路，我已经把“Excel设备名单—移动端BLE连接测试—Web后台录入”整条链路在影刀RPA里跑通，单台设备录入时间从人工的一分半钟降到了十几秒，而且全程有截图和日志。做这类项目，真正值钱的不是那几行RPA配置，而是你对BLE地址机制的理解，以及出了问题之后能快速定位是系统隐私限制、设备地址轮换还是网页元素变化的判断力。