golangci-lint 不检测数组/切片越界隐患，因其属运行时保护，静态分析无法推断变量索引路径；go vet 仅报字面量越界，staticcheck 可识别部分模式化风险，但 append 后混用新旧切片等静默覆盖问题仍难发现。
golangci-lint 本身不检测数组/切片越界隐患
它不会报 index out of range 类运行时 panic 的潜在位置。这类边界检查属于编译器阶段插入的运行时保护，静态分析工具无法在不执行的情况下推断所有索引路径是否安全——尤其当索引来自变量、循环计数器或外部输入时。
你看到的 golangci-lint run 输出里没有“越界警告”，不是配置漏了，而是它压根不干这事。想靠 linter 拦住 s[i] 越界，就像指望拼写检查器发现语义错误一样，不在能力范围内。
真正能抓到越界隐患的是 go vet 和 staticcheck
go vet 在部分场景下会提示明显静态可判的越界，比如字面量索引超长：
nums := [3]int{1,2,3}
_ = nums[5] // go vet 会报 "array index 5 out of bounds [0:3]"
staticcheck（常通过 golangci-lint 启用）则更进一步，能识别一些模式化风险：
- 循环中用
i 代替i —— 它会标出SA4001 - 对
s[i:j]截取时，j明显大于len(s)的字面量表达式 - 调用
strings.Index后直接用返回值做切片索引，却没检查是否为-1
但注意：这些都依赖“编译期可确定的常量或简单推导”。一旦索引是函数返回值或用户输入，它们就沉默了。
如何让 golangci-lint 启用相关检查项
你需要显式开启 staticcheck 和 govet，默认配置可能关掉部分子检查：
- 在
.golangci.yml中确认包含：enable:下有govet和staticcheck - 若需更细粒度控制，加
enable-all: true或单独启用SA4001（循环边界）、SA1019（已弃用 API 引发的越界风险） - 运行时加
--fast会跳过staticcheck，务必去掉
示例最小配置片段：
linters-settings:
staticcheck:
checks: ["all"]
govet:
check-shadowing: true
enable:
- govet
- staticcheck
越界问题最终得靠代码习惯和运行时防护兜底
静态工具只能帮到这一步。真实项目里最有效的防线是：
- 所有外部输入索引，先做
if i = len(s)判断，别信“前端传来的一定合法” - 避免裸写
s[i]，封装成safeGet(s, i)返回(T, bool)，强制调用方处理失败分支 - 对关键路径用
go build -gcflags="-d=checkptr"运行时检测指针越界（含 slice 底层数组越界） -
defer/recover只用于顶层 panic 捕获，不能替代边界检查——它成本高，且掩盖了本该修复的逻辑缺陷
最易被忽略的一点：append(s, x) 后如果继续用原 s 的旧长度遍历，或者把扩容后的切片和旧切片混用，这时越界不会立刻 panic，但数据会被静默覆盖。这种隐患，连 staticcheck 也看不到。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
