go二进制文件在alpine镜像中无法运行的根本原因是默认依赖glibc而alpine使用musl libc，解决关键是显式设置cgo_enabled=0实现静态链接或在alpine中安装musl-dev并保持cgo_enabled=1。
Go 二进制文件天然适合容器化，但直接扔进 Docker 容易踩内存泄漏、HTTPS 请求失败、日志丢失、信号处理异常等坑——关键不在“能不能跑”，而在“能不能稳”。
CGO_ENABLED=0 和 GOOS=linux 必须显式设置
Alpine 镜像默认不带 glibc，而 CGO 启用时会动态链接系统库；不关它，go build 出来的二进制在 alpine:latest 或 scratch 里直接报 no such file or directory（实际是找不到 libc.so）。
-
CGO_ENABLED=0强制纯静态编译，所有依赖打包进二进制，彻底规避 libc 问题 -
GOOS=linux是必须的：即使你在 macOS 或 Windows 上构建，目标容器一定是 Linux 内核，不指定会导致运行时 panic - 如果项目用了 SQLite、OpenSSL 等需 CGO 的库，不能简单设为 0，得换镜像（如
gcr.io/distroless/cc）或改用纯 Go 实现（如mattn/go-sqlite3的sqlite3_no_builtintag）
Dockerfile 多阶段构建中 COPY --from=builder 路径要严格匹配
常见错误是 COPY --from=builder /app/main . 失败，提示 “file not found in builder stage”，本质是构建阶段的工作目录或输出路径和 COPY 源路径对不上。
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 确保
RUN go build -o /app/main .中的输出路径（这里是/app/main）和COPY --from=builder的源路径完全一致 - 别写成
COPY --from=builder ./main .——.在多阶段里指当前 stage 的 WORKDIR，不是 builder 的 - 建议统一用绝对路径：
RUN go build -o /usr/local/bin/app .，然后COPY --from=builder /usr/local/bin/app .
Alpine 镜像里 HTTPS 请求失败：缺 ca-certificates
Go 程序发起 HTTPS 请求（比如调第三方 API、连 PostgreSQL、访问云服务）时，如果容器里没有证书信任链，会报 x509: certificate signed by unknown authority，哪怕代码里没显式加载证书。
-
alpine:latest默认不含根证书，必须显式安装：RUN apk --no-cache add ca-certificates - 装完后建议加一句
RUN update-ca-certificates（部分 Alpine 版本需要） - 若用
scratch镜像，不能装 apk，得把证书文件从 builder 阶段 COPY 过来：COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
容器内 SIGTERM 不触发 graceful shutdown
Go 进程收到 docker stop 发的 SIGTERM 后立刻退出，导致 HTTP 连接被粗暴中断、数据库事务未提交、临时文件未清理。
- 必须手动监听信号：
signal.Notify(sigChan, syscall.SIGTERM, syscall.SIGINT) - 收到信号后，调用
srv.Shutdown()（HTTP server）或自定义清理逻辑，再os.Exit(0) - 别依赖
defer：它只在函数返回时执行，SIGTERM 不会自动触发 defer - Dockerfile 里避免用
ENTRYPOINT ["sh", "-c", "./main"]包一层 shell —— 会导致 SIGTERM 发不到 Go 进程，而发给 sh，Go 变成孤儿进程
最常被忽略的是信号传递和证书链——它们不报错到构建阶段，也不阻断启动，但会在压测或上线后突然暴露，且现象分散（超时、连接拒绝、日志截断），排查成本远高于写两行修复代码。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
