公司蓝牙设备同事手机能搜到，我的新手机却搜不到，一般先看哪几项？

2026年10月11日阅读：56

结论先说：App 连公司自研蓝牙设备，同事手机能搜到、自己的新手机搜不到，多数不是设备坏了或手机牌子差，而是授权声明、扫描方式、广播与协议格式、厂商后台策略这四层里有一层没对齐。按 2026 年移动端交付经验，先分层定位再动代码，比反复换测试机有效；换机只能验证问题是否与机型相关，解决不了授权和协议层的问题。

先按四层排查，别急着换手机

蓝牙链路的失败点天然分层：系统没给授权，扫描代码根本不会执行；扫描过滤写错，设备名再对也进不了列表；连接成功但没订阅通知，界面显示已连接而数据一直不来。分层排查的意义在于，每一层都有可单独观察的现象，能避免改一行代码碰运气。

授权层：Android 12 起「附近设备」权限与旧版本的定位权限并存，iOS 需在工程配置里声明蓝牙用途；未授权时扫描接口通常返回空列表，也不抛异常。
扫描层：BLE 扫描常带服务 UUID 或设备名前缀过滤，条件写死会搜不到；经典蓝牙走设备发现流程，与 BLE 不是一回事。
连接与协议层：配对状态、GATT 服务与特征值、写入方式、通知订阅、包长协商，缺一项都可能连上却收不到数据。
系统与环境层：厂商省电与后台限制、系统蓝牙开关、外设是否已被另一台手机占用、外设固件是否处于可发现状态。

判断口径可简化成一句：两台不同品牌、不同系统大版本的设备都搜不到，才值得怀疑设备端；只有一台搜不到，先查那台手机的授权与开关。

搜得到不等于连得上，协议与选型也别跳过

不少项目把连接成功当终点，实际上配对、连接与收发数据是三件事。配对只建立信任关系；连接是建立链路；能不能收发，还要看服务与特征值是否对得上、通知是否订阅成功。安卓上尤其容易出现已连接但读不到值，原因多是特征值属性与实现方式没确认。

可执行的做法是把通信层拆成发现服务、匹配特征值、订阅通知、收发指令、断连重连五步，每一步都留日志。断连重连常被漏掉：用户走出蓝牙范围再回来，App 需要能自己恢复，否则会被认为时好时坏。

服务与特征值：必须与外设真实 UUID 一致，说明书与固件不一致时以外设为准。
写入方式：有应答写入与无应答写入对时序要求不同，指令连发容易丢包。
通知订阅：没订阅时数据不会主动上报，界面会一直停在已连接。
包长与重连：长指令要分片或协商，重连建议做退避重试并给用户明确提示。

选哪种蓝牙方式通常由外设决定，不是 App 单方面能选。按 2026 年常见的交付情况，BLE 更适合间歇性小数据，经典蓝牙更适合持续传输。可核对对比：

经典蓝牙（含串口类协议）：适合持续数据流，如打印、采集类外设；不同平台支持口径差异较大，部分品类对外设认证有要求，需按官方规范核对。
BLE：适合传感器、门锁、工牌等低功耗间歇通信，跨平台实现相对一致，但受系统后台策略影响明显。
对接工作量（经验区间）：协议文档齐全时，跑通核心链路常见在 3~10 个工作日；文档缺失需抓包倒推，周期常见翻倍。
测试成本：建议至少覆盖两个系统大版本、三种以上品牌机型与外设固件版本，这部分常被低估。

交付现场：只拿到一份说明书，协议表靠倒推

在项目里常见的情况是：甲方提供一份 Word 说明书，没有 GATT 服务表，预算按两周排，硬件还是上一代同事做的。比较稳的做法是先用厂商调试工具或抓包确认真实服务 UUID 与指令格式，再把倒推出的协议表回给甲方书面确认。代价是确认环节要多花两三天，换来的是不必按说明书写完后再整段返工；按经验区间，通信层返工的代价通常高于前期核对，因为要重写指令封装并重跑兼容测试。我们在类似外设对接项目里，通常会把协议表确认单独列成一个交付节点。

上线前的合格线与适用边界

验收标准建议写成可核对清单，而不是能连上就行。合格线大致是：目标机型上能稳定发现设备、断连后能自动恢复、异常时有可理解的提示，并且失败原因能被日志区分开。

能在两个系统大版本、三种以上品牌机型上稳定发现并连接目标外设。
断开重连、走出范围再返回、系统蓝牙关闭再打开，三种情况下都能恢复。
权限被拒时有明确引导，而不是静默失败。
关键步骤有日志，可区分授权问题、超时问题还是数据格式问题。
协议表、UUID 清单与指令说明随源码一并交付，避免换团队后重新猜。

适合做蓝牙直连的情况：外设是企业自有或可指定型号，业务强依赖实时采集与控制，且能要求固件与协议文档配套。不太适合或不必上蓝牙的情况：外设厂商已提供云端接口、数据允许延迟上报；用户设备型号极度分散且无法约束固件版本；功能只是替代一次手动输入。边界句：如果外设厂商已经提供云端接口，App 直连蓝牙一般是可选项而非必须项，优先走服务端常见能省掉相当一部分兼容与授权相关工作（经验区间）。