Snyk 扫描 Go 项目前需确保 go.mod 存在且已运行 go mod tidy，多模块仓库须加 --all-projects；不解析 go.sum 和本地 replace 路径，条件编译依赖会被误判，推荐 CI 中用 snyk test --fail-on high 而非仅 rely on monitor。
用 snyk test 扫 Go 项目前，先确认 go.mod 是否完整
Go 的依赖图不靠 vendor/ 或 lock 文件“固化”就能被 Snyk 解析，但前提是 go.mod 必须存在且已执行过 go mod tidy。否则 Snyk 会报 Failed to resolve dependencies: no go.mod found 或漏掉间接依赖（require ... // indirect 那些）。
- 运行
go mod tidy后再扫，避免因本地缓存或未声明的依赖导致漏报 - 若项目用
go.work，Snyk 当前（v1.1090+）支持，但需确保工作区里每个模块都有独立go.mod - 别把
go.sum当扫描依据——Snyk 不读它，只解析go.mod的require块和版本语义
扫描时加 --all-projects 才能覆盖多模块仓库
单个 Go 项目扫得准，但现实里常见一个 Git 仓含多个 cmd/、internal/、pkg/ 子模块，各自有 go.mod。默认 snyk test 只扫当前目录下的 go.mod，其他模块的漏洞直接隐身。
- 必须显式加
--all-projects参数，Snyk 才会递归找所有go.mod并分别分析 - 如果子模块用了 replace 指向本地路径（如
replace example.com/lib => ../lib），Snyk 无法解析该路径——它不执行go build，只静态读取模块定义 - CI 中建议加
--json输出，配合jq提取.vulnerabilities[].severity做门禁，而不是依赖终端颜色判断
snyk monitor 不等于持续防护，它只打快照
snyk monitor 上传依赖树到 Snyk Cloud，后续靠它对比新漏洞披露。但它不会自动重扫、不监听 go.mod 变更、也不触发告警——你得自己定时跑 snyk test --json 或配 webhook。
- 执行
snyk monitor后，Snyk 控制台里能看到 “Last updated”，但这个时间点仅反映上传时刻的依赖状态 - 若某天
golang.org/x/crypto发布 CVE，而你上次monitor是两周前，中间没test过，那漏洞就躺在那里没人知道 - CI 流程里建议：每次 PR 提交后跑
snyk test --fail-on high，比依赖monitor的后台扫描更及时
Go 泛型和 //go:build 条件编译会让 Snyk 误判可选依赖
Snyk 解析 go.mod 时不运行构建，所以对条件引入的依赖（比如仅在 Windows 下 require 的包）或泛型约束中隐式拉入的模块，它一律当成“总会用到”。结果就是：报一堆实际不会进二进制的漏洞，干扰判断。
立即学习“go语言免费学习笔记（深入）”；
- 例如
github.com/mattn/go-sqlite3在//go:build cgo下才生效，但 Snyk 仍把它当必选依赖扫 - 目前无参数跳过特定模块，只能靠
--exclude=github.com/mattn/go-sqlite3临时过滤（注意：排除后该模块所有漏洞都不报） - 更稳妥的做法是拆出最小可构建子模块单独扫描，比如只扫
./pkg/core而非整个根目录
go.mod 的准确性和扫描范围——少一个 --all-projects，或多一个本地 replace，都可能让关键漏洞消失在报告里。 
