先确认cgo_enabled=1，否则import "c"代码被跳过导致undefined reference；再确保目标环境安装匹配主版本号的.so库并执行ldconfig刷新缓存。
go build 时提示 undefined reference 到 C 函数？先确认 CGO_ENABLED 状态
Go 默认启用 cgo，但某些环境（如 Alpine 容器、CI 构建机）可能默认关闭它，导致本该链接的 C 动态库被跳过，最终在链接阶段报 undefined reference to `SSL_CTX_new' 这类错误。
检查方式很简单：
go env CGO_ENABLED
如果输出是 0，那所有带 //export 或 #include 的代码都不会参与链接——不是你漏装 libssl，而是根本没走链接流程。
- 临时启用：
CGO_ENABLED=1 go build - 永久设置（仅限开发机）：
go env -w CGO_ENABLED=1 - 注意：设为
1后，go build会依赖系统 libc、libssl 等，必须确保目标环境有对应动态库
ldd 显示 not found 但 apt search 找不到包？盯住 .so.x 后缀数字
比如 ldd ./myapp | grep "not found" 输出 libssl.so.1.1 => not found，这不是让你装 libssl-dev 或 openssl，而是要匹配 .so.1.1 中的主版本号 1.1。
Debian/Ubuntu 的命名规则很严格：
-
libssl.so.1.1→ 必须装libssl1.1，不是libssl3（后者提供libssl.so.3） -
libwebp.so.5→ 对应libwebp7（因为 7 是 Debian 当前打包的主版本，.so 后数字与包名数字不强制一致，但兼容性由 .so.x 决定） - 装错版本会导致运行时报
undefined symbol: SSL_get_version，比not found更难定位
容器里装了库还是 not found？别忘了 ldconfig
Dockerfile 里写 RUN apt install -y libssl1.1 不够。新装的库路径不会自动进动态链接器缓存，ldd 依然看不到。
必须显式刷新：
RUN apt update && apt install -y libssl1.1 && ldconfig
这是高频遗漏点。没有 ldconfig，哪怕 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 文件真实存在，ldd 也会显示 not found。
- 不要用
LD_LIBRARY_PATH临时绕过——它在多阶段构建或非 root 用户下容易失效 - Alpine 用户请改用
apk add openssl1.1，并注意其 so 名是libssl.so.1.1，包名却是openssl1.1
想彻底避开动态库问题？用 CGO_ENABLED=0，但得满足前提
加 CGO_ENABLED=0 后生成的是纯静态二进制，不依赖任何系统 .so，扔到任意 Linux 发行版甚至 glibc 都能跑。
但它有硬约束：
- 代码里不能有
#include、C.xxx调用，也不能 import"C" - 不能用
net包的 cgo 模式（会 fallback 到纯 Go DNS 解析，没问题） - 第三方库若内部用了 cgo（如
github.com/mattn/go-sqlite3），关掉后直接编译失败
所以不是“一加就灵”，得先确认项目是否真没碰 C 层。最简单的验证方式：本地执行 CGO_ENABLED=0 go build，看是否报错。
真正麻烦的是那种半 cgo 项目——部分模块需要 sqlite3，部分要调 OpenSSL，这种没法一刀切，只能分镜像构建或对齐基础镜像的 libc 版本。
