传指针修改原值不一定产生副作用，仅当函数内对*p执行写操作（如赋值、调用可变方法）时才发生；只读访问无副作用。
传指针时修改原值是否必然产生副作用
不是。副作用是否发生，取决于函数内部是否对 *p 所指向的内存执行了写操作。只读访问（如打印、计算）不会改变原值；但一旦出现 *p = ...、p.field = ... 或调用会修改接收者的指针方法，副作用就产生了。
常见误判场景：
- 把
func f(p *int) { *p++ }当作“只是加1”，忽略它直接改了调用方的变量 - 传入结构体指针后，调用其
SetX()方法（该方法接收者为*T），却没意识到这等价于(*p).SetX() - 在 goroutine 中并发写同一指针指向的数据，未加锁——这不是“副作用”而是数据竞争
如何安全地用指针参数避免拷贝又不破坏原数据
核心原则：明确区分「输入」和「输出」意图。Go 没有 const 指针语法，只能靠约定和设计约束。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只读场景优先用
func f(v T)（值传递）+func (t T) Read() ...方法，避免传指针；小结构体（≤机器字长，如struct{a,b int}）拷贝成本极低 - 必须传指针且只读时，函数名或注释明确标注
// ReadOnly，并在函数开头加断言式注释：// DO NOT assign to *p or call mutating methods on *p - 若需返回新状态而非修改原值，改用返回值：
func normalize(p *Point) Point { return Point{p.X*2, p.Y*2} }，而不是就地修改
哪些类型传指针性价比高，哪些反而更慢
传指针的收益不只看大小，还要看逃逸分析结果和内存局部性。盲目传指针可能触发堆分配，反而更慢。
典型情况对比：
-
[]byte、string、map、chan、func：本身是头信息（含指针字段），传值开销固定且很小，**无需额外取地址**；传*[]byte反而多一层间接寻址，还可能让底层数组逃逸到堆 - 大结构体（>64 字节）：如图像帧
type Frame struct{ Data [1024*768]byte }，传值会拷贝整块内存，此时*Frame更优 - 小结构体但含指针字段（如
type User struct{ Name *string; Age int }）：传值只拷贝指针和 int，很快；传指针无必要，还增加 nil 检查负担
func processLarge(large *BigStruct) { /* OK: avoids copy */ }
func processSlice(s []int) { /* OK: slice header is 24 bytes, cheap */ }
func processPtrToSlice(ps *[]int) { /* Avoid: adds indirection, may force s to heap */ }调试指针副作用的实用技巧
Go 运行时不报“你改了不该改的内存”，得靠主动防御。
可立即上手的方法：
- 启用
go run -gcflags="-m" main.go查看变量是否逃逸；若本该栈分配的变量被标为 “moved to heap”，说明传指针可能已影响优化 - 用
reflect.ValueOf(x).CanAddr()+.CanInterface()在运行时判断能否安全取地址（仅限调试，勿用于逻辑分支） - 单元测试中，对输入参数做深拷贝（
copier.Copy()或手动 clone），再比对前后值：if !reflect.DeepEqual(before, after) { t.Fatal("unexpected mutation") } - 对关键结构体实现
Clone() *T方法，在函数入口显式复制：safe := original.Clone(); process(safe)
最易被忽略的是：nil 指针解引用 panic 不是副作用，而是崩溃；而静默修改共享状态（比如全局配置指针被意外覆盖）才真正难排查。
