做硬件和物联网这行时间长了，被问得最多的一类问题就是"这个场景到底该用哪种无线传输标准协议"。问的人既有刚转过来做物联网的软件工程师，也有做了多年结构、头一回碰射频的产品经理，还有一些是手上有个想法、想先做个原型验证的独立开发者。大家共同的困惑是：市面上的无线传输标准协议名字一大堆，参数表翻开来全是 Mbps、dBm、灵敏度、占空比，看得懂每个字，连起来就不知道该选哪个。

这篇东西想解决的问题很具体：把无线传输标准协议这层"标准"的外壳剥开，讲清楚它到底约束了什么、为什么这么约束、选型时该算哪几笔账、落地时会踩哪些坑。它适合三类人看——正在做第一次无线选型的工程师、被供应商参数表绕晕的产品经理、以及想把现有有线方案改成无线的开发者。我不会给你一份"哪个协议最好"的排行榜，那种东西不存在；我给的是判断路径和计算过程，你自己套进去就能得出结论。

1. 先搞清楚"标准协议"这四个字到底约束了什么

很多人对无线传输标准协议的理解停留在"规定了频段和速率"，这个理解太浅，会导致后面一系列判断失误。标准协议真正约束的是四层东西：物理层的调制方式与信道划分、MAC 层的信道接入规则、帧格式与地址体系、以及最容易被忽略的射频法规约束。这四层里任何一层不满足，你的设备要么通不了，要么过不了认证，要么在现场被同频设备打成筛子。

我见过一个挺典型的案例：某团队做了一个 2.4GHz 私有协议的温度采集系统，实验室里跑了一年没问题，装到现场第一周就开始丢包。后来抓频谱才发现，现场有几十台企业级 AP 在做高密度覆盖，信道占用率常年 60% 以上，他们那套固定的跳频图案正好撞在人家主信道上。这不是代码写错了，是标准协议里那套自适应避让机制他们没做，而现成的标准协议早就把这事儿解决了。

1.1 物理层与协议栈的分工边界

这是我最想先讲清楚的一点，因为它决定了你对一个技术的预期。不同的无线传输标准协议，覆盖的层数完全不一样，混为一谈会出大问题。

IEEE 802.11 系列规范的是物理层和 MAC 层，往上走 IP、TCP 这些是 IETF 的事；IEEE 802.15.4 同样只到 MAC 层，ZigBee 和 Thread 是在它之上补的网络层和应用层；蓝牙的核心规范覆盖范围更宽，从物理层一路管到 GATT 的属性模型，所以蓝牙应用开发基本不用操心底层；3GPP 那套更狠，从无线接入网一直管到核心网的信令。

而 LoRa 这种情况要特别注意——LoRa 本身只是一种基于 chirp 扩频的调制方式，属于物理层技术，芯片只提供"把一段字节发出去"的能力。真正让它变成一套完整无线传输标准协议的是 LoRaWAN，那里面才定义了入网流程、网关架构、ADR 速率自适应、MAC 命令这些。我遇到过不止一个团队，买了一批 sub-GHz 扩频模组，以为插上电就能组网，结果发现既没有网关侧的开源实现，也没有网络服务器，入网流程得自己从零设计。这个认知偏差能浪费掉两三个月。

所以拿到任何一个无线方案，先问三个问题：它到哪一层为止？上一层谁来补？补的那一层有没有成熟实现？这三个问题答不上来，后面的选型全是空中楼阁。

1.2 为什么不能自己造一套"更省电"的私有协议

每次聊到这儿，总有人问：标准协议那么臃肿，我自己设计一套精简的私有协议，功耗不是更低吗？

短期看确实如此。私有协议可以砍掉所有兼容性开销，帧头从 20 字节压到 3 字节，握手流程从三次减到一次，实测功耗能降 30% 甚至更多。但这个收益是有代价的，代价体现在三个地方。

第一是共存能力。免授权频段是公共走廊，你不能假设走廊里只有你一个人。标准协议里那些看起来"多余"的机制——802.11 的 CSMA/CA 加随机退避、蓝牙的自适应跳频、802.15.4 的 CSMA/CA——都是为了在拥挤环境里活下来。自己设计的协议在实验室干净环境里跑得飞快，一到现场就原形毕露。

第二是互操作性。你的设备将来要接第三方网关、要对接云平台、要过某个行业的准入测试，对方第一句就是"你支持什么标准"。私有协议在这里是零分，你得额外做一层转换，转换层的成本和风险往往超过省下来的那点功耗。

