**T 在 Go 中几乎总是错的，因其暴露设计混乱、违背 Go 简洁原则，仅极少数场景（如 Cgo 或需修改指针变量本身）才真正需要。
为什么 **T 在 Go 中几乎总是错的
Go 不支持指针算术，也不鼓励多级间接访问。当你看到 **T 类型，第一反应不应该是“怎么解引用”，而应是“这个设计是否必要”。绝大多数场景下，**T 暴露的是结构混乱：比如本该用切片却用了 *[]T，或本该封装为结构体字段却层层取地址。
真正需要 **T 的典型场景极少，集中在：
- 需要函数修改调用方传入的指针变量本身（不只是它指向的值）
- Cgo 交互中对接 C 函数要求
**T参数（如char **argv） - 某些泛型反射操作（但通常可绕过）
如何安全地解引用 **int 并赋值
假设你已确认必须使用 **int，核心原则是：每级解引用前必须确保非 nil。Go 不会自动 panic 空指针解引用——它直接 panic，且无提示。
正确写法示例：
立即学习“go语言免费学习笔记（深入）”；
var p *int
var pp **int = &p // pp 指向 p，p 当前为 nil
if pp != nil && *pp != nil {
**pp = 42 // 安全赋值
} else {
// 必须显式分配：p = new(int); *pp = p
}
常见错误：
-
**pp = 42前未检查*pp是否为 nil → panic: invalid memory address or nil pointer dereference - 误以为
&&x能生成**T：实际&&x是语法错误；要得**T，必须有中间变量*T - 把
**T当作“更深层的引用”来优化性能：完全无效，反而增加间接跳转开销
替代 **string 的更 Go 风格做法
想通过函数修改一个字符串变量？直接传 *string 就够了：
func setString(s *string) {
*s = "modified"
}
var x string = "original"
setString(&x) // x 现在是 "modified"
如果目标是“让函数能替换整个字符串指针（比如从指向 A 改为指向 B）”，那说明你真正需要的是返回新指针，或用结构体封装：
type StringHolder struct {
Value *string
}
func (h *StringHolder) ReplaceWith(s string) {
h.Value = &s
}
强行用 **string 只会让调用侧代码臃肿：
- 调用方必须先声明
var s *string，再传&s - 无法和
nil字符串字面量自然交互（""是值，不是地址） - 与 Go 标准库惯例（如
flag.String返回*string）不一致
嵌套结构体中的指针字段访问陷阱
真正的“嵌套指针”高频场景其实是结构体字段含指针，例如：type User struct{ Profile *Profile }。这时常见错误不是解引用层数，而是忽略中间层可能为 nil：
u := &User{}
// ❌ 危险：u.Profile 为 nil，u.Profile.Name 触发 panic
// ✅ 应始终检查：
if u.Profile != nil {
name := u.Profile.Name
}
更健壮的做法是封装访问方法：
func (u *User) ProfileName() string {
if u == nil || u.Profile == nil {
return ""
}
return u.Profile.Name
}
Go 的零值语义明确，但不会帮你跳过中间 nil 检查——这是开发者责任，不是语言缺陷。
多级指针本身不难理解，难的是判断哪一级该为 nil、哪一级必须非 nil。与其花时间调试 ***T 的解引用顺序，不如重构掉第二层指针。
