golangci-lint 本身不检查嵌套层级，无内置 linter 支持直接检测 if/for/switch 嵌套深度；需通过 gocyclo 计算圈复杂度（如 min-complexity: 6）间接约束，配合提前返回和函数提取来治理。
golangci-lint 本身不检查嵌套层级
直接说结论：golangci-lint 没有内置 linter 能检测 if/for/switch 的嵌套层数。它不提供类似 ESLint 的 max-depth 或 Python 的 flake8 --max-complexity 这类配置项。所谓“限制嵌套层级”，实际要靠其他 linter 配合人工识别，或用圈复杂度（cyclomatic complexity）间接反映。
用 gocyclo 检测圈复杂度，间接约束嵌套
gocyclo 是 golangci-lint 官方集成的 linter，它计算函数的圈复杂度（McCabe 数），值越高通常意味着分支多、嵌套深、可读性差。默认阈值是 10，但实践中建议调低到 6–8。
- 在
.golangci.yml中启用并设限：
linters-settings:
gocyclo:
min-complexity: 6
- 这个值不是“嵌套层数”，而是：每增加一个
if、for、case、&&、||等控制流分支，复杂度 +1 - 比如一个函数含 3 层 if 嵌套 + 2 个 for 循环 + 1 个 switch，复杂度至少是 7，就会被报错
- 它比数缩进更可靠——能捕获
if a && b && c这种“扁平但逻辑稠密”的情况
为什么不用 nesting-depth 类似工具？
Go 生态中没有成熟、稳定、被 golangci-lint 官方支持的 “nesting depth” linter。社区曾有实验性工具（如 go-nest），但未进入主流集成列表，且容易误判闭包、匿名函数、method chain 等合法结构。官方推荐路径始终是：gocyclo + 提前返回（early return）+ 提取函数（extract function）。
- 常见误报场景：
func (r *Repo) Get(...) { if err != nil { return nil, err } ... }——这种单层防御性检查不增加实质嵌套，但某些深度计数器会错误计入 - 真正危险的是：
if x { if y { if z { ... } } }，而gocyclo对它打分 4，立刻暴露 - 重构信号明确：当
gocyclo报警时，优先考虑拆出子函数，而不是硬压缩缩进
嵌套过深的真实代价不是风格问题，而是 nil 处理失效
Go 里嵌套最常掩盖的 bug 是 error 和 nil 检查被遗漏或错位。例如：
立即学习“go语言免费学习笔记（深入）”；
if user != nil {
if user.Profile != nil {
if user.Profile.Avatar != nil {
// 这里才用 Avatar.URL
}
}
}
这段代码看似严谨，实则违反 Go 的错误处理惯用法。正确写法应是提前返回：
if user == nil {
return errors.New("user is nil")
}
if user.Profile == nil {
return errors.New("profile missing")
}
if user.Profile.Avatar == nil {
return errors.New("avatar missing")
}
// 此处 Avatar.URL 可安全使用
这种写法天然降低嵌套，也避免 nil 接口 vs nil 具体类型这类 Go 特有陷阱。所以，别把嵌套当格式问题——它是类型系统薄弱环节的放大器。