第三是认证与合规。免授权频段不代表免监管，射频指标、占空比、杂散发射这些都有硬性要求。基于成熟标准做的产品，测试机构有现成的测试方案，周期和费用都可控；纯私有协议往往要做额外的预测试，反复整改，时间成本很难估算。

我的经验判断是：节点数量少于 10 个、通信距离短、不需要和任何第三方设备互通、且产品生命周期不超过两年的场景，私有协议可以接受。超出这个范围，老老实实用标准协议，省下来的开发时间足够你把功耗优化做两轮。

2. 主流无线传输标准协议的横向拆解

把协议按"覆盖距离"和"是否需要授权频谱"两个维度摆开，选型的轮廓就能出来一大半。这里我不做绝对的好坏判断，只讲每个技术在设计上做了哪些取舍，这些取舍对应什么场景。

2.1 授权频谱与免授权频谱的第一道分水岭

这是最粗的一条线，也是很多人一开始就搞错的。蜂窝物联网那一类（NB-IoT、LTE-M）工作在运营商授权频谱上，你不需要自己规划频率、不需要自己建网关、不需要担心同频干扰，代价是要用运营商的卡、要付流量费、要接受运营商的网络覆盖现状。

免授权频谱那一类（2.4GHz、5GHz、sub-GHz 的 433/470/868/915MHz 等）你自己说了算，不用给谁交钱，但也意味着所有干扰风险你自己扛。这里有个常被忽略的细节：sub-GHz 免授权频段在很多地区是有占空比限制的，比如 868MHz 频段常见要求是 1% 占空比，意思是你在任意一小时里累计发射时间不能超过 36 秒。这个限制直接决定了你的上报频率上限，很多人做方案时压根没算这一项，产品做完了才发现法规上过不去。

对比一下发射条件就更清楚了。蜂窝物联网终端的发射功率通常可以到 23dBm，而且允许较高的重传次数；sub-GHz 免授权设备一般限制在 14dBm 左右，加上占空比约束，实际可用能量差了一个数量级。这就是为什么 NB-IoT 在地下车库、井盖下面还能通，而免授权方案在同样的位置基本没戏。

2.2 短距协议：802.11、蓝牙、802.15.4 的定位差异

这三个都在 2.4GHz 上混，但设计目标完全是三条路。

IEEE 802.11 走的是"用带宽换体验"的路子。从 802.11b 的 11Mbps 一路到 802.11ax 的 OFDMA 和高阶调制，再到 802.11be 引入的 320MHz 带宽和多链路聚合，核心思路一直是提高频谱效率、提高并发能力。代价是功耗，WiFi 的接收机为了维持高吞吐必须常开或频繁唤醒，休眠电流也在毫安级。所以 WiFi 适合有市电供电、或者电池容量足够大、或者对时延和带宽有硬要求的场景，比如摄像头、智能音箱、工业视觉。

蓝牙走的是"用小包换低功耗"的路子。低功耗蓝牙把连接事件切得非常细，两个连接事件之间射频完全关闭，平均电流可以压到几十微安。它在 2.4GHz 上划了 40 个信道，其中 37、38、39 三个专门做广播，而且这三个信道的中心频率刻意避开了 WiFi 最常用的 1、6、11 信道的中心位置。这个设计细节很能说明问题——标准制定者从一开始就假设蓝牙和 WiFi 会共存，所以把最容易撞车的频点让出来了。做产品时如果发现 BLE 广播被 WiFi 压制，先别急着调发射功率，先看看你的广播间隔和 WiFi 的 Beacon 周期是不是形成了周期性冲突。

IEEE 802.15.4 走的是"用速率换功耗和组网能力"的路子。2.4GHz 下只有 250kbps，sub-GHz 下更低，但它的 MAC 层天生支持 Mesh，节点可以做路由转发，网络规模能扩到几百个。ZigBee、Thread 都是在它上面长出来的。它的典型应用是照明控制、传感器网络、楼宇自动化这类节点多、单点数据量小、要求超长待机的场景。缺点是配置复杂，Mesh 网络的调试成本远高于星型网络，一个路由节点的位置选错，整个子网的重连风暴能持续好几分钟。

2.3 广域低功耗协议：扩频与蜂窝的取舍

广域这一块，主要两条路：一条是基于 chirp 扩频的免授权方案，一条是蜂窝物联网。

