结构体传值无法修改原数据,传指针可以;小结构体且只读宜传值,需修改或较大时宜传指针;接收者类型影响接口实现与方法集;字段用*string仅当需区分nil与"";优先值类型,除非实测拷贝成瓶颈。
核心就一条:func (s Student) SetAge(a int) 改不动原始 Student,func (s *Student) SetAge(a int) 能改。因为前者拿到的是副本,后者拿到的是地址。
type Point {X, Y int}),拷贝开销小,且天然防误改*Student 接收者方法,却对不可寻址的临时值调用——比如 Student{}.SetName("x") 会编译失败,因为 Student{} 是字面量,没地址可取Go 的接口匹配规则很严格:如果一个接口方法是用 *User 接收者实现的,那只有 *User 类型才满足该接口,User 值类型不满足。
var u User; var i fmt.Stringer = u 报错 cannot use u (type User) as type fmt.Stringer,但 i = &u 就行U
ser 的方法集只包含值接收者方法;而 *User 的方法集包含值+指针两种接收者方法*string 还是 string?看语义,不是看大小字段是否用指针,和“能不能改”无关,而和“要不要表达‘未设置’状态”有关。
*string:能区分 nil(未提供)和 ""(明确设为空字符串),适合 API 请求体、配置结构体string:零值 "" 本身就有意义,比如 type Config {Name string},没传 Name 就该是空字符串,不用判 nil
*string 就必须每次解引用前判空,if u.Name != nil { fmt.Println(*u.Name) },漏判直接 panic很多人以为“结构体大就一定传指针”,但实际中,频繁取地址再返回指针,可能让本该在栈上的小对象被迫逃逸到堆,反而加重 GC 压力。
go build -gcflags="-m -l" main.go,看变量是否 “moved to heap”int 字段,也会逃逸runtime.mallocgc 占比异常高)最常被忽略的其实是语义一致性:同一个结构体,有的方法改字段,有的只读,却混用值/指针接收者——这不是语法错误,但会让调用方无法预测行为,也埋下接口匹配隐患。