用 go run 快速验证代码，用 go build 生成可执行文件——别混着用，否则会踩包管理、工作目录和环境变量的坑。
直接说结论：用 go run 快速验证代码，用 go build 生成可执行文件——别混着用，否则会踩包管理、工作目录和环境变量的坑。
go run 为什么总报 “cannot find package”
常见错误现象是：在非模块根目录下执行 go run main.go，提示 cannot find package "xxx" 或 no required module provides package。
根本原因是 go run 默认按 Go Modules 模式查找依赖，它需要一个有效的 go.mod 文件，且当前路径必须在模块根目录（或子目录）内。
- 确保已在项目根目录执行
go mod init myproject生成go.mod - 不要在
$GOPATH/src下手动建目录再跑——Go 1.16+ 默认关闭 GOPATH 模式 - 如果只是单文件测试，加
-mod=mod强制启用模块模式：go run -mod=mod main.go - 不推荐用
go run *.go，跨文件时容易漏掉依赖声明，优先用go run .
go build 编译出来的二进制为啥运行时报错找不到库
典型表现：Linux 上编译出的 myapp 拷到另一台机器运行，提示 error while loading shared libraries: libgo.so: cannot open shared object file。
这是因为 Go 默认使用 CGO（调用 C 库），而 go build 生成的是动态链接可执行文件，依赖宿主机的 libc 和其他 C 运行时。
- 想彻底静态链接（适合容器或陌生 Linux 环境）：加
CGO_ENABLED=0 go build - macOS 上默认静态链接，但若用了
net包，仍可能触发 DNS 解析的系统调用，需额外加-tags netgo - Windows 下一般无此问题，但注意
go build -ldflags "-H windowsgui"可隐藏控制台窗口
main.go 里 import "." 是什么鬼？为什么 go build 不报错但运行崩溃
这是误用了相对导入路径，比如在 main.go 中写 import "./utils"。Go 不支持这种写法，但某些旧版本或非标准构建流程可能“侥幸通过”，实际运行时 panic。
Go 的 import 路径必须是模块路径（如 "github.com/user/project/utils"）或标准库名（如 "fmt"），不能是文件系统相对路径。
- 检查
go.mod中的module声明是否匹配你的 import 路径前缀 - 用
go list -f '{{.Dir}}' .确认当前模块根路径 - 本地包应放在子目录，然后用模块路径导入，例如
myproject/utils，而非./utils
最常被忽略的一点：go build 和 go run 对 GOOS/GOARCH 的默认行为不同——go run 总是在当前系统运行，而 go build 可交叉编译，但一旦设了 GOOS=linux，就必须确保所有依赖都支持该平台，否则静默失败或运行时 panic。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
