Go始终是值传递，传指针实为传指针副本；真正影响维护的是权限归属、副作用感知及隐式逃逸导致的内存泄漏与竞态问题。
Go 里传指针 ≠ 为了“修改原值”
很多人初学 Go 时看到 & 和 *，第一反应是“要改原来的变量”，结果在函数里对参数做 *p = ...，却发现调用方变量没变——其实是因为传进去的是指针的副本。Go 始终是值传递：func f(p *int) 中的 p 是一个新分配的指针变量，它和调用方的指针变量地址不同，只是初始值指向同一块内存。
真正影响维护成本的，不是“能不能改”，而是“谁有权限改”“改了之后谁会感知到副作用”。比如：
- 结构体字段被多个地方通过指针访问并修改，追踪赋值源头变得困难
- 一个
*User被传给日志、缓存、数据库写入三处，其中一处做了u.Name = "xxx"，其他地方读到的就是脏数据 - 函数签名看起来安全（比如只读接口），但内部偷偷解引用并修改了底层数据
struct 字段含指针时，深拷贝几乎必然出错
Go 没有内置深拷贝，copy() 只能用于 slice，encoding/gob 或 json.Marshal/Unmarshal 会绕过私有字段或 panic。当 struct 含 *string、map[string]*T 这类字段时，直接赋值（b = a）会让两个变量共享所有指针目标，后续任意一方修改都会影响另一方。
常见踩坑场景：
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 中把请求解析出的
*RequestData直接塞进 goroutine 处理，而主 goroutine 同时复用了该 struct —— 数据竞态 - 测试中构造 fixture 时用
original := &MyStruct{...}，然后test1 := *original，以为是复制，实际所有指针字段仍指向原内存 - 用
reflect.DeepCopy（非标准库）或第三方库时，忽略未导出字段或 interface{} 值的深层引用
interface{} + 指针组合让类型逃逸更隐蔽
当函数接收 interface{} 并内部做 if v, ok := x.(*MyStruct); ok { *v = ... }，这种逻辑极难被静态分析捕获。调用方传入一个栈上分配的 MyStruct 变量（如 f(MyStruct{})），Go 编译器会自动将其逃逸到堆上——因为要取地址传给接口。这个逃逸不体现在函数签名里，也不报错，但会导致 GC 压力上升、缓存局部性下降。
更麻烦的是维护者无法从函数名或参数名判断是否发生逃逸。例如：
func Process(v interface{}) {
if p, ok := v.(*bytes.Buffer); ok {
p.WriteString("log")
}
}
这个函数看似泛型，实则对 *bytes.Buffer 有强假设，且强制所有传入的 *bytes.Buffer 实例必须堆分配。一旦后期有人改成传 bytes.Buffer{}（值类型），就会 panic。
nil 指针解引用不是唯一风险，空接口包装指针才是维护黑洞
比运行时 panic 更难调试的，是空接口间接持有指针后引发的隐式生命周期延长。比如：
- 把
*Config存进context.WithValue(ctx, key, cfg)，而 context 生命周期远长于 config 创建作用域，导致 config 所指内存无法回收 - 用
sync.Map存*Item，但忘记清理过期 key，Item 结构体里又有*http.Client，最终泄漏整个 HTTP 连接池 - ORM 返回
[]*Model，上层代码转成interface{}传给模板引擎，模板里调用.Field触发反射，此时哪怕 Model 字段是值类型，整个对象图仍被强引用
这类问题不会在编译时报错，也不会立刻 panic，而是在压测时出现内存缓慢上涨，或者上线数天后连接耗尽——定位时往往要翻三四层调用链，才能发现最初那个 &config 被塞进了某个全局 map。