扩频方案的核心是用带宽换灵敏度。扩频因子每提高一档，灵敏度大约改善 2.5 到 3dB，代价是空中时间翻倍。常见的配置组合下，灵敏度能做到 -137dBm 左右，发射功率 14dBm，链路预算能到 150dB 以上，理论上覆盖几十公里。但空中时间也会长到一秒以上，配合 1% 占空比，一天能发的包数量是有限的。这个账必须提前算，不能等产品定义完了再发现发不出去。

蜂窝物联网的核心是用授权频谱换覆盖和确定性。它不需要你建网关，不用算占空比，支持 PSM 和 eDRX 两种省电模式，终端可以睡到几小时甚至几天才醒一次。代价是模组成本高于免授权方案、有持续的网络费用、而且信号质量完全取决于运营商在你那个点位的覆盖。

判断逻辑其实很简单：如果你的设备需要每秒上报一次，选短距协议自建网络；如果每分钟到每小时上报一次、点位分散在几十公里范围、且没有条件部署网关，蜂窝物联网更省心；如果上报间隔在几分钟到几小时、点位相对集中、希望完全自主可控，扩频方案加自建网关是性价比最高的。三者之间没有优劣，只有匹配度。

3. 选型必须算的三笔账：链路预算、功耗预算、空中时间预算

参数表上的数字都是理想条件下的，直接拿来用一定翻车。真正决定方案能不能落地的，是三笔必须自己动手算的账。这三笔账我建议做成脚本，每换一次方案就跑一遍，比拍脑袋可靠得多。

3.1 链路预算怎么算才不虚

链路预算的本质是一道加减法：发射端能给出的能量，减去路径上损失的能量，剩下的必须大于接收端能识别的最小信号。公式不复杂：

链路余量 = 发射功率 + 发射天线增益 + 接收天线增益 - 线损 - 接收灵敏度 - 衰落余量

前五项是确定的，最后一项衰落余量是经验值，也是最容易被人为忽略的一项。自由空间损耗的公式是：

FSPL(dB) = 32.44 + 20log10(距离km) + 20log10(频率MHz)

我拿两个典型场景算给你看。2.4GHz、100 米距离，FSPL = 32.44 + 20log10(0.1) + 20log10(2400) = 32.44 - 20 + 67.6 ≈ 80dB。也就是说光是自由空间就要吃掉 80dB。如果你的发射功率是 0dBm、灵敏度 -95dBm、天线增益各 2dBi、线损 1dB，那链路余量 = 0 + 2 + 2 - 1 - (-95) = 98dB，减去 80dB 自由空间损耗，还剩 18dB。听起来够用，但室内环境要加 15~25dB 的衰落余量（墙体、人体、家具），算完就只剩负数了。这就是为什么很多 2.4GHz 设备标称 100 米，实际隔一堵墙就掉线。

再看 sub-GHz 扩频方案。868MHz、发射 14dBm、天线各 2dBi、线损 1dB、灵敏度 -137dBm，链路余量 = 14 + 2 + 2 - 1 + 137 = 154dB。自由空间 868MHz 的常数是 32.44 + 20log10(868) = 32.44 + 58.8 = 91.2dB（1 公里时）。154 - 91.2 = 62.8dB 的富余，理论上能推到 1300 公里以上。这个数字当然是荒谬的，因为地球是圆的、还有地形遮挡。实际工程中，郊区视距能到 5~15 公里，城市密集区 1~3 公里，室内穿透一两层楼就明显衰减。这就是理论值和工程值的差距，写方案时千万别把理论值当承诺。

我把这套计算做成脚本，方便你改参数反复跑：

import math def fspl_db(distance_m, freq_mhz): """自由空间路径损耗""" d_km = max(distance_m, 1.0) / 1000.0 return 32.44 + 20 * math.log10(d_km) + 20 * math.log10(freq_mhz) def link_margin_db(tx_dbm, tx_gain_dbi, rx_gain_dbi, cable_loss_db, rx_sens_dbm, fade_margin_db): """链路余量，返回剩余可用 dB""" return (tx_dbm + tx_gain_dbi + rx_gain_dbi - cable_loss_db - rx_sens_dbm - fade_margin_db) def max_distance_m(margin_db, freq_mhz): """在给定余量下反推理论最大距离""" exponent = (margin_db - 32.44 - 20 * math.log10(freq_mhz)) / 20.0 return (10 ** exponent) * 1000.0 # 场景一：2.4GHz 室内 margin_wifi = link_margin_db(0, 2, 2, 1, -95, fade_margin_db=20) print(f"2.4GHz 室内链路余量: {margin_wifi:.1f} dB") print(f"对应理论距离: {max_distance_m(margin_wifi, 2400):.1f} m") # 场景二：868MHz 郊区扩频 margin_lora = link_margin_db(14, 2, 2, 1, -137, fade_margin_db=30) print(f"868MHz 郊区链路余量: {margin_lora:.1f} dB") print(f"对应理论距离: {max_distance_m(margin_lora, 868):.0f} m")

