简介围绕 NetSpot 这款 Wi-Fi 分析与优化工具这份文档面向家庭用户、小型企业网管以及刚接触无线勘测的运维人员重点解决信号干扰、覆盖盲区与频道规划混乱等实际问题。全篇以 Discover、Survey 两种模式的操作为主线逐项说明 Level 信号强度排序、Graph 连续性断点判读、Detail 频段信息查看和 Channels 干扰检测的具体用法并给出 2.4GHz 频段 1-6-11、2-7-12、3-8-13 三组互斥频道组合的选型建议提醒避开 4、5、9、10 等易冲突频点同时讲清高干扰环境下改用 20MHz 频宽的取舍逻辑5GHz 部分也给出可参照的规划思路。压缩包共 1 个文件为 docx 格式图文教程体积约 1.15MB下载后即可离线查阅。目前已有 4952 人学习适合作为无线网络自查与故障排查的入门到进阶参考。1. 邻居的路由器才是你家 Wi-Fi 变慢的常见原因大多数人遇到 Wi-Fi 卡顿第一反应是换路由器、加一个 AP、把功率开到最大但真实原因常常在自家墙外——隔壁那台路由器正和你抢同一段频谱资源。想搞清楚这件事靠猜没有用需要一份能把空口证据显示出来的 Wi-Fi 优化使用文档NetSpot 做的正是这件事它把附近每一台 AP 的信号强度、信道占用、时间连续性变成可视化的图和表。反直觉的地方在于它最有价值的界面不是那张好看的热力图而是看起来最朴素的 Level 排序表和 Graph 曲线。这两样东西直接回答一个问题你的网络慢是覆盖不够还是干扰太重。这两种情况的解法几乎相反判断偏了改信道、加设备都等于白做。2. 空口扫描Discover 模式从空气里获取了什么2.1 Beacon 帧是分析的起点无线网卡本身并不会直接告诉你「这里有个 Wi-Fi」它只是被动接收 802.11 管理帧。AP 会周期性广播 Beacon 帧默认间隔约 100 毫秒也就是每秒十次左右客户端也可以主动发 Probe Request让 AP 用 Probe Response 回一句。NetSpot 的列表里出现的每一个 SSID、BSSID、RSSI、信道号、加密方式、频段全部来自这两类帧的解析结果。理解这一点很关键扫描器拿到的只是「某一瞬间听到的那一帧有多响」不是网络的实际吞吐。一个 AP 的 Beacon 再响如果它挂了几十个客户端在跑大流量实际体验照样可能很差。所以后面所有优化动作本质上都是在「听得多清楚」和「抢得有多凶」之间做取舍——而 NetSpot 只负责把「听得多清楚」量化出来剩下那半句话还得人来判断。这里还有一个容易被忽略的细节BSSID 才是唯一标识SSID 只是名字。同一个名字出现五六个条目说明这是一个多 AP 的 Mesh 或漫游组网只有一个条目、信号还忽高忽低那更可能是单台设备功率不足或天线摆放有问题。判断方向不同处理手段完全不一样。2.2 Discover 与 Survey两种完全不同的数据模型打开 NetSpot 后首先要做的选择就是 Discover 还是 Survey。很多人在这里选错后面所有分析都是无效的。Discover 不依赖平面图它持续轮询所有信道把每一轮扫到的结果堆成时间序列。它的数据模型可以简化成(BSSID, 时间) → RSSI。它回答的问题是「此刻谁在跟我抢」适合排查干扰、找信道冲突、看邻频占用。Survey 需要先导入或手绘一张平面图然后人拿着笔记本边走边采点每个测量点都绑定一个坐标。它的数据模型是(x, y, BSSID) → RSSI。它回答的问题是「哪个角落没覆盖到」输出的是热力图。这两件事不能互相替代。想找信号死角却选了 Discover你只能看到一堆随时间跳动的数字想排查干扰却选了 Survey你得到的热力图会把「邻居的 AP 今天功率调大了」这种时变因素抹平成一张静态图像。我一般建议的顺序是先 Discover 摸清环境里有多少台设备、挤在哪些信道再 Survey 看自家覆盖最后调参数调完再回 Discover 复扫验证。2.3 dBm 是对数刻度-67 这条线不是随口编的NetSpot 的 Level 视图会按信号强度倒序排列所有 AP单位是 dBm全是负数。新手最容易犯的错是把 -60 和 -70 当成「差 10」觉得差不多。实际上 dBm 是对数单位每降低 3dB功率减半在自由空间里每降低 6dB可用距离大致减半。也就是说 -70 相对 -67功率只有对方的一半左右。按经验值不同区间的实际含义大致如下表RSSI 区间功率相对基准典型体验-30 ~ -50很强贴着 AP几乎无丢包-50 ~ -60强高清视频、大文件传输稳定-60 ~ -67良日常网页、视频会议可用-67 ~ -75弱语音开始有断续视频降码率-75 ~ -85很弱频繁重传握手都可能失败低于 -85极弱名义上「有信号」实际不可用但光看 RSSI 会误判真正决定链路能不能跑的是信噪比。如果环境底噪在 -90dBm那么 -75dBm 的信号 SNR 是 15dB还能用如果附近有干扰源把底噪抬到 -70dBm那 -65dBm 的信号 SNR 只剩 5dB一样跑不动。「信号满格却打不开网页」这种常见问题十有八九是 SNR 的问题不是覆盖的问题。扫描结果本身是噪声很大的数据同一个 AP 每一轮测到的 RSSI 会上下浮动几分贝。直接看瞬时值容易被骗我习惯先做一次聚合再判断# 把网卡扫到的原始样本聚合成「时间窗内的代表值」 # 输入形如 [(bssid, channel, rssi_dbm, timestamp), ...] from collections import defaultdict import statistics def aggregate(samples, window_sec10): buckets defaultdict(list) for bssid, ch, rssi, ts in samples: # 按时间窗切桶同一个 AP 的同一个窗口归到一起 buckets[(bssid, int(ts // window_sec))].append(rssi) result defaultdict(list) for (bssid, win), values in buckets.items(): # 用中位数而不是均值偶发的一两个 -90dBm 掉点不该拉低整体判断 result[bssid].append((win * window_sec, statistics.median(values), len(values))) return result这段代码里有两个参数值得说清楚。window_sec决定时间分辨率取 10 秒是折中太短则中位数退化成瞬时值起不到去噪作用太长则会把「中途掉线又恢复」这种关键事件平滑掉。len(values)是这一窗内的样本数样本数明显偏少时说明扫描器在那段时间没能稳定抓到它这本身就是一条线索——可能它掉线了也可能它在信道间跳。用中位数而不是均值是为了避免一两个极端值带偏结论这一点在做现场排查时格外重要。3. Graph 曲线时间轴上的断点暴露出什么3.1 断点是三种不同故障的共用症状Discover 视图里的 Graph 会为每个 AP 画一条随时间起伏的曲线。曲线中间出现断口意思是那段时间扫描器完全没收到它的信号。这是整套工具里信息量最大的一个视图因为断点是一个「共用症状」背后至少对应三种完全不同的成因。第一种是干扰。同频或邻频的强信号把帧淹没了AP 并没有停只是你听不清。第二种是设备侧问题比如 AP 过热重启、供电不足、固件在后台做信道扫描。第三种是客户端行为设备进入省电模式后停止响应或者干脆在几个 BSSID 之间来回漫游。三者的处理方式天差地别靠肉眼看曲线是分不出来的得结合断点前后的信号强度和持续时间做推断。我在现场一般这么看断口前 RSSI 偏高、断口后又恢复到同一水平多半是干扰或瞬时拥塞断口后 RSSI 明显变了一个档次说明它换了位置或者客户端漫游到了另一台设备断口持续几十秒到几分钟、且周期性重复那更像是设备在主动做信道切换或重启。3.2 扫描周期决定了断点的最小可分辨尺度有一个容易被忽略的物理限制断点的时间精度不可能优于扫描周期。一轮完整扫描要把 2.4G 的十几个信道和 5G 的几十个信道挨个走一遍这个过程是秒级的。所以曲线上看起来是「瞬间断开」实际可能已经断了两三秒。反过来说持续时间短于扫描周期的丢包在 Graph 上根本看不出来——这也解释了为什么图很漂亮但用户还是觉得卡。判断断点是否可信可以用下面这个简单的检测逻辑# 从同一个 BSSID 的连续扫描记录里找出可疑断流 def find_gaps(timeline, gap_threshold3.0): timeline: [(t, rssi), ...] 按时间升序 gap_threshold: 多久没再看见它就算一次可疑断流秒 这个值必须大于 2 倍扫描周期否则满屏都是假断点 gaps [] for (t1, r1), (t2, r2) in zip(timeline, timeline[1:]): if t2 - t1 gap_threshold: gaps.append({ start: t1, end: t2, duration: t2 - t1, drssi: abs(r2 - r1), # 前后信号差用来判断是干扰还是漫游 }) return gapsgap_threshold的取值是这段逻辑的核心。如果一轮扫描要 2 秒才能走完所有信道那么阈值设成 3 秒就等价于「连续两轮都没抓到它」误报率比较可控设成 1 秒的话大量 AP 会因为扫描器这一轮恰好没轮到它的信道而被判成断流结果就是满屏假阳性。drssi是断口前后的信号差这个值小说明干扰、拥塞类问题可能性大值大说明换了位置或换了设备。3.3 别把「偶发丢包」和「真断网」混为一谈Graph 上一条浅浅的缺口和一条彻底消失的长断口性质完全不同。前者往往对应重传次数上升TCP 层还能靠重传撑住用户感知是「偶尔卡一下」后者是链路直接不可用表现为「突然断线重连」。前者该调信道、降频宽、挪天线后者该查供电、查固件、查是不是被别的设备踢下线。判断方法很朴素看这条曲线在其他时间段是否稳定。如果一条曲线整体平稳、只有零星缺口那是噪声如果曲线本身就在 -75 到 -55 之间大幅摆动说明这个测量点离 AP 处于覆盖边缘任何一点环境变化都会导致断流先解决覆盖再谈其他。4. 2.4GHz 信道规划1-6-11 的由来4.1 重叠的真相22MHz 带宽配上 5MHz 步进2.4GHz 频段里相邻信道号的中心频率只差 5MHz而一个信道标称占用 22MHz。这两个数字放一起重叠就是必然的。把信道号换算成中心频率其实是一个很简单的线性关系从 2412MHz 起每加一个信道加 5MHz。# 计算两个 2.4GHz 信道之间的频谱重叠比例0~1 CHANNEL_WIDTH 22.0 # 标称占用宽度 CHANNEL_STEP 5.0 # 相邻信道中心频率间隔 def overlap(c1, c2, widthCHANNEL_WIDTH): f1 2412 (c1 - 1) * CHANNEL_STEP f2 2412 (c2 - 1) * CHANNEL_STEP lo1, hi1 f1 - width / 2, f1 width / 2 lo2, hi2 f2 - width / 2, f2 width / 2 inter max(0.0, min(hi1, hi2) - max(lo1, lo2)) return inter / width for pair in [(1, 6), (6, 11), (6, 7), (4, 5), (3, 13), (12, 13)]: print(pair, round(overlap(*pair), 2))跑出来的结果很有意思(1,6)、(6,11)、(3,13)都是 0(6,7)、(4,5)、(12,13)都是 0.77。这就是「隔开 5 个信道」这个说法的数学来源——间距 25MHz 大于 22MHz 的占用宽度理论上可以完全错开。而相差 1 个信道5MHz时重叠比例高达 77%等于两台设备在抢同一块频谱。要提醒一句理论不重叠不等于实际不干扰。真实射频滤波器的滚降不是矩形边缘有泄漏靠得越近邻道泄漏越明显。所以 1-6-11 是「代价最小的方案」并非「零干扰方案」。4.2 三组组合不要混用1/-1 是典型的误判按这个数学关系能排出来的互不重叠组合不止一组组合信道号说明A 组1 / 6 / 11最常见的默认选择B 组2 / 7 / 12在 A 组已被占满时作为退路C 组3 / 8 / 13同理可用性取决于终端支持情况关键在于这三组只能整组选一组不能混搭。有些人看到 1、6、11 都有人用了就把自己的设备设成 2觉得「挪了一格总比撞车好」。实际结果是 2 和 1 之间重叠 77%和 6 之间也重叠 77%——从一个受害者变成了两个受害者的叠加而且把原本干净的 A 组结构破坏了。同理61、11-1 这类「往上往下挪一格」的操作占用的是两个信道之间的整段频谱原本想通过错开提高速率反而因为干扰降低了整体体验。4、5、9、10 这几个信道号在现场基本不建议使用。它们不与任何一组的标准组合兼容放进去只会制造半重叠的灰色地带让所有人的信道规划都失效。4.3 20MHz 还是 40MHz一个反直觉的取舍频宽的选择比信道选择更容易翻车。直觉上频宽越宽速率越高20MHz 变 40MHz 理论上速率翻倍。但在 2.4GHz 这个总共只有八十多兆的窄频段里一个 40MHz 的信道要吃掉两个 20MHz 的位置等于把前面辛苦排出来的三个非重叠槽位压缩成一个多。在公寓楼这种密布环境里一台设备开 40MHz周边所有设备都得陪着降速。所以干扰大时主动降到 20MHz是用峰值速率换稳定性。这里头有个容易被忽略的账Wi-Fi 是共享介质、靠 CSMA/CA 竞争发送的信道越宽每次竞争成功的发送时间越长碰撞概率和退避时间也越高。当周围有十几台设备在抢时40MHz 带来的额外吞吐会被碰撞抵消掉大半而延迟抖动明显上升——这才是「降频宽反而更流畅」的真实机制。4.4 5GHz 不是「随便开」只是可选信道更多5GHz 的资源确实丰富信道编号是 36、40、44、48、52……看着间隔 4 个号实际中心频率是每 20MHz 一个编号只是习惯写法。这意味着在 20MHz 频宽下相邻编号的 5G 信道天然就是不重叠的规划难度比 2.4G 低一个数量级。但有两个坑需要提前知道。一是部分 5G 信道属于需要动态频率选择的雷达共存频段AP 在使用前要静默侦听一段时间确认没有雷达类信号一旦检测到就会被强制迁走表现是「每隔一阵子整段掉线几分钟」——这种断流在 Graph 上非常典型是长断口且周期性重复。二是 5G 穿透和绕射能力弱于 2.4G同一位置 2.4G 还有 -70dBm5G 可能已经掉到 -80dBm 以下。所以 5G 的优化重点不在信道而在 AP 的点位把 AP 挪到能看见主要活动区域的位置比换任何一个信道都有效。5. 现场排查五条踩过的坑5.1 坑一热力图很漂亮用户还是喊卡现象是 Survey 出来的覆盖图一片绿但实际使用中视频会议频繁卡顿。原因在于热力图只反映信号强度完全不反映信道占用和底噪。一个信道上有六台 AP 同时工作在 -50dBm图上全是绿的空口却是饱和的。解决办法是回到 Discover 模式看 Channels 视图数一数每个信道上有几台设备、信号分别多强把「覆盖问题」和「容量问题」分开判断。5.2 坑二把信道改成 12 或 13 以避开拥挤现象是改完之后自己这边看起来清静了但部分设备搜不到网络或者连上就掉。原因是信道 12、13 处在标准规划之外不同终端对这两个信道的支持程度不一致有些网卡在主动扫描时压根不会去搜。而且 12 和 13 之间只差 5MHz重叠 77%一旦有第二台设备也这么干等于又撞在一起。解决办法是老老实实回到 A/B/C 三组里选一组拥挤就降频宽别往边角料信道上跑。5.3 坑三为了跑满速率把频宽开到 40MHz现象是测速软件单机跑分很好看多设备同时用就集体变慢、游戏延迟飙升。原因是 2.4G 的 40MHz 挤占了两个 20MHz 槽位把可用非重叠信道从三个压到一个多整个楼层的信道规划随之失效。解决办法是在设备密度高的环境统一锁 20MHz用管理界面把这当成一条规范推下去只有在独栋、周边扫描不到几台 AP 的场景才考虑放宽。5.4 坑四用手机上的信号格数代替专业扫描现象是手机显示三格信号就认定覆盖没问题。原因是手机 UI 的格数是厂商映射过的相对值不是 dBm同一位置不同机型能差十几 dB而且手机扫描间隔很粗抓不到短时干扰。解决办法是拿笔记本配合外置网卡做扫描至少保证测量工具和判断依据是同一套数据手机只用来做「实际体验」的最终验证。5.5 坑五把「信号满格」当成链路健康现象是 RSSI 显示 -45dBm属于极强但实际吞吐只有几百 KB/s。原因是附近有强干扰源把底噪抬得很高SNR 只剩个位数每次发送都要大量重传。解决办法是看 Graph 的稳定性而不是看峰值曲线在 -45 附近剧烈抖动、断口密集就说明不是覆盖问题而是干扰问题该做的是找干扰源、换信道而不是加 AP。6. 工具给证据、人给判断一套可复现的验证方式用久了会发现 NetSpot 有个明显的特点它几乎不给结论。扫描完不会弹出一句「建议改用信道 6」也不会告诉你「这里该加一个 AP」。这个设计取舍值得琢磨——无线环境是时变的任何自动建议都有时效性一旦工具给出确定性结论用户就会把它当成标准答案照抄然后在环境变化后失效却不知道为什么。我在实际项目里更愿意把它当成一台测量仪器配一套固定的验证流程先在 Discover 里按 Level 排序记下前五台设备的 BSSID 和信道切到 Channels 看 2.4G 的堆叠情况确认三组组合里哪一组是空的再看 Graph把有长断口的设备单独列出来判断是干扰还是设备故障改完信道和频宽之后隔一段时间用同样的方式复扫一次比对前后同一位置的 RSSI 中位数和断口数量。没有这一步复扫所有调整都只是猜测。Survey 的热力图也有类似的信任边界。它是把有限几个采样点做空间插值算出来的采点间距越大图越平滑也越不可信。我一般要求采点间距不超过两米穿墙位置必须补点因为墙体两侧的信号落差可能有 15dB 以上插值算法会把这道落差抹成一条渐变色看着很自然实际完全错位。这一点吃过亏之后印象很深图纸上一片绿人到现场站在那个位置手机连都连不上。验证的判据也别定得太玄。落到可量化的指标上就三条同一位置 RSSI 中位数是否抬高了 3dB 以上、Graph 断口数量是否明显减少、2.4G 上同信道竞争设备是否降到两台以内。三条都改善这次调整才算成立只改善一条那多半是环境本身在变不是你的操作起了作用。从那以后我每次做现场优化都强制走一遍「扫—改—复扫」的闭环绝不凭一次扫描结果就下结论。这份 NetSpot 使用文档把 Discover、Survey、Channels 几个视图的判读顺序、三组信道组合表和频宽建议串成了一条完整链路配着免费版就能照着做一遍剩下的就是把这套动作重复到形成肌肉记忆。希望帮到你。本文还有配套的精品资源点击获取
简介围绕 NetSpot 这款 Wi-Fi 分析与优化工具这份文档面向家庭用户、小型企业网管以及刚接触无线勘测的运维人员重点解决信号干扰、覆盖盲区与频道规划混乱等实际问题。全篇以 Discover、Survey 两种模式的操作为主线逐项说明 Level 信号强度排序、Graph 连续性断点判读、Detail 频段信息查看和 Channels 干扰检测的具体用法并给出 2.4GHz 频段 1-6-11、2-7-12、3-8-13 三组互斥频道组合的选型建议提醒避开 4、5、9、10 等易冲突频点同时讲清高干扰环境下改用 20MHz 频宽的取舍逻辑5GHz 部分也给出可参照的规划思路。压缩包共 1 个文件为 docx 格式图文教程体积约 1.15MB下载后即可离线查阅。目前已有 4952 人学习适合作为无线网络自查与故障排查的入门到进阶参考。1. 邻居的路由器才是你家 Wi-Fi 变慢的常见原因大多数人遇到 Wi-Fi 卡顿第一反应是换路由器、加一个 AP、把功率开到最大但真实原因常常在自家墙外——隔壁那台路由器正和你抢同一段频谱资源。想搞清楚这件事靠猜没有用需要一份能把空口证据显示出来的 Wi-Fi 优化使用文档NetSpot 做的正是这件事它把附近每一台 AP 的信号强度、信道占用、时间连续性变成可视化的图和表。反直觉的地方在于它最有价值的界面不是那张好看的热力图而是看起来最朴素的 Level 排序表和 Graph 曲线。这两样东西直接回答一个问题你的网络慢是覆盖不够还是干扰太重。这两种情况的解法几乎相反判断偏了改信道、加设备都等于白做。2. 空口扫描Discover 模式从空气里获取了什么2.1 Beacon 帧是分析的起点无线网卡本身并不会直接告诉你「这里有个 Wi-Fi」它只是被动接收 802.11 管理帧。AP 会周期性广播 Beacon 帧默认间隔约 100 毫秒也就是每秒十次左右客户端也可以主动发 Probe Request让 AP 用 Probe Response 回一句。NetSpot 的列表里出现的每一个 SSID、BSSID、RSSI、信道号、加密方式、频段全部来自这两类帧的解析结果。理解这一点很关键扫描器拿到的只是「某一瞬间听到的那一帧有多响」不是网络的实际吞吐。一个 AP 的 Beacon 再响如果它挂了几十个客户端在跑大流量实际体验照样可能很差。所以后面所有优化动作本质上都是在「听得多清楚」和「抢得有多凶」之间做取舍——而 NetSpot 只负责把「听得多清楚」量化出来剩下那半句话还得人来判断。这里还有一个容易被忽略的细节BSSID 才是唯一标识SSID 只是名字。同一个名字出现五六个条目说明这是一个多 AP 的 Mesh 或漫游组网只有一个条目、信号还忽高忽低那更可能是单台设备功率不足或天线摆放有问题。判断方向不同处理手段完全不一样。2.2 Discover 与 Survey两种完全不同的数据模型打开 NetSpot 后首先要做的选择就是 Discover 还是 Survey。很多人在这里选错后面所有分析都是无效的。Discover 不依赖平面图它持续轮询所有信道把每一轮扫到的结果堆成时间序列。它的数据模型可以简化成(BSSID, 时间) → RSSI。它回答的问题是「此刻谁在跟我抢」适合排查干扰、找信道冲突、看邻频占用。Survey 需要先导入或手绘一张平面图然后人拿着笔记本边走边采点每个测量点都绑定一个坐标。它的数据模型是(x, y, BSSID) → RSSI。它回答的问题是「哪个角落没覆盖到」输出的是热力图。这两件事不能互相替代。想找信号死角却选了 Discover你只能看到一堆随时间跳动的数字想排查干扰却选了 Survey你得到的热力图会把「邻居的 AP 今天功率调大了」这种时变因素抹平成一张静态图像。我一般建议的顺序是先 Discover 摸清环境里有多少台设备、挤在哪些信道再 Survey 看自家覆盖最后调参数调完再回 Discover 复扫验证。2.3 dBm 是对数刻度-67 这条线不是随口编的NetSpot 的 Level 视图会按信号强度倒序排列所有 AP单位是 dBm全是负数。新手最容易犯的错是把 -60 和 -70 当成「差 10」觉得差不多。实际上 dBm 是对数单位每降低 3dB功率减半在自由空间里每降低 6dB可用距离大致减半。也就是说 -70 相对 -67功率只有对方的一半左右。按经验值不同区间的实际含义大致如下表RSSI 区间功率相对基准典型体验-30 ~ -50很强贴着 AP几乎无丢包-50 ~ -60强高清视频、大文件传输稳定-60 ~ -67良日常网页、视频会议可用-67 ~ -75弱语音开始有断续视频降码率-75 ~ -85很弱频繁重传握手都可能失败低于 -85极弱名义上「有信号」实际不可用但光看 RSSI 会误判真正决定链路能不能跑的是信噪比。如果环境底噪在 -90dBm那么 -75dBm 的信号 SNR 是 15dB还能用如果附近有干扰源把底噪抬到 -70dBm那 -65dBm 的信号 SNR 只剩 5dB一样跑不动。「信号满格却打不开网页」这种常见问题十有八九是 SNR 的问题不是覆盖的问题。扫描结果本身是噪声很大的数据同一个 AP 每一轮测到的 RSSI 会上下浮动几分贝。直接看瞬时值容易被骗我习惯先做一次聚合再判断# 把网卡扫到的原始样本聚合成「时间窗内的代表值」 # 输入形如 [(bssid, channel, rssi_dbm, timestamp), ...] from collections import defaultdict import statistics def aggregate(samples, window_sec10): buckets defaultdict(list) for bssid, ch, rssi, ts in samples: # 按时间窗切桶同一个 AP 的同一个窗口归到一起 buckets[(bssid, int(ts // window_sec))].append(rssi) result defaultdict(list) for (bssid, win), values in buckets.items(): # 用中位数而不是均值偶发的一两个 -90dBm 掉点不该拉低整体判断 result[bssid].append((win * window_sec, statistics.median(values), len(values))) return result这段代码里有两个参数值得说清楚。window_sec决定时间分辨率取 10 秒是折中太短则中位数退化成瞬时值起不到去噪作用太长则会把「中途掉线又恢复」这种关键事件平滑掉。len(values)是这一窗内的样本数样本数明显偏少时说明扫描器在那段时间没能稳定抓到它这本身就是一条线索——可能它掉线了也可能它在信道间跳。用中位数而不是均值是为了避免一两个极端值带偏结论这一点在做现场排查时格外重要。3. Graph 曲线时间轴上的断点暴露出什么3.1 断点是三种不同故障的共用症状Discover 视图里的 Graph 会为每个 AP 画一条随时间起伏的曲线。曲线中间出现断口意思是那段时间扫描器完全没收到它的信号。这是整套工具里信息量最大的一个视图因为断点是一个「共用症状」背后至少对应三种完全不同的成因。第一种是干扰。同频或邻频的强信号把帧淹没了AP 并没有停只是你听不清。第二种是设备侧问题比如 AP 过热重启、供电不足、固件在后台做信道扫描。第三种是客户端行为设备进入省电模式后停止响应或者干脆在几个 BSSID 之间来回漫游。三者的处理方式天差地别靠肉眼看曲线是分不出来的得结合断点前后的信号强度和持续时间做推断。我在现场一般这么看断口前 RSSI 偏高、断口后又恢复到同一水平多半是干扰或瞬时拥塞断口后 RSSI 明显变了一个档次说明它换了位置或者客户端漫游到了另一台设备断口持续几十秒到几分钟、且周期性重复那更像是设备在主动做信道切换或重启。3.2 扫描周期决定了断点的最小可分辨尺度有一个容易被忽略的物理限制断点的时间精度不可能优于扫描周期。一轮完整扫描要把 2.4G 的十几个信道和 5G 的几十个信道挨个走一遍这个过程是秒级的。所以曲线上看起来是「瞬间断开」实际可能已经断了两三秒。反过来说持续时间短于扫描周期的丢包在 Graph 上根本看不出来——这也解释了为什么图很漂亮但用户还是觉得卡。判断断点是否可信可以用下面这个简单的检测逻辑# 从同一个 BSSID 的连续扫描记录里找出可疑断流 def find_gaps(timeline, gap_threshold3.0): timeline: [(t, rssi), ...] 按时间升序 gap_threshold: 多久没再看见它就算一次可疑断流秒 这个值必须大于 2 倍扫描周期否则满屏都是假断点 gaps [] for (t1, r1), (t2, r2) in zip(timeline, timeline[1:]): if t2 - t1 gap_threshold: gaps.append({ start: t1, end: t2, duration: t2 - t1, drssi: abs(r2 - r1), # 前后信号差用来判断是干扰还是漫游 }) return gapsgap_threshold的取值是这段逻辑的核心。如果一轮扫描要 2 秒才能走完所有信道那么阈值设成 3 秒就等价于「连续两轮都没抓到它」误报率比较可控设成 1 秒的话大量 AP 会因为扫描器这一轮恰好没轮到它的信道而被判成断流结果就是满屏假阳性。drssi是断口前后的信号差这个值小说明干扰、拥塞类问题可能性大值大说明换了位置或换了设备。3.3 别把「偶发丢包」和「真断网」混为一谈Graph 上一条浅浅的缺口和一条彻底消失的长断口性质完全不同。前者往往对应重传次数上升TCP 层还能靠重传撑住用户感知是「偶尔卡一下」后者是链路直接不可用表现为「突然断线重连」。前者该调信道、降频宽、挪天线后者该查供电、查固件、查是不是被别的设备踢下线。判断方法很朴素看这条曲线在其他时间段是否稳定。如果一条曲线整体平稳、只有零星缺口那是噪声如果曲线本身就在 -75 到 -55 之间大幅摆动说明这个测量点离 AP 处于覆盖边缘任何一点环境变化都会导致断流先解决覆盖再谈其他。4. 2.4GHz 信道规划1-6-11 的由来4.1 重叠的真相22MHz 带宽配上 5MHz 步进2.4GHz 频段里相邻信道号的中心频率只差 5MHz而一个信道标称占用 22MHz。这两个数字放一起重叠就是必然的。把信道号换算成中心频率其实是一个很简单的线性关系从 2412MHz 起每加一个信道加 5MHz。# 计算两个 2.4GHz 信道之间的频谱重叠比例0~1 CHANNEL_WIDTH 22.0 # 标称占用宽度 CHANNEL_STEP 5.0 # 相邻信道中心频率间隔 def overlap(c1, c2, widthCHANNEL_WIDTH): f1 2412 (c1 - 1) * CHANNEL_STEP f2 2412 (c2 - 1) * CHANNEL_STEP lo1, hi1 f1 - width / 2, f1 width / 2 lo2, hi2 f2 - width / 2, f2 width / 2 inter max(0.0, min(hi1, hi2) - max(lo1, lo2)) return inter / width for pair in [(1, 6), (6, 11), (6, 7), (4, 5), (3, 13), (12, 13)]: print(pair, round(overlap(*pair), 2))跑出来的结果很有意思(1,6)、(6,11)、(3,13)都是 0(6,7)、(4,5)、(12,13)都是 0.77。这就是「隔开 5 个信道」这个说法的数学来源——间距 25MHz 大于 22MHz 的占用宽度理论上可以完全错开。而相差 1 个信道5MHz时重叠比例高达 77%等于两台设备在抢同一块频谱。要提醒一句理论不重叠不等于实际不干扰。真实射频滤波器的滚降不是矩形边缘有泄漏靠得越近邻道泄漏越明显。所以 1-6-11 是「代价最小的方案」并非「零干扰方案」。4.2 三组组合不要混用1/-1 是典型的误判按这个数学关系能排出来的互不重叠组合不止一组组合信道号说明A 组1 / 6 / 11最常见的默认选择B 组2 / 7 / 12在 A 组已被占满时作为退路C 组3 / 8 / 13同理可用性取决于终端支持情况关键在于这三组只能整组选一组不能混搭。有些人看到 1、6、11 都有人用了就把自己的设备设成 2觉得「挪了一格总比撞车好」。实际结果是 2 和 1 之间重叠 77%和 6 之间也重叠 77%——从一个受害者变成了两个受害者的叠加而且把原本干净的 A 组结构破坏了。同理61、11-1 这类「往上往下挪一格」的操作占用的是两个信道之间的整段频谱原本想通过错开提高速率反而因为干扰降低了整体体验。4、5、9、10 这几个信道号在现场基本不建议使用。它们不与任何一组的标准组合兼容放进去只会制造半重叠的灰色地带让所有人的信道规划都失效。4.3 20MHz 还是 40MHz一个反直觉的取舍频宽的选择比信道选择更容易翻车。直觉上频宽越宽速率越高20MHz 变 40MHz 理论上速率翻倍。但在 2.4GHz 这个总共只有八十多兆的窄频段里一个 40MHz 的信道要吃掉两个 20MHz 的位置等于把前面辛苦排出来的三个非重叠槽位压缩成一个多。在公寓楼这种密布环境里一台设备开 40MHz周边所有设备都得陪着降速。所以干扰大时主动降到 20MHz是用峰值速率换稳定性。这里头有个容易被忽略的账Wi-Fi 是共享介质、靠 CSMA/CA 竞争发送的信道越宽每次竞争成功的发送时间越长碰撞概率和退避时间也越高。当周围有十几台设备在抢时40MHz 带来的额外吞吐会被碰撞抵消掉大半而延迟抖动明显上升——这才是「降频宽反而更流畅」的真实机制。4.4 5GHz 不是「随便开」只是可选信道更多5GHz 的资源确实丰富信道编号是 36、40、44、48、52……看着间隔 4 个号实际中心频率是每 20MHz 一个编号只是习惯写法。这意味着在 20MHz 频宽下相邻编号的 5G 信道天然就是不重叠的规划难度比 2.4G 低一个数量级。但有两个坑需要提前知道。一是部分 5G 信道属于需要动态频率选择的雷达共存频段AP 在使用前要静默侦听一段时间确认没有雷达类信号一旦检测到就会被强制迁走表现是「每隔一阵子整段掉线几分钟」——这种断流在 Graph 上非常典型是长断口且周期性重复。二是 5G 穿透和绕射能力弱于 2.4G同一位置 2.4G 还有 -70dBm5G 可能已经掉到 -80dBm 以下。所以 5G 的优化重点不在信道而在 AP 的点位把 AP 挪到能看见主要活动区域的位置比换任何一个信道都有效。5. 现场排查五条踩过的坑5.1 坑一热力图很漂亮用户还是喊卡现象是 Survey 出来的覆盖图一片绿但实际使用中视频会议频繁卡顿。原因在于热力图只反映信号强度完全不反映信道占用和底噪。一个信道上有六台 AP 同时工作在 -50dBm图上全是绿的空口却是饱和的。解决办法是回到 Discover 模式看 Channels 视图数一数每个信道上有几台设备、信号分别多强把「覆盖问题」和「容量问题」分开判断。5.2 坑二把信道改成 12 或 13 以避开拥挤现象是改完之后自己这边看起来清静了但部分设备搜不到网络或者连上就掉。原因是信道 12、13 处在标准规划之外不同终端对这两个信道的支持程度不一致有些网卡在主动扫描时压根不会去搜。而且 12 和 13 之间只差 5MHz重叠 77%一旦有第二台设备也这么干等于又撞在一起。解决办法是老老实实回到 A/B/C 三组里选一组拥挤就降频宽别往边角料信道上跑。5.3 坑三为了跑满速率把频宽开到 40MHz现象是测速软件单机跑分很好看多设备同时用就集体变慢、游戏延迟飙升。原因是 2.4G 的 40MHz 挤占了两个 20MHz 槽位把可用非重叠信道从三个压到一个多整个楼层的信道规划随之失效。解决办法是在设备密度高的环境统一锁 20MHz用管理界面把这当成一条规范推下去只有在独栋、周边扫描不到几台 AP 的场景才考虑放宽。5.4 坑四用手机上的信号格数代替专业扫描现象是手机显示三格信号就认定覆盖没问题。原因是手机 UI 的格数是厂商映射过的相对值不是 dBm同一位置不同机型能差十几 dB而且手机扫描间隔很粗抓不到短时干扰。解决办法是拿笔记本配合外置网卡做扫描至少保证测量工具和判断依据是同一套数据手机只用来做「实际体验」的最终验证。5.5 坑五把「信号满格」当成链路健康现象是 RSSI 显示 -45dBm属于极强但实际吞吐只有几百 KB/s。原因是附近有强干扰源把底噪抬得很高SNR 只剩个位数每次发送都要大量重传。解决办法是看 Graph 的稳定性而不是看峰值曲线在 -45 附近剧烈抖动、断口密集就说明不是覆盖问题而是干扰问题该做的是找干扰源、换信道而不是加 AP。6. 工具给证据、人给判断一套可复现的验证方式用久了会发现 NetSpot 有个明显的特点它几乎不给结论。扫描完不会弹出一句「建议改用信道 6」也不会告诉你「这里该加一个 AP」。这个设计取舍值得琢磨——无线环境是时变的任何自动建议都有时效性一旦工具给出确定性结论用户就会把它当成标准答案照抄然后在环境变化后失效却不知道为什么。我在实际项目里更愿意把它当成一台测量仪器配一套固定的验证流程先在 Discover 里按 Level 排序记下前五台设备的 BSSID 和信道切到 Channels 看 2.4G 的堆叠情况确认三组组合里哪一组是空的再看 Graph把有长断口的设备单独列出来判断是干扰还是设备故障改完信道和频宽之后隔一段时间用同样的方式复扫一次比对前后同一位置的 RSSI 中位数和断口数量。没有这一步复扫所有调整都只是猜测。Survey 的热力图也有类似的信任边界。它是把有限几个采样点做空间插值算出来的采点间距越大图越平滑也越不可信。我一般要求采点间距不超过两米穿墙位置必须补点因为墙体两侧的信号落差可能有 15dB 以上插值算法会把这道落差抹成一条渐变色看着很自然实际完全错位。这一点吃过亏之后印象很深图纸上一片绿人到现场站在那个位置手机连都连不上。验证的判据也别定得太玄。落到可量化的指标上就三条同一位置 RSSI 中位数是否抬高了 3dB 以上、Graph 断口数量是否明显减少、2.4G 上同信道竞争设备是否降到两台以内。三条都改善这次调整才算成立只改善一条那多半是环境本身在变不是你的操作起了作用。从那以后我每次做现场优化都强制走一遍「扫—改—复扫」的闭环绝不凭一次扫描结果就下结论。这份 NetSpot 使用文档把 Discover、Survey、Channels 几个视图的判读顺序、三组信道组合表和频宽建议串成了一条完整链路配着免费版就能照着做一遍剩下的就是把这套动作重复到形成肌肉记忆。希望帮到你。本文还有配套的精品资源点击获取
