在 FROM scratch 构建的极简镜像中，Go 二进制无法通过 fork/exec 启动另一进程，根本原因是动态链接导致依赖缺失；解决方案是强制静态编译所有二进制，确保不依赖 glibc 或其他共享库。
在 `from scratch` 构建的极简镜像中，go 二进制无法通过 `fork/exec` 启动另一进程，根本原因是动态链接导致依赖缺失；解决方案是强制静态编译所有二进制，确保不依赖 glibc 或其他共享库。
scratch 是 Docker 中最精简的基础镜像——它完全为空，不含操作系统、shell、动态链接器（如 /lib64/ld-linux-x86-64.so.2），也不含任何共享库（如 libc.so.6）。当你使用 go build 默认方式编译 Go 程序时，若启用了 cgo（即 CGO_ENABLED=1，默认开启），Go 会将部分系统调用（如 DNS 解析、getpwuid、exec.LookPath 等）委托给 libc，生成动态链接的可执行文件。这类二进制在 scratch 容器中运行时，内核虽能加载 ELF 文件，但动态链接器缺失，导致 execve() 系统调用失败——错误信息 "fork/exec /opt/my-app/second: no such file or directory" 实际是误导性的：文件存在，但其依赖的动态链接器或共享库找不到，Linux 内核返回 ENOENT（而非更准确的 ENOEXEC 或 EACCES），这是常见陷阱。
✅ 正确做法：禁用 cgo 并强制静态链接
在构建两个 Go 二进制（first 和 second）时，统一使用以下命令：
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o bin/first ./cmd/first CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o bin/second ./cmd/second
-
CGO_ENABLED=0：彻底禁用 cgo，避免任何 libc 依赖； -
-a：强制重新编译所有依赖包（含标准库中的 net、os/user 等可能隐式调用 cgo 的模块）； -
-ldflags '-extldflags "-static"'：指示 Go 链接器使用静态链接模式（尤其对跨平台构建更健壮）。
? 验证是否真正静态：构建后执行 file bin/first 和 ldd bin/second：
- ✅ 正确输出应为：
bin/first: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, ... - ✅
ldd bin/second应提示not a dynamic executable； - ❌ 若显示
dynamically linked或列出libc.so.6，说明仍存在动态依赖，需检查构建环境是否意外启用了 cgo（如设置了CC环境变量）。
⚠️ 注意事项：
- 禁用 cgo 后，
net包将使用纯 Go 的 DNS 解析器（netgo），无需 libc；但若代码显式调用os.UserHomeDir()或user.Lookup()等函数，需改用os.Getenv("HOME")或避免依赖系统用户数据库。 - macOS 本地构建成功而 Linux 构建失败，往往因 macOS 默认
CGO_ENABLED=0（无 libc 可链接），而 Linux 构建机默认CGO_ENABLED=1，导致产出动态二进制。务必在 CI/CD 流水线中显式设置CGO_ENABLED=0。 - 使用
FROM scratch时，所有依赖必须以静态方式打包进二进制——包括 TLS 根证书（可通过go run -tags netgo或嵌入ca-certificates文件解决，但推荐使用x509.SystemCertPool()+GODEBUG=x509ignoreCN=0等现代方式）。
总结：scratch 镜像不是“不能运行多进程”，而是要求所有二进制严格静态化。只要 first 和 second 均为 CGO_ENABLED=0 编译的纯静态可执行文件，exec.Command("/opt/my-app/second").StdinPipe() 等调用即可在 scratch 容器中稳定工作——这才是云原生场景下最小、最安全的多进程 Go 应用部署范式。
