企业官网建设流程全解析

把家里的路由器换成支持 WiFi6 的型号之后，测速软件上的数字确实涨了，但打游戏该卡还是卡，多设备同时在线该掉线还是掉线——这个落差在 WiFi6 刚铺开那阵子特别普遍。前两篇把调制方式、频段划分、理论速率这些"纸面参数"讲完了，这一篇换个角度，专门聊 WiFi6 在调度层面到底改了什么，以及这些改动在你家客厅里能不能兑现成真实体验。如果你已经买了 WiFi6 设备却感觉"没吃到红利"，或者正准备给多设备环境做一次网络升级，这篇的内容应该比参数表更管用。我会按"机制→增益边界→部署调参→排错"的顺序讲，中间穿插一些实测数据和容易踩的坑，尽量让每一步都能直接照做。

1. 从"单车道独占"到"车队调度"：OFDMA 真正改的是分配粒度

WiFi5 时代的一次传输，本质上是"整个信道归一个设备用"。哪怕你要发的只是一个几十字节的确认包，也得占满整个 20/40/80MHz 信道，把所有子载波都用上，然后其他设备在旁边干等。这就好比一条八车道的高速公路，只允许一辆车通行，哪怕这辆车只是送个快递。设备一多，空口时间全消耗在"排队—抢到—只发一点点—再排队"的循环里。

OFDMA 把这件事拆开了。它在频域上把信道切成若干个子载波组，也就是RU（Resource Unit），然后在一帧之内同时给多个设备分配不同的 RU。关键在于"同时"两个字——不是时分复用那种你发完我发，而是同一个 OFDM 符号周期内，多个设备的数据并行出现在不同子载波上。空口时间的利用率就这么被拉起来了。

1.1 RU 的切分尺寸与数量约束

RU 不是随便切的，802.11ax 定义了固定的几种规格，按子载波数量划分：26-tone、52-tone、106-tone、242-tone、484-tone、996-tone。数字越大，占用带宽越宽，能承载的速率越高；数字越小，切得越细，能同时服务的设备越多。

这张表值得多看两眼。它解释了一个常见困惑：为什么 20MHz 带宽下，AP 号称能"同时服务 9 个设备"，但你实际测下来并发性能并没有提升 9 倍。因为 26-tone RU 能承载的速率非常低，一个 26-tone RU 在 20MHz、MCS11 下的峰值也就十几 Mbps 量级，适合传小包，不适合传大文件。真要跑吞吐，还是得用 242-tone 甚至 996-tone 的大 RU，那同时服务的设备数就退回 1 个了。所以 OFDMA 的并发增益和单流速率是此消彼长的关系，调度器要根据流量类型动态权衡。

再补一个细节：不同 RU 可以独立选择 MCS。这一点经常被忽略，但它是 OFDMA 最实用的地方之一。离 AP 近的手机可以用 MCS11（1024-QAM），角落里那台信号弱的智能插座用 MCS3 甚至 MCS0，两者在同一个帧里共存，互不拖累。WiFi5 时代不是这样——一帧的调制方式是全局统一的，慢设备会把整帧的速率拉下来，这就是所谓的"慢设备拖累"问题。

1.2 低负载场景下 OFDMA 为什么看不出优势

很多人做实测，家里就两三台设备，开了 WiFi6 关了 WiFi6 测出来的速率几乎一样，于是得出结论"OFDMA 是营销噱头"。这个结论下得太快了。

OFDMA 的收益前提是并发需求真实存在。设备少的时候，调度器没有并发的对象，只能把整个信道分给唯一一个活跃设备，此时 OFDMA 和 OFDM 的行为几乎完全一致，甚至因为多了 RU 分配的信令开销，效率略微下降。要观察到增益，至少得有这么几个条件同时成立：

• 同时活跃的设备数 ≥ 4，且都在持续产生流量
• 流量以中小包为主（网页、即时消息、视频会议信令、IoT 上报），而不是单个大文件下载
• AP 的调度器实现足够好，能识别流量类型并做出合理的 RU 分配

我在一个十几台设备的办公场景里做过对比，全部设备同时刷网页、开视频会议，WiFi6 开启 OFDMA 相比关闭，平均往返时延从 30ms 量级压到 15ms 量级，抖动明显收窄；但换成单台设备跑大文件下载，两者吞吐差距在 3% 以内。所以判断 OFDMA 有没有用，别用测速软件，用多设备同时在线时的时延和抖动去衡量，这才是它真正作用的地方。

