no required module provides package报错是因为go.mod未登记该依赖，需先确保有go.mod文件，再用go get指定根模块并立即执行go mod tidy补全require。
go get 后 no required module provides package 报错
这不是依赖没装上，而是 Go 没在 go.mod 里登记它。常见于刚写完 import 就直接 go run，或执行了 go get 但没触发模块更新。
- 先确认当前目录有
go.mod：没有就运行go mod init example.com/myapp（module 名不用真实存在，但别用github.com/xxx这种易冲突的） -
go get命令本身不保证写入go.mod，尤其当目标包是间接依赖时；更可靠的是go get github.com/cloudwego/hertz@v0.7.0（指定顶层模块，不是子路径） - 执行完立刻跟一句
go mod tidy，它会补全缺失的require、删掉未引用的项，并校验go.sum - 如果报错里提示 “to add it: go get xxx”，别照抄——那个路径（如
github.com/cloudwego/hertz/pkg/app）只是子包，go get应作用于根模块（github.com/cloudwego/hertz）
版本没变、go list -m all 显示旧版
Go 的最小版本选择（MVS）算法会忽略你写的 @v1.2.3，只要已有更高兼容版本满足所有依赖约束。比如项目里已有 github.com/some/lib/v2，再 go get github.com/some/lib@v1.5.0 就无效。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 查清谁在拉旧版：
go mod graph | grep some-lib看哪条链引入了哪个版本 - 强制指定并写入：
go mod edit -require=github.com/some/lib@v1.5.0，再go mod tidy - 想跳过 MVS 直接锁定 commit：
go get github.com/some/lib@e8f4a5c（哈希值要完整） - v1 和 v2 是不同模块路径，改版本必须同步改
import语句，否则编译器根本不会去找/v2
go mod vendor 后构建仍报错
vendor 不是开关，是目录；go build 默认仍走 GOPROXY，除非显式告诉它“只信 vendor”。
- 生成后必须运行
go build -mod=vendor，缺这个 flag 就不算真正离线 - 检查
vendor/modules.txt是否包含你预期的版本；如果缺失，说明go mod vendor没拉全——先go mod tidy再试 - vendor 目录不会自动更新，每次
go get或go mod tidy后都要重新go mod vendor - CI 中若用 vendor，建议加
go mod verify校验go.sum与 vendor 内容是否一致
replace 生效但上线前忘了清理
replace 是临时手术刀，绕过 go.sum 校验，本地跑得通，CI 或其他机器可能 panic。
- 验证是否真生效：
go list -m all | grep your-module，输出里应带=>指向你指定的路径或版本 - replace 不传递给下游模块，别人
go get你的库时不会继承它 - 上线前必须删掉
go.mod里的replace行，再go mod tidy—— 否则go.sum缺失对应校验和 - 私有 patch 更稳妥的做法是 fork 修复后提交 PR，而不是长期靠 replace 维持
go mod tidy 并不等价于“已解决所有依赖问题”。它只确保当前代码能编译，但不会告诉你某个间接依赖正悄悄加载着两个不兼容版本——得靠 go list -m all 和 go mod graph 主动翻。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
