先确认go.mod是否已正确初始化：执行go mod init 生成go.mod，再运行go mod tidy下载缺失依赖、清理未用项并更新go.sum；若依赖来自私有仓库，需配置go_proxy或replace规则。
打包时 Go 模块依赖没被包含？先确认 go.mod 是否已正确初始化
Go 1.11+ 默认启用模块模式，但很多项目仍沿用旧习惯，没生成或没提交 go.mod 和 go.sum。如果执行 go build 后二进制运行时报 cannot find module 或找不到包，大概率是模块未启用或依赖未记录。
- 运行
go mod init <module-name></module-name>（如go mod init example.com/myapp），确保当前目录有go.mod - 执行
go mod tidy：自动下载缺失依赖、清理未使用项，并更新go.sum - 检查
go.mod中是否出现目标模块，例如：require github.com/spf13/cobra v1.8.0 - 若依赖来自私有仓库，需提前配置
GO_PROXY或replace规则，否则go mod tidy会失败
go build 默认就包含所有依赖，但要注意 _ 导入和条件编译
Go 编译器静态链接全部依赖代码进二进制，不需要额外“打包”依赖文件。但某些情况会导致依赖看似“没包含”：
- 使用了
import _ "net/http/pprof"这类空白导入：它只触发包的init()，不产生符号引用；若主逻辑没显式调用该包任何导出标识符，go build可能将其整个排除（取决于构建标志和 Go 版本） - 条件编译（
//go:build）导致某平台下依赖未被扫描到：比如import "golang.org/x/sys/windows"在 Linux 下不会被纳入构建，即使go.mod里存在 - 使用了
-ldflags="-s -w"：这不影响依赖包含，但会剥离调试信息，可能让dlv等工具无法追踪依赖源码
交叉编译时依赖路径不一致？优先用 CGO_ENABLED=0
启用 cgo（默认开启）会让 Go 尝试链接系统 C 库，而不同平台的 C 头文件和库路径差异大，容易在打包后运行时报 libxxx.so not found。尤其当你把 Linux 编译的二进制拷到 Alpine 或无 libc 环境时。
- 强制纯 Go 构建：
CGO_ENABLED=0 go build -o myapp ./cmd/myapp - 这样所有依赖（包括
net、os/user等原本依赖 cgo 的包）都会走 Go 自带实现，避免动态链接问题 - 注意：部分模块（如
github.com/mattn/go-sqlite3）必须 cgo，此时不能禁用；得改用对应平台的静态链接方式（如 Alpine 的musl-dev）
验证依赖是否真被包含：用 go version -m 和 strings
光看构建成功不代表依赖逻辑生效。有些模块只在特定 flag 或环境变量下才激活，运行时才暴露缺失。
- 检查二进制嵌入的模块信息：
go version -m ./myapp—— 输出里应列出所有go.mod中的 require 项及其版本 - 快速扫描是否含敏感依赖名：
strings ./myapp | grep -i 'github.com/sirupsen/logrus'（适用于纯 Go 依赖） - 若依赖是 CGO 绑定的，用
ldd ./myapp查看动态链接库，确认是否意外链接了 host 系统的.so
真正麻烦的不是“怎么包含”，而是“看起来包含了，但运行时才报错”。模块版本冲突、平台相关 init 函数跳过、替换规则（replace）没同步到 CI 环境——这些才是上线前最常漏掉的点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