注意：部分家用路由器默认关闭 OFDMA，或者隐藏在"高级无线设置"里。刷完固件后这个选项有可能被重置，升级完记得回去确认一遍。

1.3 上行 OFDMA 依赖触发帧，这是与下行的关键差异

下行 OFDMA 好理解——AP 是发送方，它自己决定怎么切 RU、分给谁。上行就麻烦多了，因为 AP 不知道每个客户端此刻有没有数据要发、要发多少。如果让客户端自己抢 RU，冲突会比 OFDM 时代更严重。

802.11ax 的解法是Trigger Frame（触发帧）。AP 先发一个触发帧，里面用 User Info 字段逐条列出"设备 A 用 RU1、MCS4、长度 200 字节；设备 B 用 RU2、MCS7、长度 80 字节"，各设备按这个时间表在同一时刻开始发送。整个过程类似老师点名让几个学生同时上黑板写不同的题，写多久、写多少都提前说清楚。

这个机制对固件实现质量要求很高。触发帧解析错了、时间对齐偏了，就会导致上行 MU 传输失败重传，表现就是"上行速度反而变慢"。有些早期 WiFi6 设备在上行 OFDMA 上的实现比较粗糙，实际开启后上行吞吐不升反降，这类问题只能靠固件更新解决。我一般建议：新设备到手先跑一遍上下行对称测试，如果上行明显异常，先试着关掉上行 OFDMA 对比一下，确认是设备实现问题再决定要不要等固件。

2. BSS Coloring：把"听到就退让"改成"听清再决定"

如果说 OFDMA 解决的是"自己家内部怎么分资源"，BSS Coloring 解决的就是"邻居家的信号要不要理"。

传统 802.11 的载波侦听机制（CCA）非常保守：只要在信道上检测到能量超过阈值（一般是 -82dBm），就判定信道忙，主动退避。这个规则在同频干扰严重的环境里是灾难性的——你家 AP 和邻居家 AP 用同一个信道，双方都能听到对方，于是双方都在不停地退避，空口时间被大量浪费在"谦让"上。这就是老小区、密集公寓里 WiFi 体验极差的核心原因之一。

2.1 6 比特颜色字段带来的判定分层

802.11ax 在 PHY 头里加了一个 6 比特的BSS Color字段，取值范围 0 到 63（0 一般表示未启用）。每个 BSS（基本服务集）被分配一个颜色值，同频的邻居 AP 理论上应该用不同颜色。

接收端收到一帧后，先看颜色：

• 颜色和自己相同 → 判定为 intra-BSS，是本 BSS 内部的传输，按原来的严格 CCA 规则处理，该退避就退避
• 颜色和自己不同 → 判定为 inter-BSS，是邻居的信号，此时可以启用更高的 CCA 阈值（典型值 -72dBm 左右），如果收到的信号强度低于这个阈值，就直接认为"这个干扰不足以影响我"，继续发送

效果就是：即使邻居 AP 的信号能飘到你家，只要强度不高，你就不用再躲它了。空间复用率显著提升，密集环境下的实际吞吐改善往往比理论速率提升更明显。

2.2 颜色冲突与重新分配

现实里颜色不够用。63 个值听着不少，但一个高密度办公区动辄几十个 AP，颜色撞车几乎是必然的。一旦两个相邻 AP 用了同一个颜色，双方又会互相判定为 intra-BSS，退回到保守的退避逻辑，BSS Coloring 的收益归零。

好的 AP 固件会做颜色冲突检测：监听一段时间，统计收到的同色帧数量，超过设定阈值就触发颜色切换，并通知下属客户端更新。这个过程一般是无感的，但某些实现较差的设备在切换期间会短暂出现连接抖动。

家用场景里，颜色冲突的排查其实不难。绝大多数消费级路由器的管理界面不会直接显示 BSS Color，这时候可以借助一些无线分析类工具查看信标帧里的 HE 相关字段。如果发现周围多个 AP 颜色相同且信号都不弱，手动改一下自己 AP 的颜色值（一般在无线高级设置里）往往能立竿见影。

提示：BSS Coloring 只在同信道时才起作用。如果你的 AP 和邻居在不同信道，本来就不会互相 CCA 退避，这个功能开着也没坏处，但别指望它带来额外收益。

2.3 这个功能为什么在家庭场景几乎无感

说句实话，BSS Coloring 的主要战场是高密度场景——办公室、商场、会议室、学生宿舍楼。独栋住宅、周边 AP 数量寥寥的环境里，你根本遇不到同频干扰问题，开不开这个功能都不会有区别。

