go编译器报cannot find package是因构建上下文未找到包源码或编译产物，按$goroot/src、$gopath/src、模块内路径、pkg/mod顺序查找；go mod tidy可自动补全依赖，但需已初始化模块、使用完整导入路径且代理配置正确。
go build 报 cannot find package 是什么在找
Go 编译器报 cannot find package "xxx"，不是“没下载”，而是当前构建上下文里找不到该包的源码或已编译产物。它按固定顺序查找：$GOROOT/src/xxx（标准库）、$GOPATH/src/xxx（旧 GOPATH 模式）、当前模块内路径（Go Modules 模式），最后才是缓存中的 pkg/mod。错误提示末尾列出的路径（如 /usr/local/go/src/github.com/gorilla/websocket）就是它实际去翻的地方——你得看它找的是哪一层。
go mod tidy 能自动补全缺失依赖吗
能，但前提是：你已在项目根目录运行过 go mod init，且 go.mod 文件存在；所有 import 语句使用的是完整模块路径（如 github.com/gorilla/websocket），而非相对路径或本地别名；网络通畅且 GOPROXY 已设为可用地址（如 https://goproxy.cn,direct）。
-
go mod tidy会扫描全部.go文件里的import，把未声明但被引用的模块加进go.mod，再从代理或源站拉取对应版本到pkg/mod - 如果某包仍报错，先运行
go env GOPROXY确认代理生效；再执行go mod download github.com/gorilla/websocket@latest单独测试拉取是否成功 - 若提示
no required module provides package，说明 import 路径拼写错误，或该包根本不在 Go 模块生态中（比如是私有 Git 仓库但没配replace或git config认证）
为什么 go get 不再推荐用于解决缺失包
go get 在 Go 1.16+ 默认只更新 go.mod 和 go.sum，不自动写入 require 条目，行为已弱化；更关键的是，它可能绕过 go.mod 的版本约束，直接拉取 master 或最新 tag，导致依赖不一致。真正该用的是：
通过聊天（Telegram / 飞书）执行本地 `clawusage` 监控命令。当用户输入 `/clawusage ...`，或提出“查看 Codex 用量”、“开启/关闭自动…”等请求时触发使用。
-
go mod tidy：同步声明与实际引用，安全、可复现 -
go get -d github.com/gorilla/websocket@v1.5.0（加-d仅下载不构建，且指定明确版本） -
go install github.com/gorilla/websocket/cmd/xxx@latest：仅当你要装命令行工具时才用，和库依赖无关
误用 go get xxx 可能污染 go.mod 版本号，或让 CI 构建因版本漂移失败。
容器或 CI 中 missing package 的隐蔽原因
本地 go mod tidy 成功，但 Docker 构建或 CI 流水线里仍报缺失，常见于：
- Dockerfile 里没执行
go mod download或go mod tidy，只复制了源码和go.mod，没带pkg/mod缓存（而容器里默认没缓存） - 多阶段构建中，build 阶段用了
CGO_ENABLED=0，但 final 阶段基础镜像缺失 libc 相关头文件（如musl-dev），导致某些 Cgo 包（如sqlite3）无法编译 - CI runner 使用的 Go 版本低于
go.mod声明的go 1.21，低版本解析不了新语法或模块特性
最稳做法：Dockerfile 中在 COPY . . 后立即跑 go mod download，确保所有依赖落地；final 镜像用 FROM gcr.io/distroless/static 或 alpine:latest 前，先确认项目是否含 Cgo —— 含就用 golang:alpine 构建，不含就用 distroless。
