go 的 import 是编译期行为，非运行时延迟加载；所有导入包在构建时即参与依赖解析、初始化和链接，init() 和全局变量在 main() 前执行，顺序由导入图决定。
Go 的 import 不会延迟加载
Go 编译时就确定所有依赖，import 语句不是运行时指令，而是编译期声明。没有“首次调用才加载包”的机制——这和 Python 的 import 或 Java 的类加载器完全不同。
常见错误现象：go build 失败时提示某个未使用的包报错（比如 import "C" 缺失 cgo 环境），或 vendor 中存在未引用的包仍被检查；误以为删掉某处 import 就能跳过该包初始化。
- 只要源文件里写了
import "net/http"，哪怕整段代码被//注释掉，net/http仍参与编译和链接 - 包级变量初始化（
var x = someFunc()）和init()函数，在main()执行前就完成，且顺序由导入图决定 - 跨平台构建时，条件编译（
//go:build windows）能排除某些包，但这仍是编译期裁剪，非运行时延迟
想“按需加载”只能靠插件或动态链接
Go 原生不支持运行时按路径加载 .so/.dll 或字节码。所谓“延迟”，实际要靠外部机制模拟。
使用场景：CLI 工具支持可选子命令（如 git lfs）、服务端插件化扩展、避免启动时加载重型驱动（如数据库驱动）。
立即学习“go语言免费学习笔记（深入）”；
-
plugin.Open()可加载 Go 编译出的.so文件，但仅限 Linux/macOS，Windows 不支持，且要求主程序和插件用完全相同的 Go 版本和构建参数 - 用
database/sql的驱动注册机制（_ "github.com/lib/pq"）看似“按需”，实则是编译期注册——没导入就不会注册，但一旦导入就进二进制 - 更现实的做法是把功能拆成独立二进制，用
exec.Command调用，通信走 stdin/stdout 或本地 socket，规避链接和初始化耦合
import _ "xxx" 的真实作用不是延迟，而是触发副作用
import _ "net/http/pprof" 这类写法常被误解为“懒加载 pprof”，其实它只是让 pprof 包的 init() 函数执行，从而向 http.DefaultServeMux 注册路由。包本身早已在编译期链接进去了。
容易踩的坑：import _ "some/unused/package" 会导致该包所有 init() 运行、所有全局变量初始化，可能引发意外副作用（如连接数据库、监听端口、修改全局状态）。
- 如果包没有
init()或副作用，import _和普通import对二进制体积影响一致 - 交叉编译时，
import _ "unsafe"是合法的，但import _ "os/user"可能在目标平台因缺少 libc 而失败 - 用
go list -f '{{.Deps}}' .可查看实际依赖树，验证某个包是否真的被引入
构建时裁剪比运行时加载更符合 Go 设计哲学
Go 鼓励通过构建标签（//go:build）、模块替换（replace）或接口抽象来控制依赖范围，而不是试图绕过编译模型去模拟动态性。
性能影响：静态链接后，所有包代码都在内存中，但初始化开销集中在启动瞬间；动态方案（如 exec）启动慢、IPC 有延迟、调试链路断裂。
-
go build -tags 'no_cgo'可排除 cgo 依赖，比运行时判断os.Getenv("CGO_ENABLED")更彻底 - 用接口隔离实现（如
type Logger interface { Info(...)），再通过构造函数注入具体实现，比在运行时plugin.Open更轻量、可测试、无平台限制 - 真正的大忌是：为了“看起来像延迟加载”，在
init()里做耗时操作（如 HTTP 请求、磁盘扫描）——这会让所有导入该包的程序启动变慢，且无法规避
最常被忽略的一点：包名冲突和循环导入不会在运行时报错，而是在 go build 阶段直接失败。别指望“先不 import，等要用时再加”，那只会让问题延后到集成阶段才暴露。