跑完你会发现一个反直觉的结论：把发射功率从 14dBm 提到 20dBm，链路余量只增加 6dB，换算成距离大约是提升 1.4 倍；而把灵敏度从 -130dBm 改善到 -137dBm，增加 7dB，效果更好，而且不增加功耗也不违反发射限制。这就是为什么在受限场景下，优化接收端往往比堆发射功率更划算。

3.2 功耗预算：从数据手册到真实续航

数据手册上的"休眠电流 1uA、接收电流 10mA、发射电流 45mA"，这些数字单独看没有意义，必须换算成平均电流才有参考价值。平均电流的算法是把每个状态的时间占比乘上对应电流，再全部加起来。

我拿一个典型传感器节点举例，参数是这样的：每 60 秒唤醒一次，唤醒后 MCU 工作 50ms（电流 4mA），然后射频发射 20ms（电流 45mA），再接收等 30ms 的确认（电流 12mA），剩下时间全休眠（电流 2uA）。计算过程如下。

一小时有 60 个周期，每个周期 60 秒。单周期内各状态的时间：MCU 工作 0.05s，发射 0.02s，接收 0.03s，休眠 60 - 0.1 = 59.9s。

电荷量 = 4mA × 0.05s + 45mA × 0.02s + 12mA × 0.03s + 0.002mA × 59.9s = 0.2 + 0.9 + 0.36 + 0.1198 = 1.58 mAs

平均电流 = 1.58mAs / 60s ≈ 26.3uA

用一颗容量 220mAh 的纽扣电池，理论续航 = 220 / 0.0263 ≈ 8365 小时 ≈ 348 天。这个数字看着还行，但要打个折扣：电池自放电每年 1~2%、低温下容量下降、实际休眠电流往往比手册高一个量级（PCB 漏电、电容漏电、GPIO 配置错误都会贡献几微安）、还有电池内阻导致的电压跌落。实际做到标称值的 60% 就算不错了。

这里有个特别容易被忽略的点：唤醒时间。很多低功耗设计把休眠电流压到 1uA，结果每 60 秒唤醒一次，每次唤醒要等晶振起振、等射频 PLL 锁定，光这个过程就吃掉 5ms，而且这 5ms 里电流是毫安级的。积少成多，这部分开销可能比休眠电流大得多。我的做法是在选型阶段就把"唤醒开销"算进单周期电荷，而不是只看静态电流。

