go没有“未捕获异常”概念，所谓漏洞实为两类问题：不该panic却panic，或该处理error却忽略；goland无法直接搜索此类逻辑缺陷，需结合find in files搜panic(并检查recover是否在defer中、启用inspection检测未使用的error、辅以govulncheck和deadcode等工具排查深层风险。
GoLand 里根本搜不到“未捕获异常”
Go 没有传统意义的“异常”，panic 不是异常，error 也不是异常——它俩都不触发栈展开，也不需要“捕获”。所谓“未捕获异常漏洞”，在 Go 里其实是两类问题混在一起说的：不该 panic 却 panic 了，或者该处理 error 却忽略了。GoLand 的搜索功能没法直接定位这类逻辑缺陷，因为它们不是语法错误，而是控制流疏漏。
搜 panic 调用但没配 recover 的地方
这是最接近“未捕获异常”的真实场景：你在某处手动调用了 panic（比如解析配置失败、初始化出错），但周围没有 defer func() { recover() }() 包裹，导致服务直接崩溃。
- 用 GoLand 的「Find in Files」搜
panic(，排除测试文件（加-test.go过滤） - 重点检查：配置加载、全局变量初始化、
init()函数、HTTP handler 入口前的校验逻辑 - 注意别漏掉间接调用：比如某个工具函数里有
panic，而你调用它时没意识到——得顺藤摸瓜看调用链 -
recover()必须在同一个 goroutine 的defer里直接调用，搜到recover()后要人工确认它是否在defer函数体中、是否在panic可能发生的路径上
找被忽略的 err != nil 分支
这才是更常见、更隐蔽的“漏洞”：函数返回 error，你写了 if err != nil { ... }，但里面只打日志或什么都不做，没返回 HTTP 错误码、没中断流程、没传播错误——结果请求看似成功，实际逻辑已中断。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- GoLand 自带的「Inspection」可启用 “Error return value not used”（Settings → Editor → Inspections → Go → Error return value not used）
- 但它对以下情况无效：赋值给下划线
_, err := doSomething()、用err做条件判断但没处理、或把err传给另一个函数却不检查它的返回值 - 真正要盯的是 handler 函数末尾是否总有一个明确的响应：比如
c.JSON(...)或c.Error(...)是否覆盖所有分支，尤其else和default路径 - 别信
log.Printf("err: %v", err)就算处理了——它不等于业务错误响应
用 govulncheck 和 deadcode 补漏
这两工具不搜“异常”，但能暴露因错误处理缺失导致的深层风险：
-
govulncheck .扫描依赖中已知会触发 panic 的漏洞（比如某些 JSON 解析器在恶意输入下 panic）——这些 panic 如果没被中间件 recover，就是线上崩溃点 -
deadcode -all ./找出定义了但从没被调用的 error 处理函数（比如你写了handleDBError()，但所有 DB 调用都忽略 err）——说明那套错误处理逻辑根本没生效 - 结合
go vet -shadow检查作用域内err变量是否被重复声明掩盖，导致外层 err 检查失效
真正的风险不在语法层面，而在控制流是否闭合：每个可能出错的点，是否都有明确的 error 处理出口，以及每个手动 panic 是否都在可控范围内被拦截。工具只能提示线索，最终得靠人沿着调用链走一遍。
