Go 中私有结构体的公有方法：封装性与接口抽象的核心实践

在 Go 的世界里，有一个设计模式经常被提及，但很多人并没有真正吃透它的精髓：那就是让结构体私有，却把它的方法公开。这种“可使用，不可构造”的玩法，初看似乎有点矛盾，但实际上是 Go 语言封装哲学的极致体现——严格控制对象的“出生权”，但敞开了行为的“契约”。说白了，就是你可以用它干活，但怎么造出来的，你别管，也不该管。

要理解它，得先看一个最常见的场景。想象一下，你定义了一个叫 stack 的结构体，首字母小写，这意味着它在包外是看不见的。外部代码想 stack{} 这么直接 new 一个？不行，编译器直接就给你拦下了。但是呢，你又想让别人能用这个栈，比如 Push 和 Pop。怎么办？答案就是：控制构造权，开放行为契约。把 Push 和 Pop 这些方法写成首字母大写，问题就解决了。只要外部能拿到这个私有结构体的实例，就能调用它的公有方法。

核心机制：工厂函数 + 方法暴露

那外部怎么拿到实例呢？通常的玩法就是提供一个“工厂函数”。这个函数是公有的，它是创建私有结构体实例的唯一合法途径。举个例子，在 txscript 包里：

// package txscript（简化示例）
type stack struct {
    data []interface{}
}

func (s *stack) Push(v interface{}) {
    s.data = append(s.data, v)
}

func (s *stack) Pop() interface{} {
    if len(s.data) == 0 {
        return nil
    }
    last := s.data[len(s.data)-1]
    s.data = s.data[:len(s.data)-1]
    return last
}

// 导出的构造入口，唯一合法创建方式
func NewStack() *stack {
    return &stack{data: make([]interface{}, 0)}
}

这样一来，外部包用起来就非常清晰和安全：

package main

import "your-module/txscript"

func main() {
    s := txscript.NewStack() // ✅ 合法：通过导出函数获取实例
    s.Push("hello")          // ✅ 合法：调用导出方法
    s.Pop()                  // ✅ 合法

    // _ = txscript.stack{}   // ❌ 编译错误：cannot refer to unexported name txscript.stack
}

你可能会问，费这么大劲图个啥？直接公开 stack 不就行了？这背后的考虑是：你不想让调用方依赖具体的结构体实现。一旦你把 stack 公开，哪天你想改内部的数据结构（比如从切片换成链表），所有依赖它的代码都可能需要跟着改。而现在，你自由了，只要 NewStack 函数返回的类型仍然符合约定，内部随便重构。

进阶实践：面向接口编程

这还不是最妙的。更强大的用法是把它跟接口结合起来。定义一个公有接口，然后用一个私有的结构体去实现它，最后通过工厂函数返回这个接口。来看个例子：

// package service
type Processor interface {
    Process(input string) (string, error)
    Reset()
}

type processorImpl struct {
    state int
}

func (p *processorImpl) Process(input string) (string, error) {
    p.state++
    return input + "_processed", nil
}

func (p *processorImpl) Reset() {
    p.state = 0
}

// 导出工厂函数，返回接口而非具体类型
func NewProcessor() Processor {
    return &processorImpl{state: 0}
}

这个模式的优势绝对值得你把它写进自己的代码规范里：

• 彻底解耦：调用方，比如 main 包，永远只跟 Processor 这个接口打交道。它根本不知道背后还有一个 processorImpl 的存在。
• Mock 测试如喝水：测试的时候，你可以随时换上一个假的实现（比如 mockProcessor），去模拟各种边界情况，而不需要去修改业务代码。这是写出高覆盖率和健壮单元测试的关键。
• 版本演进的自由：内部结构体想怎么重构就怎么重构，哪怕是把整个处理逻辑彻底换掉（比如增加个缓存，或者切换成异步算法），只要接口的契约不变，下游所有代码零感知。

注意事项与最佳实践

当然，这个模式也有一些地方需要你特别留意，可以看作是“高手进阶”需要避开的坑：

• 方法名必须大写：这是一个铁律。只有 func (s *T) Method() 这种形式的方法才能被外部看到。写成 func (s *t) method() ？那就真成了“私有”方法，外部调用不了。
• 别不小心暴露了内部状态：如果你的私有结构体里有一个首字母大写的字段，比如 type t struct { Field int }，那这个 Field 外部是可以直接读写修改的。这相当于把你家大门钥匙给了一个陌生人。正确做法是，所有字段都用小写，通过 Getter/Setter 方法来控制访问。
• 语法层面强制，没有后门：这是 Go 的设计哲学，不像某些语言能通过反射偷偷摸摸改私有变量。除开 unsafe 这个“恶魔”，你无法绕过这个约束。这并非缺陷，而是让你在设计层面就做出正确决定的强制力。
• 命名约定：工厂函数通常喜欢用 New 开头，比如 NewStack、NewProcessor，这是 Go 社区约定俗成的做法，能让人一眼就看出这是一个构造入口。

这种设计模式在 Go 的标准库里随处可见，比如 net/http 内部那些私有的 client 结构体，或者 database/sql 的 DB 背后的私有实现。它让 Go 在静态类型语言的严谨框架中，玩出了接近动态语言的灵活性和扩展性，同时又死死守住了编译期的安全底线。可以这么说，这才是 Go 语言“少即是多”理念最深刻的一次落地。