一个让人抓狂的连不上现场去年帮一个做资产追踪的团队排查问题。他们的设备装在物流托盘上平时休眠定时醒来广播一包数据网关收到后回连读一次历史记录。实验室里一切正常拉到现场跑了三天发现大概三成的托盘数据永远收不上来。现场表现很怪网关日志里能看到这些设备的广播包信号强度也不差说明设备在正常发。但发起连接后要么超时断开要么连上了立刻掉反复重试几次后设备就回到休眠等下一个周期再重复同样的剧本。他们一开始怀疑是天线、干扰、电源换了一轮硬件没变化。后来把抓包工具挂上去对比了能连上的设备和连不上的设备的广播内容问题才浮出水面两类设备的广播包里有几个跟连接相关的字段不一样而发起方用的是同一套固定参数去连所有人。这就是典型的发起连接参数与广播参数不匹配。它不报错不崩溃只是默默让你一部分设备永远连不上而且比例还可能随环境变化非常折磨人。先搞清楚这两组参数各自是什么广播参数是设备在广播包里自报家门时携带的信息。除了设备名、服务UUID这些业务字段还有几个跟能不能被连、怎么连直接相关的是否允许被连接可连接广播 vs 不可连接广播广播间隔从设备延迟slave latency的期望值连接超时的期望值有些协议栈还会把期望的连接间隔范围放进广播数据或扫描响应里发起连接参数是主动方手机、网关、主设备在发起连接那一刻自己决定的扫描窗口/扫描间隔决定它多久能听到一次广播发起连接时的连接间隔连接超时从设备延迟关键点在于发起方单方面决定了连接建立后的初始参数但它未必尊重广播方声明的期望值。两边如果差得太离谱连接要么建不起来要么建起来很快断。坑一扫描窗口太窄漏掉了慢广播最隐蔽的一种不匹配是发起方的扫描节奏和广播方的广播间隔对不上。广播是周期性的设备每隔一个广播间隔发一次。发起方如果只在很短的窗口里开机扫描就可能连续几次都刚好错过。实验室里设备少、干扰小偶尔错过还能补上现场设备一多、广播信道一挤错过概率急剧上升。现象特征不是完全连不上而是时好时坏重试几次能成功但成功率低得没法接受。很多人会误判成信号问题其实是时间上的错位。排查思路很直接把发起方的扫描窗口/间隔和广播方的广播间隔都打出来算一下在一个扫描周期内理论上能覆盖到几次广播事件。如果覆盖次数小于2就是设计上的隐患。工程上一般要求扫描窗口至少能覆盖到广播间隔的两到三倍留出余量。扫描周期 扫描间隔 单周期内可听到广播的次数 ≈ 扫描窗口 / 广播间隔 这个值建议 2现场环境差时建议 3坑二连接间隔谈不拢连上就掉连接建立后双方要协商一个连接间隔。发起方给的是一个初始值广播方从设备可以在广播里声明自己期望的范围。如果发起方给的值远小于从设备能承受的最小值或者远大于它声明的最大值就会出现从设备直接拒绝这次连接请求连接建立但从设备因为来不及响应而频繁丢包连接超时计数器很快溢出触发断开现场表现就是前面那个故事里的连上了立刻掉。抓包能看到连接建立的过程然后很快出现断开事件断开原因码往往指向连接超时或参数不可接受。这里有个公开资料很少讲的细节很多从设备的协议栈在收到不合理的连接参数时不会礼貌地拒绝而是先接受再立刻断开。所以你看到的是连上又掉而不是连不上。这个行为差异会误导排查方向——你会以为是链路不稳定其实是参数从一开始就不被接受。判断方法把发起方的连接间隔、从设备广播里声明的期望范围、以及从设备实际能支持的范围三个值列出来对比。只要发起方的值落在从设备支持范围之外基本可以锁定。坑三从设备延迟和超时配合不当从设备延迟slave latency允许从设备跳过若干个连接事件不应答用来省电。它必须和连接超时配合连接超时 (1 从设备延迟) × 连接间隔 × 系数。如果发起方给的连接超时太短而从设备又声明了一个较大的延迟从设备按自己的节奏跳过事件发起方那边超时计数器先溢出连接就断了。这个坑的阴险之处在于它只在从设备真的进入省电节奏后才暴露。刚连上时从设备可能还积极应答跑一会儿开始偷懒连接就断。所以现象是连上后能撑几秒到几十秒然后断而不是立刻断。现场排查时重点看断开的时间点是否规律。如果总是维持差不多长的时间后断开且这个时间和连接超时字段对得上基本就是这个问题。坑四可连接标志被忽略还有一种低级但常见的广播包里声明的是不可连接广播比如只广播数据的信标发起方却硬要去连。这种情况下发起方根本收不到连接响应扫描器会一直重试直到超时。现象是能看到设备就是连不上连超时后放弃。用抓包工具看广播包的类型字段就能确认。这个不算参数数值不匹配而是能力不匹配但现场表现和参数不匹配一模一样所以放在一起讲。现场怎么快速定位给你一套我常用的判断顺序按这个走基本不会绕弯第一步抓广播包列出每个设备的广播类型可连接/不可连接、广播间隔、声明的连接参数期望范围。第二步抓发起方的配置扫描窗口/间隔、发起连接时的连接间隔、连接超时、从设备延迟。第三步做三组对比扫描覆盖次数是否够窗口/间隔 vs 广播间隔发起连接间隔是否落在从设备声明范围内超时是否满足延迟约束第四步如果数值上都对得上还连不上再怀疑广播类型和能力不匹配。这里有个经验不要只测一台设备。参数不匹配的坑往往是大部分设备能连少数连不上因为不同批次的从设备固件可能声明了不同的期望范围。只测一台很容易漏掉。权衡发起方该不该迁就广播方理论上发起方应该尊重广播方声明的期望参数。但工程上没那么简单。发起方如果是手机操作系统往往不让你随便设连接参数它有自己的策略你只能接受。这时候反过来的做法是让从设备在广播里声明一个足够宽的范围宽到能包容发起方可能给出的各种值。这是很多量产设备的实际做法——不追求最优省电追求最大兼容。发起方如果是自研网关那就灵活得多。可以在发起连接前先解析广播里的期望参数动态调整自己的发起参数。代价是逻辑复杂一点但能显著提升连接成功率。取舍的核心是谁更容易改就让谁去兼容。手机端改不动就设备端放宽设备端资源紧张就网关端做适配。没有标准答案取决于你的产品形态。一个容易被忽略的隐形陷阱从设备延迟这个字段有些协议栈在广播里根本不声明或者声明为0。发起方如果默认按自己的省电策略给一个较大的延迟而从设备实际不支持就会出现前面说的超时断开。更麻烦的是这个字段的行为在不同协议栈实现里不一致有的忽略发起方的值、坚持用自己的有的完全服从发起方。所以同样的参数换一批从设备模块表现可能完全不同。工程上的稳妥做法发起方给保守值。延迟给0或很小超时给足够大连接间隔给一个中间值。先保证能稳定连上再在连接建立后通过参数更新流程去协商更省电的配置。把建立连接和优化功耗分成两步比一次性赌对参数可靠得多。最后一句实在话这类问题的恶心之处在于它不给你明确的错误提示。你看到的是连不上“连上就掉”“时好时坏”这些现象和射频问题、电源问题、干扰问题的表现高度重叠很容易把人带到错误的排查方向上。养成一个习惯任何连接类故障先把两边的参数抓出来对比再去看射频和硬件。参数对比是几分钟的事能帮你排除掉一大半的伪硬件问题。