def avg_current_ua(states, period_s): """ states: [(电流mA, 持续时间s), ...] period_s: 整个周期时长 """ charge_mas = sum(i * t for i, t in states) return charge_mas / period_s * 1000.0 states = [ (4.0, 0.05), # MCU 工作 (45.0, 0.02), # 射频发射 (12.0, 0.03), # 射频接收 (0.002, 59.9), # 深度休眠 ] i_avg = avg_current_ua(states, 60) print(f"平均电流: {i_avg:.1f} uA") print(f"220mAh 电池理论续航: {220 / (i_avg / 1000) / 24:.0f} 天")

3.3 空中时间与占空比合规

这一项只有你想用免授权 sub-GHz 频段时才致命，但一旦踩坑就是整个方案推翻。

扩频的空中时间计算公式是固定的，我不建议手算，直接把公式写成脚本。核心参数是扩频因子（SF）、带宽（BW）、编码率（CR）和负载长度。符号时长等于 2 的 SF 次方除以带宽，前导码时长等于（前导码符号数 + 4.25）乘以符号时长，负载部分要先算出负载符号数再相乘。

我算一个常见配置给你看：SF9、BW125kHz、CR 4/5、前导码 8 个符号、负载 20 字节。符号时长 = 512 / 125000 = 4.096ms。前导码 = (8 + 4.25) × 4.096 ≈ 50.2ms。负载符号数的分子是 8×20 - 4×9 + 28 + 16 = 168，分母是 4×(9-0) = 36，相除向上取整得 5，再乘以 (CR对应值 + 4) 即 5，得到 25，加上固定的 8 个符号共 33 个符号。负载时长 = 33 × 4.096 ≈ 135.2ms。总空中时间约 185ms。

按 1% 占空比算，一小时 3600 秒，可用发射时间 36 秒，除以 185ms 约等于 194 次上报。也就是说这个配置下每小时最多发 194 个包，换算下来大约每 18.5 秒一次。如果你的需求是每 5 秒上报一次，这个配置就不合规，必须降低扩频因子缩短空中时间，或者换用 2.4GHz 免授权频段。

def lora_airtime_ms(sf, bw_khz, cr, pl_bytes, preamble=8): """扩频空中时间估算，cr 取值 1~4 对应 4/5 到 4/8""" t_sym = (2 ** sf) / (bw_khz / 1000.0) / 1000.0 * 1000 # ms t_preamble = (preamble + 4.25) * t_sym de = 1 if (sf >= 11 and bw_khz == 125) else 0 num = 8 * pl_bytes - 4 * sf + 28 + 16 - 20 * 0 den = 4 * (sf - 2 * de) payload_sym = 8 + max(math.ceil(num / den) * (cr + 4), 0) return t_preamble + payload_sym * t_sym for sf in range(7, 13): t = lora_airtime_ms(sf, 125, 1, 20) print(f"SF{sf}: {t:.0f} ms, 1%占空比下每小时最多 {int(36000 / t)} 包")

这段代码跑出来的结果会很直观地告诉你：SF 每加一档，空中时间大约翻倍，可上报次数大约减半。灵敏度用上报频率换的，天下没有免费午餐。

4. 落地实操：一次典型无线节点的协议落地过程

理论算完，落到板子上还有一大堆事。我把一个典型节点的落地流程拆成三步，每步都写清楚我在实际项目里会怎么做。

4.1 需求冻结与协议初筛

动手前必须先冻结五个参数，这五个参数不定下来，选型就是瞎猜。

一是数据量。每个包多少字节，含帧头。这一项直接排除掉一批协议，比如你要传 1KB 的图片，802.15.4 直接出局。

二是上报频率。多久一次，允许多大的抖动。这一项决定占空比和平均电流。

三是覆盖范围。是同一个房间、同一栋楼、还是跨厂区。这一项决定是短距还是广域。

四是供电方式。市电、大容量锂电、纽扣电池、还是能量采集。这一项决定功耗预算是毫安级还是微安级。

五是生命周期。产品打算卖几年，是否需要后续扩展节点。这一项决定要不要为一时的省事牺牲互操作性。

五个参数填完，用排除法过一遍：纽扣电池供电加高频上报，WiFi 和蜂窝直接排除；跨厂区覆盖加自建网络，短距 Mesh 排除；需要手机直接配网，没有蓝牙的方案被动排除。通常过完一轮只剩两三个候选，这时候再用上一节的三笔账做定量比较。

我个人的习惯是把这个过程写成一个简单的决策表，每个候选方案一行，链路余量、平均电流、空中时间占比、模组成本、开发工作量各列一列，打分加权。加权这事儿看着很土，但确实能避免被某一项参数带偏。

4.2 射频前端与天线匹配的实做

这一块是最容易出问题、也最容易被软件工程师忽略的。协议选得再对，射频前端做砸了，实测距离可能只有理论值的十分之一。

先说天线。2.4GHz 的板载 PCB 天线，尺寸和净空区是硬约束，净空区内不能铺铜、不能走线、不能放电池，下方地平面要完整。我见过太多把电池贴在 antenna 正下方的设计，实测直接掉 10dB，还以为是协议问题。sub-GHz 的弹簧天线或陶瓷天线对地平面尺寸更敏感，地平面不够大，辐射效率上不去，灵敏度也受影响。

再说匹配网络。芯片手册里给的匹配参数是针对特定叠层和特定板材的参考值，换个板厂、换个板厚，参数就得重调。我的做法是打样时留出 pi 型匹配网络的三个焊盘，先用矢量网络分析仪测 S11，目标是回波损耗优于 -10dB。没有网分的团队，至少要在暗室或者开阔场地做一次对比测试：把设备放在已知距离，换不同匹配元件组合，看接收信号强度指示的变化，虽然粗糙但比不调强。

还有一个细节是电源去耦。射频功放工作时是脉冲电流，如果电源去耦不到位，发射瞬间会把电源拉低，MCU 可能复位，或者 ADC 采样跳变。我的经验是在功放电源脚旁边放 100nF 加 10uF，中间串一个磁珠，磁珠的直流电阻要小，否则压降会影响发射功率。

4.3 抓包与实测验证

做完硬件，验证环节不能只看"能不能通"，要看具体指标。

第一步是空口抓包。2.4GHz 可以用支持监听模式的网卡配合抓包工具，抓 Beacon 帧、抓重传、抓 ACK 丢失。我一般会重点看三个指标：重传率、信噪比分布、以及相邻信道的能量。重传率超过 10% 就要查原因，可能是同频干扰、可能是天线失配、也可能是接收灵敏度设置不合理。

第二步是拉距测试。别在实验室里绕圈，去真实场景。我的标准流程是选一条直线路径，每隔固定距离记录一次接收信号强度和丢包率，画出曲线。曲线在某个距离突然断崖式下跌，通常意味着菲涅尔区被遮挡，这时候抬高天线高度往往能救回来。

第三步是长时间稳定性观察。至少跑 72 小时，记录丢包、重连、以及异常复位。这一步能抓出很多间歇性问题，比如温度升高后晶振频偏导致失锁、比如电池电压下降后功放输出功率不足。

批量生产前还要做一致性抽样，至少抽 20 台做同样的拉距测试，看离散度。我遇到过一次，同一批板子有 3 台距离只有其他板子的三分之一，最后查到是天线匹配电容的贴片位置偏了 0.3mm，导致寄生参数变化。这种问题不做抽样根本发现不了。

5. 常见问题与排查实录

这一节全是踩过的坑，按现象分类整理，遇到问题可以直接对号入座。

5.1 排查速查表

5.2 几个只有踩过才知道的坑

第一个坑：把人体的影响忘了。2.4GHz 对人体的吸收非常明显，设备拿在手上和放在桌上，接收信号强度能差 6~10dB。做可穿戴产品时，必须在"佩戴状态"下做校准，否则出厂参数全是错的。我吃过这个亏，实验室调好的阈值，用户戴在身上就频繁掉线。

第二个坑：低温下的频偏。很多低成本晶振的温度特性不好，零下二十度时频偏能到几十 ppm，超出协议允许范围，接收端解不出来。做户外产品一定要用带温度补偿的晶振，或者在固件里做频率补偿。

第三个坑：休眠电流的隐性开销。GPIO 配置成输入但悬空，会产生漏电；调试接口没关，会持续消耗；LDO 的静态电流被忽略。这几项加起来轻松超过 10uA，比你的 MCU 休眠电流大好几倍。我的做法是在样机阶段就逐项断开测量，把每一路的电流摸清楚。

第四个坑：把"连接成功"当成"通信正常"。协议层连接建立不代表链路质量好，很多设备连接着但实际在反复重传，功耗翻倍、时延抖动。必须看应用层的实际吞吐和重传计数，不能只看连接状态灯。

第五个坑：忽略了协议版本兼容。同一个协议不同版本之间，有些参数默认值是不一样的。比如蓝牙低功耗在不同版本里对连接参数范围的要求有变化，一端按新版本配、另一端按旧版本解，就会出现协商失败。做产品时要把协议版本和关键参数写进对接文档，别指望对方猜。

6. 一些我自己的判断习惯

写了这么多，最后分享几个我这些年形成的判断习惯，可能比具体参数更有用。

第一个习惯是"先看最坏情况"。任何方案我都先问：在信号最差、干扰最强、电压最低、温度最极端的组合下，它还能不能工作？三个账算的都是典型值，实际产品必须留够余量。我一般要求链路余量在设计阶段保留 10dB 以上的富余，功耗预算按计算值的 1.5 倍准备。

第二个习惯是"不要为了单一指标牺牲全局"。有人为了追求极致续航，把上报间隔拉到一小时，结果产品根本满足不了业务需求；有人为了追求覆盖距离，把扩频因子拉满，结果占空比超限。选型是多个约束下的最优点，不是单项目标的最大值。

第三个习惯是"能借力就不自己造"。标准协议里那些看起来笨重的机制，都是无数场景打磨出来的。自己实现一遍，省下的那点开销，往往要用几倍的调试时间去还。除非你的场景确实极端到标准协议覆盖不了，否则别轻易走出这个圈。

第四个习惯是"留好升级的接口"。无线这块变化很快，今年选的方案两三年后可能就有更合适的替代。硬件上留出封装兼容的焊盘，软件上把射频驱动抽象成一层接口，将来换方案时改动量能降到最低。这一点在做长生命周期产品时特别重要，我见过太多因为射频方案锁死导致整个产品线无法迭代的例子。