goland默认启用“unhandled error”检查，专门检测os.open、json.unmarshal等返回error却未判断（如缺少if err != nil）的调用点，可通过settings→editor→inspections→go中确认其启用状态及严重级别。
“Unhandled Error”检查是否启用
GoLand 默认开启 Unhandled Error 检查，但部分团队会禁用或调低严重级别，导致问题不被高亮。它专门检测函数返回 error 但未做任何判断（比如没写 if err != nil）的调用点。
确认方式：打开 Ctrl+Alt+S → Editor | Inspections → 展开 Go → 找到 Unhandled Error，确保勾选且 Severity 设为 Warning 或更高。
- 如果该检查被禁用，所有未处理错误都不会标记，哪怕代码明显漏判
- 它对
defer中的Close()、json.Unmarshal()、os.Open()等常见易错函数敏感 - 支持排除特定函数名：在检查设置里填
fmt.Printf,log.Print等你明确不想检查的调用
快速定位并批量修复未处理 error
光标停在任意一处红色波浪线（或黄色警告）上按 Alt+Enter，菜单里会出现 “Handle error” 快速修复项 —— 这不是模板补全，而是基于上下文生成带 if err != nil 的分支逻辑。
若整个文件有大量同类问题，别一个个点：右键编辑器 → Code | Code Cleanup... → 选择作用域（如当前文件）→ 勾选 Unhandled Error 对应的清理项 → 点击 Analyze。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 修复会保留原表达式结构，只插入最小必要包裹，比如
f, _ := os.Open(...)会被转成f, err := os.Open(...); if err != nil { ... } - 不会自动加
return或panic，需人工确认错误处理策略 - 若函数签名含多个返回值（如
(int, string, error)），修复后可能需手动调整变量名避免冲突
为什么有些 error 调用没被检查出来
Unhandled Error 不是语法扫描，它依赖数据流分析（DFA）。以下情况会导致漏报：
- error 被赋给变量但变量后续未使用（如
err := doSomething(); _ = err） - error 被传入另一个函数但未被消费（如
log.Println(err)不算“处理”，只是输出） - 调用链过深或跨包时，DFA 可能无法准确追踪 error 是否最终被检查
- 使用了自定义 error 包装（如
errors.Wrap）但未启用对应插件支持
此时需配合 Find Usages 查看该函数所有调用点，手动审计；或启用 Data flow analysis 高级模式（Settings → Editor → Inspections → Go → Data flow analysis）增强检测深度。
容易忽略的边界场景
真正危险的不是裸奔的 os.Open()，而是那些“看起来已处理”的假象：
-
if err != nil { log.Println(err) }—— 日志 ≠ 处理，检查仍会触发 -
if err != nil { return err }在非 error 返回函数中直接报错（编译失败），但检查可能因类型推导失败而跳过 - goroutine 内部调用（
go func() { _, err := http.Get(...) }）—— error 完全丢失，检查通常无法捕获 - interface{} 类型接收 error（如
func Handle(v interface{})）—— 静态分析无法确定 v 是否为 error
这些地方必须靠人工 code review 或单元测试覆盖，IDE 的静态检查帮不上忙。
