go不直接管理docker容器网络，仅能通过docker api或系统命令间接操作；自定义网络需用netlink库直接配置内核网络对象，但复杂操作应交由docker sdk完成。
Go 语言本身不直接管理 Docker 容器网络，真正起作用的是 dockerd 的内置网络驱动（如 bridge、overlay）和 Linux 内核的网络栈；Go 只能通过调用 Docker API 或执行 ip、iptables、nsenter 等命令间接操作。硬要在 Go 里“实现容器网络管理”，本质是封装对底层网络设施的控制逻辑。
用 github.com/docker/docker/api/types/network 创建/删除 Docker 网络
Docker SDK for Go 提供了标准接口，但仅限于调用 dockerd 已支持的网络功能，无法自定义数据面行为（比如实现一个新驱动）。创建网络时，Driver 字段决定底层行为："bridge" 会自动配置 docker0 和 veth 对，"host" 则跳过网络命名空间隔离。
-
IPAM.Config必须显式指定Subnet，否则默认使用172.17.0.0/16，容易与已有网段冲突 - 若指定
EnableIPv6: true，需确保dockerd启动时带--ipv6 --fixed-cidr-v6=...参数，否则创建失败并报错"IPv6 enabled, but no IPv6 subnet configured" - 删除网络前必须确保无容器连接，否则返回
"network xxx has active endpoints"，需先调用ContainerList+NetworkDisconnect
networkCreateResp, err := cli.NetworkCreate(ctx, "mynet", types.NetworkCreate{
Driver: "bridge",
IPAM: &network.IPAM{
Config: []network.IPAMConfig{{
Subnet: "192.168.100.0/24",
}},
},
})
用 netlink 库在 Go 中直接配置 veth、namespace 和路由
绕过 Docker API，直接操作内核网络对象，适用于定制化网络方案（如 CNI 插件）。核心依赖是 github.com/vishvananda/netlink 和 github.com/vishvananda/netns，它们封装了 netlink socket 调用。
- veth pair 创建后，必须手动将一端移入目标 network namespace，否则无法生效；常用方式是用
netns.GetFromPath("/proc/<pid>/ns/net")</pid>获取 ns 句柄，再调用netlink.LinkSetNsFd() - 在容器 netns 内配置 IP 和路由，需用
netns.Set()切换上下文，否则所有netlink操作仍在 host namespace 执行 - 忘记执行
netlink.LinkSetUp()会导致接口处于DOWN状态，ping 不通 —— 这是最常被忽略的一步
link := &netlink.Veth{
Name: "veth0",
PeerName: "veth1",
}
if err := netlink.LinkAdd(link); err != nil {
return err
}
// link.Attrs().Index 是 veth0 的 ifindex
// link.PeerIndex 是 veth1 的 ifindex
处理容器启动后网络就绪的竞态问题
容器进程启动快于网络配置完成（尤其在自定义 CNI 流程中），导致应用读取 /etc/resolv.conf 失败或连不上 DNS。不能依赖固定 sleep，而应检测关键信号：
立即学习“go语言免费学习笔记（深入）”；
- 检查
/sys/class/net/eth0/carrier是否为1（表示链路已 up） - 用
netlink.AddrList()查询eth0是否已分配 IPv4 地址，避免只看接口状态 - DNS 就绪需额外验证：在容器 netns 内执行
dig +short google.com @8.8.8.8，超时则重试
为什么不要在 Go 里重复实现 docker network connect 的逻辑
看似只是“把容器加进网络”，实际涉及多步原子操作：查找容器 netns、创建 veth pair、移动 peer 端、设置 IP、添加 iptables 规则、更新 dockerd 内部状态。SDK 调用 NetworkConnect 是唯一安全方式；自己手撸容易漏掉 ebtables 防护规则或 docker0 的 MAC 地址学习刷新，导致跨容器通信异常或 ARP 泛洪。
真正需要 Go 控制的，是网络策略下发（如用 gobgp 设置 BGP）、IPAM 分配决策（对接 Consul 或 Etcd），或者调试时进入容器 netns 抓包 —— 这些才是 Go 发挥作用的合理边界。
