go中指针是控制数据所有权和共享行为的基本工具：值传递复制数据，指针传递共享内存；结构体传参、方法接收者、接口实现及nil判空均依赖此本质区别。
Go 中指针不是“高级技巧”，而是控制数据所有权和共享行为的基本工具；普通变量存值，指针存地址——这个区别直接决定函数能否修改原变量、结构体传参是否卡顿、方法调用是否 panic。
为什么 modify(x int) 改不了原值，但 modify(&x) 可以
Go 所有参数传递都是值传递，关键在于“传的是什么的值”：
-
modify(x int)：传的是x的副本，函数内改x= 改一张复印件，原变量毫发无损 -
modify(p *int)：传的是地址的副本（比如0xc000012340），虽是地址的拷贝，但两个地址指向同一块内存，*p = 100就是往那块内存写入
常见错误现象：func setName(p Person) { p.Name = "Alice" } 调用后 Person 原值没变——因为传的是整个 Struct 的拷贝，不是地址。
大型 struct 传值 vs 传指针，性能差多少
假设有个 type BigData struct { Items [1e6]int }（约 8MB）：
立即学习“go语言免费学习笔记（深入）”；
- 值传递：
process(b BigData)→ 每次调用都复制 8MB 内存，GC 压力陡增，延迟明显 - 指针传递：
process(b *BigData)→ 只传一个 8 字节地址，开销恒定
实操建议：只要 struct 字段超过 4–5 个基础类型，或含 slice/map/channel，优先用 *T 传参；标准库中 http.Request、sql.Rows 全部是指针类型，不是巧合。
方法接收者用 func (t T) M() 还是 func (t *T) M()？
这不是风格问题，而是接口实现和可变性的硬约束：
- 如果方法要修改接收者字段（如
t.Counter++），必须用指针接收者*T，否则改的是副本 - 如果类型实现了某个接口，而该接口中**任一方法**用了指针接收者，则只有
*T类型能赋值给该接口，T类型会编译报错：T does not implement X (M method has pointer receiver) - 即使所有方法都只读，也建议统一用
*T接收者——避免后续加修改逻辑时被迫重构所有调用点
典型坑：var u User; fmt.printf("%v", u) 没问题，但 var i fmt.Stringer = u 编译失败，只因 User.String() 是指针接收者。
指针的零值是 nil，值类型的零值是具体值——这影响初始化和判空逻辑
这是最易被忽略的语义差异：
-
var s string→s == ""，安全使用 -
var p *string→p == nil，解引用前必须检查：if p != nil { use(*p) }，否则 panic:invalid memory address or nil pointer dereference - struct 字段含指针时（如
type Config struct { DBURL *string }），jsON 反序列化可能留nil，直接*c.DBURL会 crash
真正复杂的地方不在语法，而在于：你得时刻判断——这个变量，我到底想让它「独立」还是「共享」？想隔离就用值，想联动就用指针；想省事就用值，想高效就用指针；但一旦混用，bug 往往出现在边界处，比如 nil 指针解引用、接口赋值失败、或以为改了实则没改。