该传 *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 }）。传它们本身就能修改底层数组或哈希表，加 * 只会让代码更难读、更易出错。

• 错误写法：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 变量本身（比如清空并重新分配底层数组），但这极少见，通常说明设计有问题。