Host模式零网络栈开销、延迟低至15μs、吞吐达9.8Gbps，但无网络隔离，共享宿主机网络命名空间、端口及iptables规则；macvlan则为容器分配独立MAC和同网段IP，延迟22–25μs、吞吐8.5–9.2Gbps，保留命名空间隔离且支持物理网络直连与跨主机通信。
Host 网络：零网络栈开销，但牺牲隔离性
host 模式让容器直接复用宿主机的网络命名空间，不创建 veth pair、不经过 docker0 网桥、不触发 iptables nat 规则。这意味着网络路径最短——从应用 socket 直达物理网卡，延迟可低至 15μs，吞吐接近宿主机原生水平（实测达 9.8 gbps）。适合对延迟极度敏感的场景，比如高频交易服务、实时音视频转码、或需要绑定特定 host 端口（如 80/443）且不做端口映射的 web 前端。
但它也带来明显限制：
- 容器无法使用 端口映射（-p 参数被忽略），多个容器不能同时监听同一端口
- 所有容器共享宿主机的 /etc/hosts、iptables 规则、路由表，故障或配置冲突会互相影响
- 不支持跨主机通信，也不适用于多租户或安全合规要求高的环境
Macvlan 网络：独立 IP 与 MAC，直连物理二层
Macvlan 为每个容器分配一个真实的 MAC 地址，并将其虚拟接口直接挂载到指定物理网卡（如 eth0）上。容器获得与宿主机同网段的独立 IP（例如 192.168.1.101），在局域网中表现为一台普通物理设备。它绕过了 docker0 和 NAT，仅保留一层轻量级虚拟接口封装，延迟约 22–25μs，吞吐可达 8.5–9.2 Gbps。
这种模式的关键优势在于：
- 容器拥有完整网络身份，可被 DHCP 分配地址、被交换机 ACL 管理、被监控系统直接发现
- 支持跨容器、跨主机（只要物理网络互通）、甚至跨 VLAN（配合子接口）通信
- 保留了网络命名空间隔离，避免 host 模式下的全局污染风险
性能差异的核心来源
差距主要来自三处底层机制：
- veth pair 开销：bridge 模式必经，macvlan 和 host 都跳过
- NAT 与 conntrack 处理：bridge 默认启用，host 完全规避，macvlan 通常关闭（除非显式配置 SNAT）
- iptables 规则链遍历：bridge 模式需经过 INPUT/FORWARD/DOCKER 链，host 模式走 INPUT/OUTPUT，macvlan 流量默认只进 OUTPUT 或 FORWARD（取决于方向），规则更少
选型建议：按场景而非参数决定
选 host 还是 macvlan，不能只看“谁更快”，而要看你的约束条件：
- 如果部署单节点、无多租户需求、服务端口固定且唯一（如 Prometheus exporter 占用 9090），host 是最简最优解
- 如果需要容器在物理网络中“被看见”（如工业 IoT 设备模拟、PLC 通信、传统防火墙策略依赖 MAC/IP 绑定），必须用 macvlan
- 如果未来可能扩展到多主机，又希望保持单机高性能，macvlan 更易平滑演进（只需确保各节点物理网络二层互通）
- 如果容器需访问宿主机 localhost 服务（如本地数据库），host 模式下直接用 127.0.0.1；macvlan 下需改用宿主机真实 IP，这点需在应用配置中明确