真正需要关注它的场景是：老旧小区、公寓楼、一层十几户的出租房，周围能扫出二十个以上 SSID，且信道严重重叠。这种情况下，BSS Coloring 加上 OFDMA 的组合，对晚高峰时段的体验改善是实打实的。我见过一个典型例子，某栋楼里同一信道上挤了七个 AP，启用 BSS Coloring 后，中位时延下降了将近四成。

3. MU-MIMO 的上下行不对称，以及它到底能带来多少

MU-MIMO（多用户多输入多输出）不是 WiFi6 才有的东西，WiFi5 Wave2 就引入了下行 MU-MIMO。但 WiFi5 时代的实现限制很多，最要命的一条是：只支持下行，而且要求客户端也支持 MU-MIMO，实际兼容的终端少之又少，功能基本处于"开了也没用"的状态。

WiFi6 把这件事推进了一步：下行 MU-MIMO 扩展到最多 8 个空间流，同时新增了上行 MU-MIMO。这个"新增"是重点。

3.1 下行 MU-MIMO 的天线账要先算清楚

下行 MU-MIMO 的原理是用空间自由度在同一个时频资源上同时服务多个设备，靠波束成形把不同数据流"瞄准"不同方向。AP 的天线数决定了能力上限：4 天线可以同时服务最多 4 个单流设备（或者 2 个双流设备），8 天线同理。

这里有个特别容易误判的地方。很多路由器标称"AX6000""AX11000"，数字很大，但拆开看往往是"2.4GHz 4x4 + 5GHz 4x4"之类的组合，两个频段的天线不能合并使用。而且实际并发能力还受限于 AP 能不能拿到准确的 CSI（信道状态信息）——它需要客户端配合发送探测反馈，反馈不及时或者精度不够，波束成形就瞄不准，MU-MIMO 增益直接打折。

家用环境里，MU-MIMO 的实际增益通常不如宣传的那么明显，原因是：

• 手机、笔记本绝大多数是 2x2 甚至 1x1，凑不齐足够的并发流
• 设备分散在房间各处，空间相关性不高，波束成形效果受限
• 需要多台设备同时有大流量需求，而这在家庭场景里是间歇性的

我的经验是，4x4 的 AP 配上五六台设备，MU-MIMO 带来的下行吞吐提升在 15% 到 30% 之间，视设备分布和流量模式波动很大。指望它翻倍，不现实。

3.2 上行 MU-MIMO 为什么必须靠触发帧串起来

上行 MU-MIMO 的实现难点在于：多个客户端要在同一时刻、用不同的空间流向上发送，而它们的时钟、频率、功率都是各自独立的。没有统一的协调，接收端根本没法把混在一起的空间流分开。

所以上行 MU-MIMO 和上行 OFDMA 一样，依赖 Trigger Frame 统一调度。AP 发触发帧，指定每个客户端使用的空间流和发送参数，同时要求它们提前发送 NDP（Null Data Packet）供 AP 测量信道。整个流程的信令开销不小，只有在多设备持续上传的场景下才划算——比如多路视频监控回传、多人同时视频会议上传。

顺带一提，WiFi6 里的 OFDMA 和 MU-MIMO 是可以叠加使用的，也就是频域切 RU、空域切空间流，两者组合起来才是完整的 MU 能力。但组合调度的复杂度也成倍上升，实际能不能跑出效果，非常依赖 AP 的芯片方案和固件成熟度。

3.3 判断自家环境值不值得为 MU-MIMO 折腾

给个简单的判断思路：

最后一行是我最想强调的。很多人在信号本身就弱的房间里纠结 MU-MIMO 有没有生效，这完全是本末倒置——波束成形和空间复用的前提是链路质量足够好，先解决覆盖，再谈多用户。一个稳定的 -60dBm 单流连接，体验远好过一个 -75dBm 勉强维持的双流连接。

4. TWT 省电协商：机制不难，难在兼容性

TWT（Target Wake Time，目标唤醒时间）是 WiFi6 里最"低调"的功能，宣传上远不如速率提升显眼，但对电池供电设备的续航影响是数量级的。

传统 WiFi 的省电机制是周期性醒来看 Beacon，看有没有自己的缓存数据。这个周期是固定的，所有设备都得按同一个节奏醒来，醒来就要竞争信道，设备一多就是一堆小包碰撞。TWT 换了个思路：AP 和客户端提前约定一个具体的唤醒时间点，客户端在约定时间之外可以彻底休眠，射频关掉，只留一个极低功耗的计时器。

