网桥（Bridge）在局域网里常被用来连接两个网段，比如把办公室的有线网络和会议室的无线AP桥接起来。很多人一听到‘桥’字，就联想到‘中转’‘转发’，下意识觉得：多一道环节，肯定拖慢速度——延迟是不是很高？
延迟到底来自哪儿？
网桥工作在数据链路层（OSI第二层），它不解析IP包，只看MAC地址。收到帧后，查表决定往哪端口转发。这个过程非常轻量：没有NAT转换、没有路由计算、不改IP头、甚至不校验上层内容。主流硬件网桥（比如企业级交换机的桥接模式或OpenWrt软路由启用bridge接口）转发延迟通常在几微秒到几十微秒之间。
举个例子：你用两台电脑直连同一台支持桥接的千兆交换机，A ping B，平均延迟0.2ms；如果中间插一个纯二层网桥（如一台配置为bridge模式的树莓派），再测一次，延迟变成0.23ms——多出来的0.03ms，就是桥接引入的真实开销。
什么情况下延迟会‘明显变高’？
不是网桥本身慢，而是这些场景容易让人误以为‘网桥很卡’：
用了软件网桥+低性能设备：比如在老旧笔记本上跑Windows自带的“网络桥接”，CPU忙不过来，转发排队，延迟跳到10ms以上，还伴随丢包；
启用了STP生成树协议：默认等待30秒才让端口进入转发状态，这不是传输延迟，是启动延迟，但新手常混淆；
跨网段桥接+物理距离远：比如用无线网桥拉500米远的监控点，真正拖慢的是无线信道干扰和重传，不是桥接逻辑本身。
动手验证很简单
在Linux下用tcpreplay或ping加tcpdump抓包比对时间戳，就能看出进出网桥的帧间隔。例如：
sudo tcpdump -i br0 -nn -ttt icmp and host 192.168.1.100观察同一ICMP请求帧在网桥入口和出口的时间差，多数情况＜10μs。
所以别一看到‘网桥’就皱眉。只要设备靠谱、配置干净，它的延迟几乎可以忽略不计——比起Wi-Fi信号穿墙掉30ms，网桥那零点零几毫秒，真不算事儿。