该传 *T 而不是 T 的核心判断标准是：是否需要修改调用方原始值且类型体积大或语义要求可变；否则优先传 T，避免不必要的 nil 检查与风险。
什么时候该传 *T 而不是 T
核心判断标准：是否需要函数内部修改调用方的原始值，且该类型体积较大（如结构体）或语义上明确要求“可变”。
Go 中所有参数都是值传递，T 会复制整个值；*T 复制的是指针（8 字节），开销固定。但指针带来可变性风险——哪怕只是读取，也可能因并发或误写导致意外修改。
常见误用场景：为一个只读的 string 或 int 加 *，既无必要又增加 nil 检查负担。
- 必须用
*T：函数需修改结构体字段（如user.SetName("x")）、初始化未导出字段、或避免大结构体拷贝（>128 字节建议测一下） - 优先用
T：基础类型（int、string、bool）、小结构体（如type Point struct{ X, Y int }）、纯计算函数（如Normalize(v Vector) Vector） - 接口值本身已是指针语义：接收
io.Reader不需要写*io.Reader，因为接口底层包含指针
nil 检查不是可选动作，而是接口契约的一部分
一旦函数签名接受 *T，调用方就可能传 nil。不检查直接解引用会 panic：panic: runtime error: invalid memory address or nil pointer dereference。这不是防御性编程的“礼貌”，而是明确定义函数行为边界的必需步骤。
- 在函数入口立即检查：
func ProcessUser(u *User) error { if u == nil { return errors.New("user cannot be nil") } // 后续安全使用 u.Name, u.ID 等 } - 不要把
nil检查推迟到深层逻辑（如某个字段赋值前），那会让错误位置难以定位 - 若业务逻辑允许
nil（如可选配置），应显式命名参数并文档化，例如opts *ProcessOptions并注明 “nil means defaults”
方法接收者用 *T 还是 T？看是否要改状态
这和函数参数逻辑一致，但更易混淆——因为 Go 允许对 T 类型值调用 *T 接收者方法（编译器自动取地址），反之则不行。这种隐式转换掩盖了真实意图。
- 用
*T接收者：方法会修改接收者字段（如func (u *User) SetEmail(e string) { u.Email = e }） - 用
T接收者：方法只读，且不希望调用方意外传入指针（比如防止并发写同一对象）；也适用于不可寻址值（如字面量User{}.Name()） - 混用危险：同一个结构体上既有
T又有*T方法，会导致方法集分裂——var u User只能调用T方法；var u *User能调用全部。这会让使用者困惑，也不利于接口实现一致性
切片、map、channel 本身已是引用类型，别画蛇添足加 *
这是新手高频踩坑点：[]int、map[string]int、chan int 在底层都是包含指针的结构体（如 slice 是 struct{ ptr *int, len, cap int }）。传它们本身就能修改底层数组或哈希表，加 * 只会让代码更难读、更易出错。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
func AppendItem(items *[]int, x int)—— 需要双重解引用*items = append(*items, x)，且调用时得写&mySlice - 正确写法：
func AppendItem(items []int, x int) []int—— 返回新切片，由调用方决定是否赋值：mySlice = AppendItem(mySlice, 42) - map 和 channel 同理：传
map[string]int就能直接m["k"] = v，无需*map
真正需要指针的，是想替换整个 map 变量本身（比如清空并重新分配底层数组），但这极少见，通常说明设计有问题。