4.1 个体 TWT 与广播 TWT 的协商流程

TWT 有两种形态，用起来差别挺大。

个体 TWT（Individual TWT）是一对一协商：客户端发 TWT Request 帧，里面带着建议的唤醒周期、唤醒时长、最小唤醒间隔等参数；AP 回 TWT Response，要么接受，要么调整参数后再接受，要么直接拒绝。协商成功后，双方按这个时间表执行，每一轮都可以重新谈。

广播 TWT（Broadcast TWT）是 AP 统一广播一份时间表，挂在它下面的设备按需加入。好处是客户端不需要逐个协商，兼容性门槛低；代价是灵活性差，所有设备挤在同一批唤醒窗口里，容易形成新的拥堵。

从省电效果看，个体 TWT 明显更优，因为它能根据设备的具体流量特征定制周期。一个每小时上报一次温度传感器的传感器，完全可以协商成每小时醒一次；而一个门锁可能需要更长的休眠周期。广播 TWT 做不到这种粒度。

4.2 智能家居设备上的兼容性坑

这是我在实际部署里踩得最深的一块。

WiFi6 刚普及时，一批早期 IoT 设备对 TWT 的支持是"半吊子"——声称支持，但协商完成后无法正确解析唤醒时间表，结果就是该醒的时候没醒，表现成设备频繁离线、指令响应延迟几秒甚至十几秒。这类问题在智能灯泡、开关、传感器上尤其常见。

排查这类问题的思路：

1. 先确认路由器是否默认开启了 TWT。部分型号出厂关闭，部分默认开启
2. 出现"设备时不时掉线但信号强度正常"的现象时，试着关掉 TWT 观察 24 小时
3. 如果关闭后恢复正常，基本可以锁定是 TWT 兼容性问题，考虑单独为 2.4GHz 频段关闭 TWT（很多 IoT 设备只连 2.4G）

顺便说个反向的坑：有些设备会在协商 TWT 之后过度休眠，虽然不掉线，但延迟显著上升。智能门锁这类对响应时间敏感的设备尤其明显——你按了门铃，它那边还在睡。这种情况下把 TWT 关掉，或者把唤醒间隔调短，问题就解决了。

提示：不要把 TWT 当成"开了就一定省电"的功能。它对低占空比的设备收益最大，对一直活跃的设备（比如常开的摄像头）几乎没有意义，反而增加调度复杂度。

4.3 省电收益的量级参考

给个粗略的量级，方便判断值不值得折腾。以典型的低功耗传感器为例，传统省电模式下平均电流在毫安级，TWT 优化到位后可以压到几百微安级，续航差距可能是几个月和几年的区别。

但对手机、笔记本这类设备，TWT 的收益就没那么夸张了。它们的瓶颈往往在屏幕和处理器，无线模块占的功耗比例不高。所以看到"WiFi6 让手机续航提升"这类说法，别太当真——真正受益的是那些只做一件事的小设备。

5. 把纸面能力兑现：家用与小型办公的调参顺序

原理讲完，接下来是我认为最实用的部分。很多人拿到 WiFi6 路由器，把所有高级功能全开，结果体验反而变差。调参这件事有先后顺序，顺序错了会互相干扰。

5.1 先定信道与带宽，再谈其他

带宽和信道是所有无线参数的地基，这一层没定好，上面所有功能都是白搭。

5GHz 频段建议：优先考虑 80MHz。理由很实际——80MHz 在 5GHz 频段上有多个不重叠信道可选，抗干扰能力和速率之间平衡得最好；160MHz 虽然理论速率翻倍，但可用信道极少，一旦撞上雷达检测（DFS 信道）就得整段退避，实测体验经常是"平时很快，偶尔断流几十秒"。除非你能确定周围没人用、且设备离 AP 很近，否则别上 160MHz。

2.4GHz 频段建议：死守 20MHz，只用 1、6、11 三个信道中的一个。2.4G 频段宽度只有 83.5MHz，40MHz 带宽在这个频段就是自找麻烦，不但不会更快，还会把整栋楼的邻居一起拖下水。这个频段现在的主要职责是给 IoT 设备和老旧终端兜底，不需要追求速率。

信道选择：别用自动。自动信道在很多固件里的实现是"开机扫一次"，之后就不管了，邻居换信道它也不会跟着换。手动扫描一次环境，选一个占用最少的信道固定下来，比自动靠谱得多。扫描可以用手机上的无线分析工具，看哪个信道的 AP 数量最少、信号最弱。

