& 和 是同一内存地址的两个互补操作：& 从值获取地址， 从地址取值；二者非语法糖，而是直接对应底层指令，使用时需严格匹配类型与有效性。
为什么 & 和 * 总是配对出现却行为相反
因为它们本质是同一内存地址的两个视角：& 是“从值出发找地址”，* 是“从地址出发取值”。不是语法糖，是编译器直接生成的底层指令——&x 拿的是变量 x 在栈上的起始字节偏移，*p 则按 p 存的地址去读一块内存，大小由指针类型决定。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference，基本等于你用了 * 却没确保指针非 nil；或者传了 &x 给一个期望 *int 的函数，但误以为它会自动解引用。
-
&只能作用于可寻址对象（变量、结构体字段、切片元素），不能用于字面量或函数调用结果，比如&42或&fmt.Sprintf("x")会编译报错cannot take the address of ... -
*要求操作数是具体指针类型，*int不能直接解引用*string，类型必须严格匹配（接口指针除外） - 如果函数参数是
*T，你传&x是对的；但如果函数返回*T，别急着*ret——先检查ret != nil
什么时候必须用指针传参而不是值传参
核心判断依据只有两个：是否需要修改原变量，以及值是否过大。Go 所有传参都是值传递，所谓“传指针”只是把地址这个整数值拷贝过去。
使用场景：修改 map/slice/chan 以外的变量内容；避免大结构体拷贝；实现接口时方法集一致性要求（接收者为指针才能满足 *T 实现某接口）。
立即学习“go语言免费学习笔记（深入）”；
- 小结构体（如
type Point struct{ X, Y int }）值传参更高效，指针反而多一次内存访问 - 含 slice/map/chan 字段的结构体，即使本身小，也建议用指针——否则副本里的引用仍指向原底层数组，改数据会互相影响，但字段地址本身不共享
- 方法接收者用值还是指针，看是否要修改字段；如果多个方法中有的改、有的不改，统一用指针接收者，避免编译器报错
method set mismatch
new() 和 &T{} 都能创建指针，区别在哪
两者都返回 *T，但初始化逻辑不同：new(T) 返回指向零值的指针，&T{} 返回指向字面量初始化的指针（字段可显式赋值）。
性能上无差异，都是分配堆或栈内存；但语义和可读性差别明显——new 已基本被社区弃用，Go 代码里几乎只在泛型约束或极少数兼容场景出现。
-
new(int)→*int指向0；&int{42}→*int指向42 -
&struct{a,b int}{}是合法的，new(struct{a,b int})语法也合法但难读，且无法初始化字段 - 切片、map、chan 类型不能用
new初始化（它们本身是引用类型，零值已可用），但可以用&[]int{}得到指向切片头的指针——极少用，容易引发混淆
nil 指针解引用不是 bug，而是设计选择
Go 不做空指针防护，*p 遇到 p == nil 直接 panic。这不是疏忽，是明确拒绝隐式默认行为——比如 C++ 的 operator* 重载可能返回代理对象，Go 强制你面对“地址无效”这个事实。
容易踩的坑：在 defer、recover 中漏判指针有效性；或把 nil 指针当成“空值”来用（比如认为 *string 为 nil 就等于空字符串），其实它连字符串头都没分配。
- 检查指针是否为空，写
if p != nil { *p = ... }，不要写if *p != ""（这行就 panic 了） - 函数返回
*T时，文档或注释应明确说明是否可能返回nil；调用方必须处理，不能假设“反正有默认值” - 结构体字段为
*T时，JSON 反序列化遇到缺失字段会设为nil，不是零值——这点和值类型字段行为完全不同
指针真正的复杂点不在语法，而在于它把“生命周期”和“所有权”推给了人脑判断。栈上变量的地址传出去后，谁保证它没被回收？堆上分配的指针，谁负责释放？Go 用 GC 解决后者，但前者——比如把局部变量地址传给 goroutine——只能靠你盯住逃逸分析输出和代码路径。
