hAP be³ 开卖这两个月，B 站的测试区几乎变成了 ROS 玩家的集体会诊室。7 月 11 日开机测试，2900 多播放、28 条评论；7 月 17 日二测专门关掉 FastTrack 再打一遍带宽；7 月 25 日，hAP be³ 和 79 美元的 hAP be lite 直接同场对比 WiFi 7。哔哩哔哩到 8 月 1 日，做测试的 UP 主 Athlon_sds 在转发官方宣传视频时顺手补了一句让等等党沉默、让已购党心里一沉的消息：7 月 28 日发布的 RouterOS 7.24rc3 修复了 WiFi 7 MLO 聚合的一些问题，但 ether2-ether4 的 L2 Hardware Offload，还是不支持。哔哩哔哩
评论区里能直接看出这个圈层此刻在纠结什么：“还好没等这玩意，买了 5009”、“拔草了，原本 1200+ 还想买的”、“没有 VLAN 卸载那不就 G 了”、“交换芯片到 CPU 的带宽只有 2.5Gbps，一个口跑满 2.5G，其他口可能就饿死了”。哔哩哔哩一台网口标称 2.5G、三频 WiFi 7 的路由，为什么会被自己最核心的用户群反复追问"到底能不能跑满"？
这个问题没法在"参数表"层面回答。MikroTik 最容易被新手误读的地方在于：同一块板子上的流量，走的根本不是同一条路。搞清楚 RouterOS 里三层互相独立的加速机制——L2 硬件卸载、交换芯片上行口、FastTrack——你就不只是看懂 hAP be³，而是看懂 MikroTik 全系设备"口相同、性能不等"的底层逻辑。
第一层：L2 Hardware Offload——"不经过 CPU"才是真快
RouterOS 里的端口大致分两类：直接焊在 CPU 上的，和挂在交换芯片上的。同一颗交换芯片上的端口互相转发流量时，可以把转发表下给芯片自己处理，数据包完全不进 CPU——这就是 L2 Hardware Offload。效果是粗暴的：芯片线速转发，CPU 占用几乎为零。
而一旦某个端口不在芯片上（或者你把它从 bridge 里挪到了 CPU 侧），这条流量就要乖乖进 CPU 走软件转发。软件转发的上限，就是你那颗四核处理器的算力上限——这正是"千兆都不到"和"线速跑满"的分水岭。
hAP be³ 被点名的问题是：ether2-ether4 这三个 2.5G 口至今没拿到 L2 卸载支持。三台设备之间互拷文件，包全部要过 CPU。UP 主两轮开机测试测的就是这个场景：第一轮开着 FastTrack 测 NAT 带宽，第二轮特意把 FastTrack 关掉对比，顺带记录 CPU 温度和容器内 speedtest——本质上是在把"哪条路加速、哪条路裸奔"拆开给观众看。哔哩哔哩
第二层：芯片到 CPU 的上行带宽——藏在参数表后面的独木桥
就算端口都在交换芯片上、卸载也开了，还有第二道闸：芯片汇流到 CPU 的那条上行链路。评论区已经有人在拆这个口：“交换芯片到 CPU 的带宽只有 2.5Gbps”——意味着四个 2.5G 口里，凡是要出芯片的流量（拨号 NAT、进容器、跨 VLAN 路由）全都挤一根独木桥，一个口跑满，其他口就饿着。哔哩哔哩还有人对着拆机能看到的交换芯片（评论区提到的 QCA8386）和带 PPPoE offload 的 CPU 平台直接开讨论——这些是观众基于视频画面的信息，不是官方口径，但讨论的方向全部戳在同一个点上：MikroTik 的便宜，很大程度上省在端口和 CPU 之间的互联上。
这层逻辑同样解释了为什么有人"继续用 5009"不焦虑。B 站那条 1.5 万播放的《用 5009 打通万兆内外网》长期霸着入门万兆的咨询区（200 收藏、83 评论），是因为它是社区验证得最厚的一条万兆家庭路线：路由、光口、交换口的分工在教程里是现成的，不用自己拿真金白银试错。哔哩哔哩老机型端口规格看似寒酸，但玩法成熟、坑位已被踩平；新机型端口豪华，但流量全在一条总线上开会——这就是"不是买新不买旧"在 ROS 圈不总成立的原因。
第三层：FastTrack——CPU 侧的"免检通道"，也是配置最容易踩坏的
第三层和交换芯片无关，是 RouterOS 的软件机制：FastTrack。对已建立的 NAT 连接，RouterOS 会记住处理结果，后续数据包跳过防火墙、filter、mangle 的逐包匹配，CPU 占用大幅下降。知乎上早年就有 ROS 玩家写过总结：FastTrack 能极大降低 CPU 使用率、提升带宽，但代价是不能对这些流量做 mangle 策略和流控——一旦你加了分流、QoS、连接数限制之类的规则命中了这条流，免检通道作废，包重新回到全量处理的路径上。知乎
这就是为什么"千兆宽带 PPPoE 拨号"这类最常见需求，反而是 hAP be³、hAP be lite 最不用担心 FastTrack 之外还有瓶颈的场景：流量路径是 WAN→CPU 做 NAT→LAN，FastTrack 恰好管这段；真正的坑是后面有人为了去广告、分流、游戏加速加了一堆 mangle，把免检打回人工，才发现四核 CPU 开始冒烟。
三层拼起来，才能看懂"跑不满"系列
把这三层套回这波讨论，很多"跑不满"就不再是质量问题而是结构问题：
hAP be lite 标称 BE3600 实测千兆都难跑满：低价位 CPU + 无卸载冗余，无线和 NAT 两头都在吃 CPU，属于第一层、第三层同时没有余量。
hAP be³ 被质疑"不及预期"：WiFi 侧要等 7.24 后续版本把 MLO 修完，有线侧 ether2-ether4 的卸载没到位，属于第一层的结构性缺口，短期改配置改不出来。
同一批 VLAN 系列视频里反复强调的事：v6.41 之前的老式 bridge+VLAN 配置方式天生不带硬件卸载，只有走 vlan-filtering 的新方式才能把 L2 offload 保住。哔哩哔哩很多"我做了 VLAN 之后内网变慢"的案例，是配置写法把第一层亲手关掉了。
7.23 更新里"VRF 支持 Hardware Offload"还特意标注仅限 CRS800 系列——官方自己也在按芯片型号划卸载的边界。哔哩哔哩
一个容易被忽略的信号：MikroTik 官方多年前讲的 Bridge L2 Hardware-offload 教程，今年 8 月被人重新搬运到 B 站，标签"内容比较硬核"，收藏数直接压过点赞数。哔哩哔哩有人收藏官方老教程当新知识学，本身就说明这层认知在中文社区长期缺位。
不同人现在该怎么办
按三层结构对号入座，比看任何单条评测都有用：
只拨千兆/两千兆 PPPoE、主要用 WiFi 的家庭用户：FastTrack 覆盖你的主路径，be lite、be³ 的"跑不满"讨论跟你关系不大——但别乱加 mangle，加了流控再回头看 CPU 占用。这类人最该做的是把配置做减法。
NAS 大量内网互拷、要做万兆/2.5G 内网的用户：你最依赖的就是第一层卸载和第二层上行带宽，hAP be³ 这三个没卸载的 2.5G 口恰好卡在你的主场景上。要么等 7.24 系版本放出口径，要么按评论区那句大实话——“继续用 5009”，或者把交换职责交给 CRS 系机型，让路由只做路由。
IoT 隔离、多 VLAN 玩家：先检查你的 VLAN 是不是用 vlan-filtering 方式写的，老写法等于自愿放弃卸载。这是零成本改动，收益立竿见影。哔哩哔哩
已经买了的：三件事现在就做——① 同芯片口之间跑一次 bandwidth-test 并开着 /system resource 看 CPU，接近打满说明你在软件转发，先查 bridge 和 VLAN 写法；② NAT 场景开/关 FastTrack 各测一轮，搞清楚自己带宽的天花板是软件 NAT 还是端口结构；③ 把 RouterOS 升级到 7.24 系后持续盯 changelog——MLO 修复在 rc3 已经出现，ether2-4 卸载会不会跟进、PPPoE 硬件 offload 会不会开放给新平台（评论区的期待，非官方承诺），是接下来两个版本最值得观察的两个信号。
MikroTik 的性价比从来不是白给的：它把"哪些口之间免费快、哪些流量要收 CPU 的钱"做成了每台机器的私有谜题。参数表告诉你有几个 2.5G 口，只有这三层机制告诉你，你的流量从哪个口进、还能不能活着快起来。
