会崩溃，且是运行时 panic；局部变量栈上分配，函数返回后地址不可访问，编译器仅能静态捕获部分情况，间接取地址可能延迟至运行时崩溃。
返回局部变量地址会崩溃吗
会，而且是运行时 panic。Go 编译器对 return &localVar 有静态检查，但并非所有情况都能捕获——比如在闭包、循环内取地址，或通过中间函数转发时，可能绕过检查，最终触发 invalid memory address or nil pointer dereference。
- 栈上分配的局部变量在函数返回后生命周期结束，其地址不可再访问
- 编译器通常能检测到直接返回局部变量地址，报错
cannot take the address of … - 但若通过切片元素、结构体字段、或 map 值间接取地址（如
&s[0]、&x.field），可能仅在运行时崩溃
什么情况下该返回指针而非值
核心判断依据是：是否需要「可变性共享」或「避免拷贝开销」。不是“习惯性加 *”，而是明确设计意图。
- 结
构体较大（如超过 32 字节）且频繁传递时，返回
*T减少内存复制 - 需要函数调用后修改原值（例如初始化配置、构建链表节点），必须返回指针
- 类型实现了接口，且需保持指针接收者方法可用（如
(*bytes.Buffer).Write），返回*T才能调用这些方法 - 返回
nil表示“未初始化”或“可选缺失”语义（如func NewConfig() *Config）
new(T) 和 &T{} 哪个更合适
二者都分配堆内存并返回 *T，但语义和可读性不同：&T{} 更常用、更清晰；new(T) 仅适用于零值初始化且无字段赋值场景。
-
&T{}显式构造，支持字段初始化（如&User{Name: "Alice"}），推荐用于绝大多数情况 -
new(T)总是返回零值指针，无法设置字段，等价于&T{}但更隐晦，仅在泛型或反射等底层场景偶见 - 注意：
&struct{}{}是合法的，但new(struct{})也合法——不过空结构体指针几乎无意义，慎用
func CreateUser(name string) *User {
return &User{Name: name, CreatedAt: time.Now()} // 清晰、可控
}
func ZeroUser() *User {
return new(User) // 不推荐：无法设字段，不如直接写 &User{}
}
返回 nil 指针的安全边界在哪
返回 nil 指针本身安全，但调用方必须主动判空。Go 不提供空指针自动防护，错误常出现在未检查就解引用。
- 函数文档或命名应暗示可空性（如
FindUser()可返回nil，MustGetUser()则 panic） - 避免在返回前做
if x == nil { return nil }这类冗余判断——除非你是在封装底层可能返回 nil 的逻辑 - 切片、map、channel 类型本身是引用类型，不应返回其指针（如
*[]int），这违背 Go 习惯且增加复杂度
最容易被忽略的是：指针字段的深层嵌套判空。比如 u.Profile.Address.Street，中间任一环节为 nil 都会 panic，不能只检查顶层指针。
