推荐使用官方 docker/docker Go SDK 调用 Docker API，需配置 Unix socket 或安全 TLS 的 TCP 连接，设置 context 超时，显式端口映射并轮询健康接口判断容器就绪，用 map 管理多容器依赖与清理，避免直接 exec docker-compose。
Go 服务如何安全调用 Docker 容器 API
直接用 net/http 手动拼 Docker REST API 请求容易出错，推荐使用官方维护的 docker/docker Go SDK（即 github.com/docker/docker/api/types 等包），它封装了认证、超时、连接复用和错误分类。
- Docker daemon 默认只监听 Unix socket（
/var/run/docker.sock），不是 HTTP 端口；本地开发若改用 TCP（如tcp://localhost:2375），必须显式开启 Docker 的DOCKER_HOST并确保 TLS 配置正确，否则会报connection refused或x509: certificate signed by unknown authority - 初始化 client 时务必设置上下文超时：
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) defer cancel() cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation(), client.WithTimeout(10*time.Second)) if err != nil { log.Fatal(err) } - 不要在长生命周期服务中复用未设超时的全局
*client.Client，HTTP 连接可能卡死或堆积；建议按操作粒度创建带 context 的调用，或用client.WithHTTPClient注入带连接池和 timeout 的自定义*http.Client
容器启动时如何注入配置并等待就绪
Go 程序启动容器后不能立刻发请求，得等容器内服务真正监听端口。SDK 本身不提供“等待就绪”逻辑，需自行实现健康检查。
- 用
ContainerCreate启动时，通过HostConfig.PortBindings显式映射端口，避免随机端口导致后续调用不可知；绑定到"127.0.0.1:8080"而非"0.0.0.0:8080"更安全 - 启动后调用
ContainerStart，再轮询检查：用http.Get访问容器映射的本地端点（如http://127.0.0.1:8080/health），配合time.Sleep和最大重试次数；不要依赖ContainerInspect返回的State.Status == "running"，那仅代表容器进程 running，不代表应用 ready - 若容器内服务无健康接口，可改用
exec.Run执行ss -tln | grep :8080类命令判断端口监听状态，但需确保容器有net-tools或busybox
如何管理多个容器间的依赖顺序与清理
Go 程序常需启动一组协同容器（如 db + api + cache），但 Docker SDK 不提供原生依赖编排——这不属于它的职责范围，应交由更高层逻辑控制。
【做什么】纯 Windows 只读存储分析 — 扫描 12+ 组目标（含 Installer/ProgramData/回收站）→ 三灯分级(🟢可自动清/🟡需判断/🔴建议卸载)→ 交互式 HTML 报告 + 本地服务一键删。 【何时用】用户抱怨磁盘空间不足、要求清理/分析/查看空间占用、想知道什么东西吃硬盘。 【触发词】磁盘满了/C盘满了/D盘满了/空间不够/清理空间/清理磁盘/清理C盘/占空间/ 存储分析/磁盘分析/看一下存储/电脑空间/storage analysis/disk cleanup/清缓存/
- 用 map 记录容器 ID 与角色名的映射（如
map[string]string{"postgres": "abc123...", "redis": "def456..."}），避免硬编码 ID；停止时按反向顺序调用ContainerStop+ContainerRemove - 为每个容器设置
HostConfig.AutoRemove: true可省去手动 remove，但仅适用于一次性任务；长期服务必须显式 stop/remove，否则docker ps -a积累大量 exited 容器 - 务必用
defer或runtime.SetFinalizer（慎用）注册清理函数，并捕获 panic；更可靠的是用os.Interrupt监听 SIGINT/SIGTERM，在退出前批量 stop/remove
为什么不用 docker-compose up --no-start 在 Go 中调用
看似简单，实则破坏可控性。Go 进程直接 exec docker-compose 命令会丢失容器生命周期管理权，无法获取容器 ID、无法细粒度控制重启策略、无法感知内部网络变化，且 compose 文件路径、环境变量、profile 开关都易引发隐式行为。
立即学习“go语言免费学习笔记（深入）”；
- Compose 是面向开发/运维的编排工具，不是 Go 应用的运行时依赖管理器；它的
up启动是黑盒，Go 程序无法 hook 容器启动完成事件 - 若真需复用 compose 定义，可用
github.com/compose-spec/compose-go解析 YAML，提取 service 配置后转成 SDK 的container.Config和host.Config结构体，再调用 SDK 创建——这才是 Go 原生可控的方式 - 跨平台兼容性差：Windows 上
docker-compose.exe路径、参数格式、输出解析都不同；而 SDK 是纯 Go 实现，一次编译全平台可用
最易被忽略的一点：Docker socket 文件权限。Linux 下 /var/run/docker.sock 属于 docker 组，Go 程序若以非 root 或非 docker 组用户运行（如容器内运行），会直接报 permission denied。要么把运行用户加进 docker 组，要么挂载 socket 时用 mode=666（不推荐生产），要么改用 TCP + TLS 方式通信。
