ldd是第一道排查门槛，必须在目标容器中运行而非本地；缺失库名含.so.x后缀，需apt search精准匹配对应包（如libwebp.so.5→libwebp7）；装包后务必执行ldconfig刷新缓存；优先系统级注册路径而非LD_LIBRARY_PATH；纯Go程序可设CGO_ENABLED=0生成静态二进制。
ldd 是第一道排查门槛，必须在目标容器里跑
编译成功不代表能运行，关键看二进制依赖是否能在目标环境解析。别在本地开发机上 ldd ./myapp —— 那只会显示“全都有”，是假象。真正要查，得把二进制拷进目标容器（或直接在目标服务器上），再执行：ldd ./myapp | grep "not found"。输出类似 libwebp.so.5 => not found 或 libssl.so.1.1 => not found，这些就是缺失的动态库名（注意：是完整名称，含 .so.x 后缀，不是路径、也不是版本号片段）。
apt search 要按 .so.x 后缀精准匹配包名
拿到缺失库名后，在 Debian/Ubuntu 类容器中用 apt search 查对应系统包，例如：apt search libwebp.so.5。结果通常返回 libwebp7 这类包名——7 对应 .so.5 的主版本，不是随意选最新版。常见映射关系：
-
libxxx.so.1→ 一般对应libxxx1 -
libssl.so.1.1→ 必须装libssl1.1，装libssl3会报undefined symbol -
libmysqlclient.so.21→ 对应libmysqlclient21
装错版本比“not found”更难定位，因为链接器能加载库，但符号对不上。
Dockerfile 里装完库必须加 ldconfig
在 Dockerfile 中用 apt install 装完库后，不能以为完事了。新库默认不会被动态链接器识别，必须显式刷新缓存：RUN apt update && apt install -y libwebp7 && ldconfig。漏掉 ldconfig 是高频坑：你明明装了包，ldd 却还报 not found，就是因为缓存没更新。别依赖 LD_LIBRARY_PATH，它在容器里容易污染、不可靠；优先走系统级注册（/etc/ld.so.conf.d/ + ldconfig）。
立即学习“go语言免费学习笔记（深入）”；
CGO_ENABLED=0 是最直接的规避方式，但得确认代码没调 C
如果程序只用标准库或纯 Go 第三方库（比如 net/http、encoding/json），且没写 import "C"、没用 #include、也没依赖 sqlite3/cgo/openssl 等 C 绑定，那直接关 CGO：CGO_ENABLED=0 go build -o myapp。生成的是完全静态二进制，扔进 Alpine、CentOS、任何 Linux 发行版都能跑，零依赖。
但一旦代码里有 C 交互痕迹，关 CGO 就会编译失败。这时候就得老老实实补库，或者改用多阶段构建，让构建镜像和运行镜像的 libc 版本对齐——这点最容易被忽略：不是“有没有库”，而是“库的 ABI 是否兼容”。
