cgo_enabled=0必须设置，因为不关闭cgo会导致二进制动态链接libc，依赖宿主机glibc版本，破坏可移植性并引入cve-2015-7547等漏洞风险；设为0后强制使用go纯实现，生成完全静态二进制，无c库符号。
Go静态编译时CGO_ENABLED=0为什么必须设
因为不关CGO，二进制会动态链接libc，导致运行时依赖宿主机glibc版本，既破坏可移植性，又引入攻击面——比如旧版glibc的堆溢出漏洞（如CVE-2015-7547）会直接传导到你的容器里。CGO_ENABLED=0强制使用Go自带的net、os等纯Go实现，生成完全静态链接的二进制，不带任何C库符号。
常见错误现象：./app: error while loading shared libraries: libpthread.so.0: cannot open shared object file，就是忘了关CGO；或者在Alpine上跑失败，也是因为musl libc和glibc ABI不兼容。
- 交叉编译时务必加：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 gobuild -o app ./cmd/app - 若代码中用了
cgo特性（如调用C函数、sqlite驱动），就不能关CGO，此时必须用golang:alpine镜像构建，并确保目标环境有对应C库 - 关CGO后，
net.LookupHost等DNS解析会退化为纯Go实现（基于/etc/resolv.conf），不支持systemd-resolved或nsswitch扩展，但更可控、无隐式依赖
最小基础镜像选scratch还是alpine
选scratch是真正意义上的最小边界：它是一块空画布，只含内核系统调用接口，体积≈0MB，攻击面趋近于零。但代价是调试能力归零——你连sh、ls、strace都没有。
alpine则是在安全与可观测性之间折中：约5MB，带busybox和apk，能临时装curl或netstat排障，但多出的每个工具都是潜在攻击入口点。
- 生产环境无调试需求 → 用
FROM scratch，COPY二进制后直接CMD ["./app"] - 需要日志抓取或简单网络诊断 → 用
FROM alpine:latest，但别RUN apk add任何额外包 - 绝对禁止在
scratch镜像里塞bash或sh——哪怕只为了“方便”，就等于主动撕开最小边界
非root用户运行时uid=65534是什么陷阱
很多Dockerfile写USER 65534，以为这是“非root”，其实65534是nobody用户，但Kubernetes默认启用MustRunAsNonRoot策略时，只校验UID≠0，不校验GID或用户名语义——所以65534能过PodSecurityPolicy，却可能因权限太低导致bind()失败、open(/tmp)被拒、甚至logrus写日志时chmod报错。
真正安全的做法是显式创建低权限用户，并赋予必要能力：
- 在Dockerfile里：
RUN adduser -u 1001 -D -s /sbin/nologin appuser && chown -R appuser:appuser /app - 然后
USER 1001，不是数字魔数，而是可读、可审计的UID - 如果应用需监听1024以下端口（如80），别改端口映射，改用
setcap 'cap_net_bind_service=+ep' ./app授予权限，避免提升UID
Go二进制里残留调试符号怎么清
默认gobuild生成的二进制包含完整调试信息（DWARF），体积膨胀30%-50%，且泄露源码路径、变量名、函数签名——攻击者拿到二进制就能反推逻辑结构，甚至定位未公开API。
用-ldflags剥离是最有效方式：
- 编译时加：
gobuild -ldflags="-s -w" -o app ./cmd/app -
-s删掉符号表和调试信息，-w删掉DWARF段 - 验证是否清理干净：
file app应显示“stripped”；readelf -S app | grep debug应无输出 - 注意：
-s -w不影响panic堆栈行号，但会丢失runtime/debug.Stack()里的函数名，需权衡可观测性
gobuild命令是否明确知道哪个flag在关闭什么能力、每个USER指令背后是否经过权限最小化验证、以及当scratch里连echo都没有时，你是否已准备好用tcpdump容器侧捕包替代shell诊断。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
