多数生产环境应选bond mode=4（802.3ad/lacp），因其在稳定性、交换机兼容性及内核支持成熟度上无明显短板；team仅在需自定义哈希策略、动态重配或聚合超4块网卡时才适用，否则增加运维复杂度。
直接说结论：多数生产环境该选 bond mode=4（802.3ad/LACP），不是因为它“高级”，而是它在稳定性、交换机兼容性、内核支持成熟度上没有明显短板；team 仅在需要自定义哈希策略、动态重配或聚合超 4 块网卡时才值得引入，否则徒增运维复杂度。
为什么 bond0 启不来？先查这三件事
90% 的绑定失败不是配置写错，而是底层没就绪：
-
lsmod | grep bonding没输出 → 执行modprobe bonding，并往/etc/modules追加bonding确保开机加载 -
ip link show里eth0/eth1状态是DOWN或NO-CARRIER→ 先手动ip link set eth0 up，确认物理链路连通 - NetworkManager 正在接管网卡 →
systemctl stop NetworkManager && systemctl disable NetworkManager，并在所有网卡配置文件中加NM_CONTROLLED=no
别跳过这些，cat /proc/net/bonding/bond0 报 “No such file or directory” 就说明 bond0 接口根本没创建成功，此时调参数毫无意义。
bond mode=4 配置后流量不均衡？重点看 xmit_hash_policy 和交换机
mode=4 理论上能负载分担，但默认 xmit_hash_policy=layer2 只按 MAC 地址哈希 —— 同一服务器对同一目标 IP 的所有连接永远走同一条链路，看起来就是“只有一张卡在干活”。
- 改哈希策略：在
BONDING_OPTS中加入xmit_hash_policy=layer3+4，让它按源/目的 IP + 端口组合计算哈希值 - 交换机必须配成 LACP active 模式（不能是 passive），且所有参与端口加入同一个 LAG 组
- 检查协商结果：
cat /proc/net/bonding/bond0中每块 slave 的Port State应为0x3f（表示 LACP 成功握手），若为0x1，说明根本没协商上
注意：改完 xmit_hash_policy 不需要重启网络服务，但必须先 ip link set bond0 down 再 up 才会生效。
team loadbalance 比 bond mode=4 慢？这不是 bug，是架构代价
team 的负载均衡能力确实更灵活（比如支持 tx_hash 组合 ["eth", "ipv4", "ipv6"]），但它把链路状态检测、哈希决策等逻辑全放在用户态 teamd 进程里处理，带来三个可测量的开销：
- 故障切换慢约 150ms：
team切换依赖teamd收到 Netlink 事件再通知内核，而bond在内核态直接响应 - CPU 占用高：满载时
team占用率约 12%，bond仅 5% —— 对 CPU 敏感的服务（如 DPDK、高频交易）需谨慎 - 配置不向后兼容：nmcli 创建的
team连接无法用传统 ifcfg 文件管理，容易和旧运维脚本冲突
如果你只是想让两块万兆卡跑满 20Gbps，bond mode=4 更稳；只有当你需要基于应用层特征（比如 HTTP Host 头）做分流，才该考虑 team 上层扩展。
别忽略 MTU 和双工模式的一致性
哪怕 bond 和 team 都配对了，只要其中一块网卡的 MTU 是 1500、另一块是 9000，或者一块是全双工、另一块是半双工，绑定接口就会频繁抖动甚至中断。
- 统一设置：
ethtool -s eth0 speed 10000 duplex full autoneg off mtu 1500，对所有 slave 网卡执行一遍 - 验证：
ethtool eth0 | grep -E "(Speed|Duplex|MTU)"，确保输出完全一致 - 绑定接口的 MTU 必须 ≤ 所有 slave 的最小 MTU，否则发包会失败
这个细节常被跳过，但它是跨厂商设备（比如 Cisco 交换机 + Intel 网卡 + Mellanox 网卡混用）中最隐蔽的单点故障源。
