golangci-lint 本身不是漏洞扫描器，仅通过 staticcheck、errcheck 等 linter 拦截高危编码模式：SA1019（弃用API）、SA1021（time.After滥用）、SA1027（unsafe未注释）、SA4006（恒真/假条件）、SA5008（JSON类型错配）；需显式启用且依赖 Go 1.21+ 和正确配置。
golangci-lint 本身不是漏洞扫描器，不提供 CVE 检查、依赖漏洞识别或 SAST 级别安全分析；它只做静态代码质量检查，所谓“安全检查”实际是通过启用特定 linter（如 staticcheck、errcheck）来拦截高危编码模式。
staticcheck 能抓哪些“安全相关”的问题
staticcheck 是唯一值得在安全上下文中启用的 linter，它能识别运行时可能引发 panic、数据泄露或逻辑绕过的模式，但需注意它不扫描第三方依赖或配置文件：
-
SA1019：调用已弃用函数（如crypto/md5、http.Redirect不带 status code），这类 API 往往存在已知缺陷或设计缺陷 -
SA1021：循环中滥用time.After（导致 goroutine 泄漏和内存持续增长） -
SA1027：使用unsafe且未加注释说明用途（强制要求人工审查） -
SA4006：恒真/恒假条件判断（如if false { ... }或for true { ... }），可能掩盖逻辑缺陷或被用于绕过校验 -
SA5008：JSON 反序列化时类型错配（如用int接收字符串字段），易导致解析失败或静默截断
这些规则默认关闭，必须显式启用：linters-settings.staticcheck.enable-all: true，或只开具体条目：checks: ["SA1019", "SA1021", "SA1027"]。
errcheck 必须禁用测试专用误报函数
errcheck 本意是防止 error 被忽略，但在测试中 t.Fatal、log.Fatal、os.Exit 是合法终止方式，若不屏蔽会大量误报：
- 在
.golangci.yml中配置：errcheck: exclude-functions: ["t.Fatal", "t.Fatalf", "log.Fatal", "log.Fatalf", "os.Exit"] - 不要用
check-exported: false——它会同时放过导出函数里的错误检查，削弱主线逻辑防护 - 确保
--tests参数已启用（否则 _test.go 文件根本不会被 errcheck 扫到）
go vet 的 shadow 和 atomic 检查要谨慎启用
govet 的部分子检查有安全意义，但极易在测试中误报，必须针对性调整：
-
shadow：在for _, tt := range tests场景下常把tt误判为变量遮蔽，应禁用：govet: disable: ["shadow"] -
atomic：检查非原子操作访问sync/atomic类型，对并发安全关键，建议保留；但需确认项目用了 Go 1.20+，否则该检查不可用 -
printf和stringintconv：防止格式串注入和整数转换溢出，可保留，无明显误报
别碰 copylock 或 nilfunc——前者在泛型代码中误报率极高，后者几乎无实际价值。
别信“安全 linter”列表，真正起作用的就这三个
网上常列的 gosec、gas、revive 安全规则等，要么已归档（gas），要么不属于 golangci-lint 原生支持（gosec 需单独集成），要么规则粒度太粗（revive 的 security-audit 规则基本无效）：
- 只保留
staticcheck（深度语义）、errcheck（错误流控制）、govet（基础运行时行为）这三项，其他如gosec必须作为独立步骤跑，不能塞进.golangci.yml -
unused和gosimple虽不直接标“安全”，但清理废弃 test helper 或简化冗余断言（如if !ok { t.Fatal() }→require.True(t, ok)）能降低维护盲区，间接提升安全可审计性 - 所有配置必须放在与
go.mod同级的.golangci.yml中，且 CI 命令必须显式带--config=.golangci.yml，否则 staticcheck 根本不运行
最常被忽略的是：即使配置全对，Go 版本低于 1.21 时 staticcheck 会因缺少类型信息而漏报 SA1019；CI 中务必固定 GOVERSION 并开启 GO111MODULE=on。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
