Alt+Enter仅自动修复IDE静态可识别的指针错误，如nil解引用、未初始化指针字段访问、new(T)后直接使用嵌套指针字段；不处理运行时逻辑缺陷（如map查无key、json未检查）。
Alt+Enter 能自动修复哪些指针类型错误？
它不处理所有指针问题，只覆盖 IDE 静态分析能明确识别的几类：nil 解引用、未初始化指针字段访问、new(T) 后直接使用嵌套指针字段、接口变量误判为非 nil。对 map[string]*User 查不到 key 导致的 u.Name panic，或 json.Unmarshal 后未检查的 *User，Alt+Enter 不触发修复——这些属于运行时逻辑缺陷，IDE 无法推断数据流。
常见可修复场景包括：
-
var u *User; fmt.Println(u.Name)→ Alt+Enter 提供 “Add nil check before dereference” -
func (u *User) GetName() string { return u.Name }中u.Name标红 → 快速修复插入if u == nil { return "" } -
p := new(User); p.Profile.Name = "x"（Profile是*Profile）→ 提示 “Dereference of possibly nil pointer”，修复建议加if p.Profile != nil
为什么 Alt+Enter 有时不弹出指针修复选项？
不是功能失效，而是条件不满足。最常被忽略的三个前提：
- 当前文件必须属于一个已识别的 Go module（右下角显示
Go SDK: 1.26.0且项目根目录有go.mod） - Nil pointer dereference 检查需手动启用：Settings > Editor > Inspections > Go >
Nil pointer dereference（默认可能关闭） - 光标必须落在被解引用的表达式上，比如
u.Name的Name上，而不是u或分号处
若悬停提示是 Unresolved reference 而非 possible nil pointer dereference，说明 GoLand 认为该符号根本不存在（如包未导入、拼写错误），此时 Alt+Enter 会优先提供 import 补全或重命名建议，而非 nil 检查。
修复后代码仍 panic？检查这三点
Alt+Enter 插入的判空只是“语法安全”，不等于“逻辑安全”。容易漏掉的硬伤：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 判空位置不对：
if u != nil { u.Profile.Name }无效，因为u.Profile本身可能是 nil，得拆成两层判断 - 接口变量陷阱：
var i interface{} = (*User)(nil)，此时i == nil为 false，Alt+Enter 不提示，需用reflect.ValueOf(i).IsNil() - 并发写入竞争：
u在判空后、解引用前被其他 goroutine 置为 nil，Alt+Enter 不也无法插入锁，得靠人工加sync.RWMutex
这类问题 Alt+Enter 不会覆盖，它只解决静态可判定的单线程路径风险。
想跳过某处指针检查？用 suppression 注释
别关全局检查，局部压制更精准。正确做法是悬停在标红代码上 → 看 tooltip 底部找 Inspection 'GoNilness' options → Alt+Enter → 选 “Suppress for statement”。IDE 自动生成：
//noinspection GoNilness fmt.Println(u.Name)
注意：GoNilness 是固定 ID，不是随便写的文字；suppress for function 会加在函数开头，suppress for file 会加在文件顶部；禁用后该位置不再标红，但编译和运行时 panic 依然会发生。
真正难的从来不是加那行 if p != nil，而是想清楚：这个指针本该在哪儿初始化？谁负责保证它非 nil？Alt+Enter 只是把“写判空”自动化了，没把“设计责任”拿走。