5.2 发射功率和漫游阈值，这两个参数经常互相打架

信号强度和漫游是一对矛盾。功率开太大会导致客户端"赖着不走"——明明已经到了信号很差的房间，手机还死死抓着主路由不放，因为主路由的信号"看起来还能用"。功率开太小又会导致覆盖不全。

我的做法是：功率不要拉满，留出漫游的触发空间。具体操作是先把 AP 功率调到中高档位（比如 70% 到 80%），然后在两个节点之间的过渡区域实测信号强度。理想状态是，客户端走到中间位置时，原节点信号掉到 -70dBm 左右，新节点信号升到 -60dBm 以上，这时候客户端才有动力切换。

如果路由器支持设置漫游阈值（有些叫"弱信号剔除"或"漫游引导"），建议把触发值设在 -70dBm 到 -75dBm 之间。设得太激进（比如 -65dBm）会导致设备在边缘区域反复横跳，体验比不漫游还差。

多节点组网时还有一个容易被忽略的点：所有节点的 SSID、密码、加密方式、频段配置必须完全一致，否则客户端会认为是不同的网络，不会主动切换。有些固件支持 802.11k/v/r，这些是辅助漫游的协议，能开就开，但前提是节点之间要有可靠的协调通道。

5.3 用可复现的方法验证改动是否有效

调完参数不做验证，等于白调。我习惯用一套固定的验证流程：

第一轮，单设备近距离测试。设备放在 AP 旁边一米内，跑一次上下行吞吐，记录数值。这一步是为了确认基础能力正常，排除设备本身的问题。

第二轮，多设备并发测试。同时开三到五台设备，一半跑下行大文件，一半跑视频会议或网页浏览，持续五分钟，记录平均时延、最大时延和丢包率。这一步看的是调度能力，比单纯测速有意义得多。

第三轮，移动测试。拿着手机从 AP 旁边走到最远的房间，全程保持 ping 网关，记录丢包和时延跳变位置。这一步能直观反映覆盖和漫游表现。

第四轮，长时间稳定性测试。挂一晚上，第二天看有没有断连记录。很多问题只在长时间运行后暴露，比如某个设备在特定 TWT 周期下偶发失联。

这四轮下来，一轮改动到底有没有用，心里就有数了。别凭感觉说"好像快了点"，那不可靠。

6. 几个高频误判：从现象追到根因的排查链路

最后这部分是纯排错实录。我把遇到过次数最多、也最容易被误判的几种情况整理出来，包括完整的排查路径，方便你照着走一遍。

6.1 协商速率 1200Mbps，实测只有 300Mbps

这是最高频的疑问。先说结论：这个差距是正常的，但要看差多少。

WiFi 的协商速率（PHY Rate）和实际吞吐之间隔着好几层损耗：MAC 层的帧头开销、ACK 确认、帧间隙、信道竞争退避、重传。理想条件下，实测 TCP 吞吐大约是协商速率的 55% 到 70%。1200Mbps 协商对应 660Mbps 到 840Mbps 实测，这才是正常区间。如果只有 300Mbps，那就确实有问题了。

排查顺序建议这样走：

第一步，确认协商速率本身是多少。看路由器的客户端列表，或者系统里的无线连接详情。如果协商速率压根没到 1200Mbps，问题在链路质量或设备能力，不在别处。常见原因包括：设备本身是 1x1（峰值只能到 600Mbps 左右）、带宽被限制在 40MHz、MCS 因为信号质量被降级。

第二步，确认测试方式。用单线程测速还是多线程，差距可能有一倍。单线程 TCP 更容易受时延和窗口大小限制，多线程才能跑出真实带宽。另外测速服务器的距离和负载也会影响结果，换个就近的节点再试。

第三步，确认没有中间环节拖后腿。比如走了中继、走了 Mesh 的无线回程、走了百兆网口。百兆网口跑不出千兆速率，这个道理简单但真的有人踩。还有一种是路由器的 NAT 转发性能不足，跑满带宽时 CPU 打满，表现为速率上不去且时延飙升。

第四步，怀疑干扰。切到 80MHz、换一个干净信道、关掉 160MHz，再测一遍。这一步能排除掉绝大多数环境问题。

6.2 "开了 WiFi6 反而更卡"的几种真实成因

这个现象确实存在，而且原因不止一个。

