必须在go.work根目录执行安全检查命令，且所有模块需use显式声明；govulncheck仅扫描实际调用链，本地模块未import则不被检测；go mod verify不校验use模块，CI应禁用GOWORK并模拟真实构建环境。
go work 模式下验证依赖安全，必须先确保工作区生效
在工作区模式下运行 govulncheck 或 go mod verify 时，如果命令没在 go.work 所在目录执行，或子模块路径未被 use 显式声明，工具会退回到单模块上下文——此时根本看不到跨模块的依赖关系，漏洞扫描和校验都会漏掉本地联动部分。
实操要点：
- 所有安全检查命令（
govulncheck ./、go mod verify、go list -m all）必须在含go.work的根目录下运行 -
go.work文件中每个要参与开发的模块路径，都得用use ./xxx显式列出，不能靠目录结构自动发现 - 若某个模块仍被
replace覆盖，govulncheck会按replace后的路径解析，但实际构建时走的是工作区路径——这种不一致会导致漏洞误判，应删掉replace行
govulncheck 扫描多模块时要注意间接依赖路径是否真实可达
govulncheck 默认只分析构建图中“实际调用链”上的模块，而工作区模式下，本地模块之间是直接文件系统引用，不是通过版本号拉取。这意味着：如果模块 A use 了模块 B，但 A 的代码里根本没 import B 的任何包，B 就不会出现在扫描结果里——哪怕 B 本身有高危 CVE。
常见问题与对策：
立即学习“go语言免费学习笔记（深入）”；
- 扫描结果比预期少？用
go list -m all确认所有use的模块是否列在输出中；没出现说明go.work未生效或路径写错 - 想强制包含某个模块做安全评估？在主模块的
main.go或测试文件里加一行_ "github.com/your-org/xxx"，再跑govulncheck ./ - CI 中不要依赖
govulncheck -deps=1，它只看直接依赖，而风险常藏在模块 B → 模块 C → 漏洞库 这样的二级链路里
go mod verify 在工作区里只能校验 go.sum 已记录的模块
go mod verify 不关心 go.work，它只比对 go.sum 文件里的哈希值和本地缓存内容。而工作区模式下，本地模块是“绕过下载直接加载”的，它们的校验和根本不会写进 go.sum——所以你执行 go mod verify 时，那些 use 进来的本地模块压根不会被检查。
这意味着：
- 本地模块自身的代码完整性，
go mod verify完全不覆盖，得靠 Git 提交记录或人工确认 - 如果本地模块又依赖了远程第三方（比如
lib_b/go.mod里写了require golang.org/x/crypto v0.25.0），这部分才会出现在go.sum并被go mod verify校验 - 想让本地模块也被校验？只能把它发布成 tag，然后在其他模块里用版本号引用，再运行
go mod verify——但这违背了工作区“免发布联调”的初衷
CI/CD 中禁用 go work 是安全验证的前提
CI 环境默认忽略 go.work，这反而是好事：它迫使你面对真实构建场景。但如果你在本地靠工作区掩盖了依赖问题（比如用 use 绕过了一个有漏洞的旧版远程依赖），CI 就会暴露出来——因为 CI 里 go build 会严格按各模块自己的 go.mod 解析，而那个旧版可能已被 govulncheck 标记为不安全。
关键动作：
- CI 脚本开头加
go env -w GOWORK=off，彻底关闭工作区，避免环境差异干扰 - CI 中必须运行
go mod download && go mod verify，确保远程依赖完整且未篡改 - 本地开发用
go work提效，但每次合入前，要在 CI 模拟环境下单独验证：删掉go.work，用go mod tidy重新生成依赖树，再扫一次govulncheck ./
最易被忽略的一点：工作区让你能“假装”模块 B 已升级，但只要它的 go.mod 里还写着 require example.com/lib v0.1.0，CI 就会真的去拉这个带漏洞的 v0.1.0——go work use 不会修改任何 go.mod 内容，它只是临时覆盖解析行为。
