家里或小办公室用软路由搭双WAN，常会遇到主线路突然断掉、视频会议卡顿、下载中断的尴尬。这时候有人会想到搞个网桥热备——主网桥挂了自动切到备用网桥，听起来很稳。但问题来了：这玩意儿真不拖慢网速？
热备不是白干活，它要抢时间
网桥热备（比如 Linux 的 bond 模式 active-backup 或 keepalived + bridge 配合）本质是靠状态检测+MAC漂移实现的。主桥出问题后，备用桥得立刻顶上，但这个“立刻”是有延迟的——少则几十毫秒，多则2~3秒。这不是性能瓶颈，而是切换过程本身带来的短暂中断。你正在打游戏时切一次，可能就掉线一两秒；上传大文件时切一次，TCP重传机制会拉长总耗时。
CPU和内存占用不低，尤其在高并发下
热备不是光配个配置就完事。keepalived 要轮询检测对端状态，bridge 还要维护 FDB（转发数据库）表项同步，再加上 ARP 探测、 gratuitous ARP 广播……这些活全靠 CPU 算。我拿一台 J4125 小主机实测：启用双网桥热备后，空闲 CPU 占用从 2% 升到 8%~12%，跑满 1000 个并发连接时，CPU 软中断（softirq）飙升明显，吞吐比单桥下降约 7%～9%（iperf3 测得）。
别忽略 MAC 地址学习抖动
交换机和终端设备都是靠 MAC 表记“谁在哪个口”。主桥切到备桥后，同一台设备的 MAC 地址瞬间出现在另一个物理口上，交换机会刷新表项，部分老型号交换机甚至会泛洪广播几秒钟。这时局域网内其他设备可能出现短暂 ping 不通、Samba 共享响应迟缓的现象。这不是丢包，是网络“懵了一下”。
怎么压低影响？几个实操建议
如果你确实需要热备，又不想被拖累：
- 把 keepalived 的检查间隔设成
interval 1（秒），但别太激进，fall 2和rise 2保持平衡，避免误切； - 关掉不必要的 bridge 参数，比如禁用 STP：
echo 0 > /sys/class/net/br0/bridge/stp - 在支持的网卡上启用 offload 功能：
ethtool -K eth0 tx on rx on tso on gso on - 如果只是防单线故障，优先考虑 PPPoE 多拨+策略路由，比网桥热备更轻量。
说到底，热备不是免费午餐。它换来的可靠性，代价是微小但真实存在的资源开销和切换抖动。要不要上，得看你手里的设备性能、网络负载强度，还有你能容忍几秒的“失联”。