Go中应避免无必要使用*T，因其降低可读性与维护性；仅当需修改原值或T过大（>128字节）时才传/返回指针，小结构体拷贝更轻量，nil检查泛滥暴露设计缺陷。
Go 语言并不禁止用指针，但大量无必要地使用 *T（尤其是返回指针、传入指针、嵌套指针）确实会显著降低代码可读性和维护性——这不是风格偏好，而是由 Go 的值语义、内存模型和常见误用模式决定的。
为什么 func() *T 比 func() T 更容易让人困惑
返回指针看似“省复制”，但掩盖了两个关键信息：调用方是否要负责生命周期？该值是否可能为 nil？
- 返回
*T后，调用方必须检查if v == nil，否则 panic 风险陡增；而返回T天然安全，零值明确（如struct{}、""、0） - 如果
T是小结构体（比如type Point struct{ X, Y int }），拷贝开销远小于一次内存分配 + GC 压力，此时返回*Point反而更重 - IDE 和文档难以推断“这个
*T是不是总非空”，导致阅读时反复跳转源码确认
传参用 *T 的真实适用场景其实很窄
传指针只在两类情况下真正必要：需要修改原值，或 T 确实巨大（>128 字节且频繁传递）。
- 只读访问
map/slice/chan不需要指针——它们本身已是引用类型，func f(s []int)已能高效读写底层数组 - 传
*string或*int几乎总是过度设计；若真需修改，应考虑函数职责是否过重，或改用结构体封装状态 - 接口类型参数（如
io.Reader）本身就是指针语义，再包一层*io.Reader属于冗余间接层
nil 检查泛滥是滥用指针最直接的副作用
一旦某个类型开始广泛返回或接收 *T，if t == nil 就会像补丁一样散落在各处，破坏逻辑主线。
立即学习“go语言免费学习笔记（深入）”；
- 例如
json.Unmarshal返回*T而非T，就迫使所有调用点加if err != nil || t == nil——而实际上解码失败时err已足够表达错误，nil只是副作用 - 更隐蔽的问题：当多个函数链式调用都返回
*T，一处漏判nil就导致 panic 在深层调用栈爆发，堆栈信息难定位原始责任点 - 静态分析工具（如
staticcheck）对nil敏感度有限，靠人眼审查极易遗漏
真正影响可读性的从来不是语法符号本身，而是指针引入的隐式契约：谁分配？谁释放？能否为空？是否共享？这些本该由类型和函数签名显式表达的约束，一旦退化为“看文档”或“看实现”，就已输了第一步。
