根本原因是模块路径与import路径不匹配或go111module未正确启用；需用go mod init指定正确模块名、确保import前缀与go.mod中module声明一致，并设go111module=on强制启用模块模式。
Go 环境装完、go run hello.go 跑通，不等于能写真实项目——起步阶段的“顺利”往往掩盖了后续掉坑最密集的区域。
为什么 go mod init 后 go build 仍报找不到包？
常见于从 GitHub 复制示例代码后直接运行：模块路径与实际导入路径不一致，或本地未启用 Go Modules（尤其 GOPATH 模式残留）。
- 执行
go env -w GO111MODULE=on强制开启模块模式（Go 1.16+ 默认开启，但旧终端可能缓存旧值） -
go mod init的参数必须是模块根路径，例如项目在~/projects/myapp，就该用go mod init myapp，而非随意起名如go mod init demo - 检查所有
import语句里的路径是否与go.mod中的module声明前缀匹配；不匹配时，go build会去 GOPATH 或 proxy 查，而不是当前目录
本地开发时如何安全替换依赖为自己的修改版？
比如调试 github.com/sirupsen/logrus 源码，或临时打补丁。直接改 go/pkg/mod/ 下的缓存是危险且不可复现的。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 用
replace指令在go.mod中重定向：replace github.com/sirupsen/logrus => ../logrus-fix
（路径为相对于go.mod文件的相对路径） - 替换后必须运行
go mod tidy，否则go build仍可能拉取远端版本 - 注意：若被替换的包本身有
go.sum校验项，go mod tidy会自动更新它；但推送代码前应确认团队是否接受该replace—— 它无法被他人复现，除非也提供对应本地路径
为什么 go test 能过，但 CI 上跑失败？
典型诱因是测试依赖了未显式声明的环境变量、本地文件路径，或用了 os/exec 调用系统命令（如 curl、jq），而 CI 镜像里没有这些工具。
- 用
os.Getenv读环境变量前，先检查是否存在，避免 panic；更稳妥的是用os.LookupEnv - 测试中涉及文件操作，一律用
os.MkdirTemp创建临时目录，而非硬编码/tmp/testdata；测试结束调用defer os.RemoveAll - 避免在测试中调用外部命令；若必须，先用
exec.LookPath("curl")检查可执行文件是否存在，不存在则跳过测试：t.Skip("curl not available")
真正卡住人的，从来不是语法，而是模块路径怎么对、依赖怎么换、测试怎么写才不依赖机器——这些事不会在 go help 里高亮，但每次出问题都在这三件事上反复消耗时间。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