成因一：旧设备兼容性。一些早期的 802.11ac 设备在遇到 WiFi6 AP 的 HE 前导码时，解析能力不足，会误判为干扰，进而频繁退避。表现是这些旧设备速率骤降、时延抖动。解决办法是在 AP 上为这些设备单独留一个兼容模式，或者把 2.4G 频段保持在较保守的配置上。

成因二：OFDMA 与 MU-MIMO 的实现缺陷。前面提过，早期固件在这两个功能的调度实现上有问题，开启后空口效率反而下降。判断方法是逐项关闭做对比测试，哪项关了变好，就锁定是哪项的问题，然后去找固件更新。

成因三：功率与信道设置冲突。有些人为了"信号更强"把功率拉满，结果 AP 之间互相干扰加剧，客户端也更不愿意漫游。这种情况把功率降下来，体验往往立刻改善。

成因四：频段引导（Band Steering）过于激进。为了让设备尽量连 5G，有些固件会把设备从 2.4G 强行踢下线，导致设备反复重连。如果发现设备连接日志里频繁出现断开重连，先去把这个功能的激进程度调低。

排查这类"开了更卡"的问题，我的一般原则是：先把所有 WiFi6 新特性关掉，回到一个已知稳定的基线，然后一次只开一项，每次开完观察至少半小时。这样能精确定位到是哪一功能惹的祸。一次性全开再一点点关，很容易因为观察窗口不够长而误判。

6.3 智能家居设备成批掉线，但手机一切正常

这个组合现象指向性很强。手机正常说明射频和基础连接没问题，成批的 IoT 设备掉线，基本锁定在"新特性兼容性"上。

排查路径按顺序走：

先看这些设备连的是哪个频段。绝大多数 IoT 设备只支持 2.4GHz，如果它们连的是 2.4G 而手机在 5G，那问题范围就缩小到 2.4G 的配置上。

然后检查这几个开关：TWT、OFDMA、WPA3 加密模式、802.11ax 模式（有些固件允许关掉 HE 只用 VHT）。其中 WPA3 是最容易被忽略的一项——WiFi6 认证要求支持 WPA3，但大量存量 IoT 设备只支持 WPA2，在 WPA3/WPA2 混合模式下部分设备的四次握手会失败，表现就是连不上或者连上后立刻断开。

我的常规处理方式是：2.4GHz 频段保持 WPA2-PSK（AES），关掉 TWT，保留 OFDMA，5GHz 频段可以放开用 WPA3 混合模式。这个配置在绝大多数场景下能兼顾兼容性和性能。

如果调完之后还有个别设备掉线，那就要单独看了。抓一下那个设备的连接日志，看看是认证阶段失败还是关联后超时，两者的排查方向完全不同。认证失败回去看加密配置，关联后超时基本是省电机制或信标间隔的问题。

6.4 用 Wireshark 抓空口包时的几个实用过滤条件

真到了需要抓包定位的阶段，有几个过滤表达式能省大量时间：

# 只看管理帧中的信标，观察 HE 能力字段 wlan.fc.type_subtype == 0x0008 # 筛选触发帧，看上行调度是否正常发生 wlan.fc.type_subtype == 0x0024 # 只看本 BSS 的流量，排除邻居干扰 wlan.bssid == xx:xx:xx:xx:xx:xx # 筛选重传帧，判断空口质量 wlan.fc.retry == 1

抓包的关键是网卡要支持监听模式，且能正确解析 802.11ax 的 HE 相关字段。老网卡抓到的包会缺字段，看到的信息不完整，容易得出错误结论。这一步别省，工具不对等于白干。

另外一个经验：抓包时长别太短。TWT 的唤醒周期可能是几十秒甚至几分钟，抓个十秒八秒什么都看不到。想让 TWT 的问题暴露出来，至少抓够几个完整周期。

调完一圈参数之后我最深的体会是，WiFi6 的这些东西没有一个是"开了就变快"的魔法开关，它们都是针对特定瓶颈的解法。OFDMA 治的是多设备排队，BSS Coloring 治的是邻居干扰，MU-MIMO 治的是空间复用不足，TWT 治的是电池续航。搞清楚自己环境里真正的瓶颈在哪，再去开对应的那一项，才不会陷入"全开一遍然后全部关掉"的循环里。至于具体的取舍，每家的电磁环境、设备构成、房屋结构都不一样，别人调好的参数搬过来未必管用，还是得自己按上面那套流程跑一遍，数据说话最靠谱。