Go 里 **T 不是“指向指针的指针”，而是“指向 *T 类型变量的指针”
很多人看到 **T 就下意识类比 C 的二级指针，结果在取地址、传参或解引用时 panic。根本原因是 Go 没有“指针类型”的指针这一概念——**T 只能指向一个 *T 类型的变量，不能指向任意表达式（比如 &x 这样的临时地址）。
常见错误现象：invalid operation: cannot take address of &x (operand is a pointer) 或运行时 panic: runtime error: invalid memory address。
- 必须先声明一个
*T类型的变量，再对它取地址才能得到**T -
**T不能直接由&(&x)构造（Go 禁止对取址表达式再取址） - 函数接收
**T参数时，调用方必须传入一个已命名的*T变量的地址，不能传&p（其中p := &x是局部变量声明）
示例：
var x int = 42 p := &x // p 是 *int pp := &p // pp 是 **int，合法 fmt.Println(**pp) // 输出 42
什么时候真需要 **T？不是为了“多一层抽象”，而是为了修改指针本身
单级指针 *T 能让你改 T 的值；**T 才能让你改那个 *T 变量存的是哪个地址——典型场景是函数内需重置/替换外部指针目标。
立即学习“go语言免费学习笔记（深入）”；
使用场景：
- 实现类似 C 的
realloc行为：函数内部分配新内存，并让调用方的指针指向它 - 链表节点插入时，需要修改前驱节点的
next字段（该字段本身是*Node），而你拿到的是**Node（比如头指针的地址） - 某些 Cgo 回调中需更新 Go 端持有的 C 指针变量
反例：如果只是想在函数里改结构体字段，传 *T 就够了；用 **T 属于过度设计，还增加 nil 判断层级。
**T 解引用时的 panic 风险比 *T 高得多
一次解引用 *p 失败，通常只因 p == nil；但 **pp 要安全执行，得同时满足两个条件：pp != nil 且 *pp != nil。漏判任一环节就会 panic。
容易踩的坑：
- 忘记检查
*pp是否为 nil，直接写**pp = 123 - 把未初始化的
**T变量（值为 nil）直接解引用 - 在 map 或 slice 中存储
**T，但没确保中间层指针被正确赋值
建议始终显式判断：
if pp != nil && *pp != nil {
**pp = newValue
}与 C 的关键差异：Go 的 **T 无法做算术运算，也不支持 void\*\* 等泛型指针模拟
Go 没有指针算术，所以 **T 不能像 C 那样用于遍历指针数组（如 argv）；也没有 void** 这种通用二级指针类型。这意味着你没法用一个统一的 **interface{} 去承接任意 **T。
实际影响：
- 无法用
**T模拟动态二维数组（得用[]*T或[][]T） - 想封装“可变指针”逻辑时，必须借助接口或泛型，不能靠裸指针转型
- Cgo 中若需传递
**C.int，必须严格匹配 C 端期望的内存布局，不能用 Go 的**int直接转换
真正难的从来不是语法，是记住：Go 的指针是类型安全的容器，不是内存地址的自由操作符。多一级解引用，就多一层类型约束和生命周期依赖。
