本文永久链接 – https://tonybai.com/2025/09/13/package-managers-are-evil

大家好，我是Tony Bai。

“包管理器是万恶之源 (Package Managers are Evil)。”

这句石破天惊的论断，出自Odin语言的创造者Ginger Bill最近发表的一篇博文。在一个npm install、pip install、go get已经成为开发者肌肉记忆的时代，这无异于一篇挑战整个现代软件开发基石的“檄文”。

对于我们这些深度依赖go mod的Gopher来说，这无疑也是一次直击灵魂的拷问。我们早已习惯了Go Modules带来的便利——它解决了版本锁定、依赖传递和可复现构建等核心问题，被公认为Go生态走向成熟的里程碑。但我们是否在享受便利的同时，也正在“自动化我们的依赖地狱”？

Ginger Bill的这篇文章并非无的放矢的抱怨，而是一次对开发者文化、信任模型和软件工程第一性原理的深刻反思。让我们直面这次拷问，并以此为镜，重新审视我们与go mod的关系。

核心论点：包管理器是“依赖地狱的自动化”

首先，Ginger Bill做了一个关键的区分，他的矛头并非指向：

• 包（Packages）: 代码组织单元。
• 仓库（Repositories）: 发现和存储包的地方（如GitHub）。
• 构建系统（Build Systems）: 编译和链接代码的工具。

他精准地将炮火对准了包管理器（Package Managers）的核心功能：自动化地下载、解析和处理依赖关系。

他认为，这正是问题的根源所在。“依赖地狱”（Dependency Hell）是一个真实存在的、困扰着所有大型项目的难题——成千上万个你并不真正了解的传递依赖，版本冲突、潛在的bug、未知的安全漏洞，共同构成了一个巨大的泥潭。

而包管理器的作用，就是“将这个通往地狱的过程自动化了”。

他辛辣地指出：“不是所有能被自动化的东西，都应该被自动化，尤其是依赖地狱。”

他的核心观点是，npm install或go get这种一键式的便利，剥夺了开发者一个至关重要的环节：思考。

“当你必须手动下载和集成一个库时，你会开始思考：‘我也许并不需要这个’，或者‘我可以用别的方式来实现’。当需要更新时，手动操作会迫使你变得非常小心。”

这种被刻意放慢的、充满“摩擦力”的过程，迫使开发者去审视每一个引入的依赖，将其视为一个严肃的决策，而不是一次随意的命令行敲击。

Go的悖论：一个“幸免于难”的生态？

有趣的是，在Ginger Bill的批判中，Go被作为一个相对正面的例子提及。他观察到，即便Go拥有一个内置的包管理器，但大多数Go开发者似乎并不需要引入大量的第三方包。

“通往地狱的入口似乎又远又难走。”

为什么Go生态在一定程度上抵御了其他生态（如JavaScript）中那种失控的依赖爆炸？答案在于Go语言的设计哲学：“自带电池”（Batteries Included）。

Go拥有一个极其强大和全面的标准库。你想构建一个高性能的Web服务器？net/http就在那里。你需要处理JSON、加密、模板或者并发？标准库为你提供了一流的、经过实战检验的工具。你甚至可以在标准库里找到一个完整的Go编译器。

这种设计极大地降低了对外部微小、功能单一的“工具包”的依赖。当标准库就能满足80%的需求时，开发者自然不会像在其他生态中那样，为了实现一个最基本的功能（比如left-pad）就去引入一个外部依赖。

然而，这并不意味着Go开发者可以高枕无忧。go mod依然是一个强大的自动化工具，当我们开始引入大型框架（如Gin、GORM）或复杂的SDK时，我们同样面临着瞬间引入数十甚至上百个传递依赖的风险。

每一个依赖，都是你签下的一份“责任状”

文章中最深刻的观点之一，是对“依赖”一词含义的重新诠释。

“在现实生活中，当你有一个依赖时，你要对它负责。如果你的孩子或你的公司做错了事，你可能会因此进监狱。包依赖与此相去不远，但人们却在几乎没有任何验证的情况下就信任了它们。”

每一个go get下来的包，都是一份你自愿承担的负债。你不仅要为它的安全漏洞负责，还要为它的bug、为它未来可能停止维护的风险负责。

作者以他自己使用著名C库SDL2的痛苦经历为例。尽管SDL2被数百万人使用，但他的团队却不断踩到其中的bug，最终决定自己从头编写窗口和输入处理系统。“至少这是我们自己的代码，当出问题时我们可以依赖和修复它。”

“我不是在提倡一切都从头造轮子，” 作者澄清道，“我只是希望我们能认识到，每一个依赖都是一份负债。”

文化反思：程序员世界里的“盖尔曼遗忘效应”

为什么我们会如此轻易地信任来自互联网的随机代码？文章引用了ThePrimeagen的一个精彩论点：编程界的“盖尔曼遗忘效应”（Gell-Mann Amnesia Effect）。

这个效应描述了一种现象：当你在报纸上读到一篇关于你所精通领域的文章时（比如马术），你会发现其中充满了错误和误解。然后，你翻到下一页，读到一篇关于你不了解的领域（比如JavaScript）的文章，你又会理所当然地认为它是完全正确的。你瞬间忘记了刚刚才亲身验证过的、媒体的不可靠性。

程序员也存在同样的问题：

“你会发现工程师们一边说‘我的一些同事太可怕了’，一边又说‘嘿，让我从网上下载这个库，这肯定很棒’。他们看着自己公司三分之一的员工无法写出像样的代码，同时又选择信任他们下载的每一个开源包。”

我们对自己身边代码的质量持怀疑态度，却对那些由“开源大神”（他们可能和我们糟糕的同事是同一水平）编写的代码抱有不切实际的、过高的信任。

小结：给Gopher的启示——如何与go mod共存？

Ginger Bill的结论是激进的：如果可能，应该避免使用包管理器。对于大多数在团队中工作的Go开发者来说，这显然是不现实的。go mod是Go生态协作的基石，我们不可能回到手动管理依赖的蛮荒时代。

然而，这篇文章的价值不在于它的结论，而在于它提出的哲学框架。它像一面镜子，让我们反思我们与go mod的关系。我们可以从中提炼出几条适用于Gopher的行动指南：

1. 将go get视为一个严肃的架构决策：在引入任何新的依赖之前，进行尽职调查。检查它的代码质量、社区活跃度、issue列表和维护状态，虽然这会给你带来不小的额外工作量。
2. 永远优先选择标准库：在寻求外部解决方案之前，先问自己：“这个问题，std库里真的没有解决方案吗？” 往往答案是有的，只是需要你多花一点时间去挖掘。
3. 适当优先地拥抱代码生成，而非黑盒框架：在某些场景下，使用代码生成工具（如sqlc）可能比引入一个庞大的ORM框架（它会带来一整套复杂的依赖和抽象）更“简单”，因为它产出的是你可以直接阅读和控制的代码。
4. 定期审计你的依赖树：使用go mod graph和go list -m all来审视你的项目究竟依赖了什么。对于那些不再需要，或者有更好替代品的依赖，要勇于清理。别忘了Go Proverbs中的那一条：A little copying is better than a little dependency。

Go的“自带电池”哲学给了我们一个得天独厚的优势，让我们能更容易地践行“少即是多”的依赖管理原则。最好的包管理器，或许就是那个你用得最少的。 而go mod的真正强大之处，可能不在于它能多么轻易地帮我们添加依赖，而在于它通过一个强大的标准库，让我们在很多时候，根本无需想起它。

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/09/12/go-constructor-pattern-guide

大家好，我是Tony Bai。

Go 语言的设计哲学崇尚简约与直白(straightforward)。其中，结构体字面量 (Struct Literal) 的存在，让我们可以用极其简单的方式创建数据结构。然而，在构建大型、复杂的系统时，这种简单性也可能成为一把双刃剑。当一个对象的创建需要满足特定前置条件、执行复杂初始化或强制执行业务规则时，我们便需要一个更强大、更可控的工具。

这个工具，就是 Go 语言中地道 (Idiomatic) 且被广泛采用的“构造模式”，通常以工厂函数(New或NewXXX)的形式出现。

在本文中，我们就来系统性地说明一下Go语言构造模式的必要性、核心应用场景，并探讨其在实践中的关键决策点，如指针与值的选择。

Go 的“构造模式”：一个约定俗成的工厂函数

首先，我们必须明确一个基本事实：Go 语言在语法层面并没有内置“构造函数” (Constructor) 的概念。它不像许多面向对象语言那样，拥有在实例化时被自动调用的特殊方法。在 Go 的世界里，我们通过一种广为流传且极为有效的设计模式来达到同样的目的。

这个模式就是遵循 New… 命名约定的工厂函数 (Factory Function)。它的核心职责是封装创建逻辑，并返回一个特定类型的、立即可用的实例。让我们通过一个具体的例子，来看看这个模式在代码中是如何体现的。

// 这不是语言特性，而是一个遵循“构造模式”的工厂函数
func NewUser(name string, age int) (*User, error) {
    if age < 18 {
        return nil, errors.New("user must be at least 18 years old")
    }
    return &User{
        Name: name,
        Age:  age,
    }, nil
}

或更符合Go惯例的不带error返回值的形式：

func NewUser(name string, age int) *User {
    if age < 18 {
        return nil
    }
    return &User{
        Name: name,
        Age:  age,
    }
}

这个 NewUser 函数完美地诠释了构造模式的核心思想：

• 封装验证逻辑：函数首先检查 age 是否满足业务规则（大于等于18岁）。
• 明确的失败路径：如果验证失败，它会返回一个 nil 指针。如果带了error返回值，则返回一个描述性的 error，清晰地告知调用者创建失败。
• 成功的实例创建：只有当所有条件都满足时，它才会创建一个 User 实例的指针并返回，确保调用者得到的永远是一个有效的对象。

通过这种方式，工厂函数为类型的创建提供了一个受控且可预测的入口。它并非语言的强制要求，而是一种强大的工程实践，是开发者工具箱中用于提升代码健壮性的关键一环。

构造模式的威力：何时必须使用工厂函数？

既然我们已经明确了构造模式的本质——一个约定俗成的工厂函数——一个自然而然的问题便浮现出来：我们为什么需要它？Go 语言简洁的结构体字面量 User{…} 看似已经足够，为何要增加一个函数层来封装创建过程呢？

答案在于，当简单性不足以应对现实世界的复杂性时，构造模式便显示出其不可替代的威力。本节将深入探讨几个关键场景，在这些场景中，采用工厂函数不仅是推荐的，甚至是必需的。

1. 当类型的“零值”无效或不足时

Go 的零值机制确保了变量总处于一个已知的初始状态。然而，一个类型的零值（例如 User{Name: “”, Age: 0}）在业务逻辑上未必是有效的。工厂函数确保了任何被创建的实例，其初始状态都是经过深思熟虑且完全合法的。

2. 强制执行不变量与业务规则

这是构造模式最核心的价值所在。它提供了一个无法被绕过的入口，用于执行验证逻辑，从而保护一个类型的不变量（Invariants）。

// 构造一个有界计数器
func NewBoundedCounter(limit int) (*BoundedCounter, error) {
    if limit <= 0 {
        return nil, errors.New("limit must be a positive number")
    }
    return &BoundedCounter{limit: limit}, nil
}

或

func NewBoundedCounter(limit int) *BoundedCounter {
    if limit <= 0 {
        return nil
    }
    return &BoundedCounter{limit: limit}
}

通过这种方式，你从根本上杜绝了创建一个拥有无效边界的计数器的可能性。

3. 封装复杂的初始化过程

当一个结构体的创建需要注入依赖、初始化内部的 map 或 chan、或执行任何非平凡的设置步骤时，工厂函数可以将这些复杂性对调用者完全隐藏。

func NewAPIService(db *sql.DB, logger *log.Logger) *APIService {
    return &APIService{
        db:     db,
        logger: logger,
        cache:  make(map[string]cacheEntry), // 封装内部 map 的初始化
    }
}

4. 设计稳定且可演进的 API

如果一个包导出的结构体允许用户通过字面量进行初始化，那么该结构体的任何字段变更（增、删、改）都将成为破坏性改动。而通过工厂函数返回实例，则可以将结构体的内部实现与客户端代码解耦。你可以自由地演进你的数据结构，只要工厂函数的签名保持稳定。

5. 管理依赖并实现可测试性 (接收接口，返回结构体)

也许构造模式最强大的能力，体现在它作为实践 Go 语言核心设计原则——“接收接口，返回结构体”——的天然舞台。

一个设计良好的组件不应依赖于具体的实现，而应依赖于抽象（接口）。工厂函数正是实现这种依赖注入 (Dependency Injection) 的理想场所。

考虑一个与数据库和日志记录器交互的 APIService。一个紧耦合的设计会直接依赖具体类型：

// 紧耦合的设计，测试困难
func NewAPIService(db *sql.DB, logger *log.Logger) *APIService { ... }

这种设计在单元测试中会迫使我们创建真实的数据库连接，使测试变得缓慢且脆弱。

通过让工厂函数接收接口，我们可以彻底解耦：

// 定义依赖的接口
type Datastore interface {
    GetUser(id int) (User, error)
}
type Logger interface {
    Info(msg string)
}

// APIService 依赖于接口
type APIService struct {
    db     Datastore
    logger Logger
}

// 工厂函数接收接口作为参数，返回具体结构体
func NewAPIService(db Datastore, logger Logger) *APIService {
    return &APIService{db: db, logger: logger}
}

这一重构带来了巨大的好处：在测试中，我们可以轻易地传入一个“模拟” (mock) 的 Datastore 实现，从而将 APIService 的业务逻辑与底层数据库完全隔离。

同时，函数返回一个具体的结构体 (*APIService)，确保了调用者能够访问到该类型提供的全部公开功能，避免了因返回接口而造成的“过早抽象”。

Tip：若想强制用户必须使用工厂函数，只需在结构体中添加一个私有字段 (unexported field)。这样，其他包将无法使用结构体字面量来创建一个“业务层面逻辑有效”的该类型的实例。

关键决策：返回指针 (*T) 还是值 (T)？

一旦我们确信在特定场景下需要使用工厂函数，设计的焦点便会转移到一个更为具体且至关重要的问题上：这个函数应该返回一个指针 (*T)，还>是一个值 (T)？

这并非一个随意的语法选择，而是对性能、内存模型和程序语义的权衡。接下来的内容中，我们将剖析这两种返回方式的利弊，并为你提供清晰的决策指南。

何时返回指针 (*T)？

当函数返回一个指针时，Go 的编译器会通过逃逸分析 (Escape Analysis) 识别出该实例需要在函数外部继续存在，因此会将其分配在堆 (Heap) 上。

选择返回指针的核心理由：

1. 避免大结构体复制：当结构体非常大时，在函数间传递一个指针（一个内存地址）的成本远低于复制整个结构体。这是最重要的性能考量之一。
2. 实现共享与可变性：如果你期望函数返回的实例可以在程序的不同部分被共享和修改，指针是唯一的选择。
3. 结构体包含不可复制类型：若结构体包含如 sync.Mutex 或 os.File 等字段，它必须通过指针传递，以确保所有操作都作用于同一个实例。对这类结构体的值进行复制，通常会导致程序错误。
4. 遵循接口约定：在 Go 中，通常是指针类型 (*T) 来实现接口。因此，返回接口的工厂函数自然也应返回指针。

何时返回值 (T)？

当函数返回一个值，且该值未发生逃逸时，它会被分配在栈 (Stack) 上，然后复制给调用方。

选择返回值的核心理由：

1. 小型、简单的值类型：对于只包含几个基本类型的微小结构体，复制成本极低。
2. 降低垃圾回收 (GC) 压力：栈上分配由编译器自动管理，生命周期短暂，无需 GC 介入。在性能极其敏感的热点代码路径上，优先使用栈分配是重要的优化手段。
3. 促进不变性 (Immutability)：返回一个值的副本，意味着调用者对该副本的任何修改都不会影响到其他部分，这使得代码的行为更加可预测，减少了意外的副作用。

默认情况下，对于小型的、类似值的结构体，优先返回值。对于大型结构体、需要被修改的实体，或包含不可复制字段的类型，则应返回指针。

进阶用法：用指针字段表示“可选性”

我们对指针的探讨，主要集中在它作为函数返回值的角色上，以决定实例的内存分配和共享方式。然而，指针的威力并不仅限于此。在结构体内部，指针同样扮演着一个精妙而关键的角色：表达“可选性” (Optionality)。它为我们提供了一种区分“零值”与“未提供”的优雅机制。

一个 int 字段的零值是 0，而一个 *int 字段的零值是 nil。

在很多业务场景中，0 是一个完全有效的数值（例如，库存数量为 0），但我们可能还需要表达“这个值尚未设置”或“此项不适用”的语义。此时，一个 nil 指针便完美地传达了“缺失”的概念。

这在处理来自数据库的 NULL 值或 JSON API 中的可选字段时尤为重要。

考虑一个用于更新用户部分信息的 PATCH 请求，我们可能只想更新用户的昵称，而不触及其年龄；或者，我们想将用户的积分明确设置为 0。

package main

import (
    "encoding/json"
    "fmt"
)

// UpdateUserPayload 定义了更新用户信息的请求体
// 使用指针类型来表示可选字段
type UpdateUserPayload struct {
    Nickname *string json:"nickname,omitempty"
    Score    *int    json:"score,omitempty"
}

func main() {
    // 场景一：只更新用户的昵称
    newNickname := "Gopher"
    payload1 := UpdateUserPayload{
        Nickname: &newNickname, // Score 字段为 nil
    }
    json1, _ := json.Marshal(payload1)
    fmt.Println(string(json1)) // 输出: {"nickname":"Gopher"}

    // 场景二：只将用户的积分明确更新为 0
    newScore := 0
    payload2 := UpdateUserPayload{
        Score: &newScore, // Nickname 字段为 nil
    }
    json2, _ := json.Marshal(payload2)
    fmt.Println(string(json2)) // 输出: {"score":0}
}

在这个例子中：

• *string 和 ***int** 结合 json:”,omitempty” 标签，创造了强大的表达能力。
• 在场景一中，由于 Score 字段是 nil，它在 JSON 序列化时被完全忽略了。API 的接收端可以据此判断：客户端只想修改 Nickname，对 Score 不做任何操作。
• 在场景二中，我们明确地提供了一个指向 0 的指针。这使得 score 字段在 JSON 中真实地出现，并赋值为 0。API 接收端会明白：客户端的意图是将 Score 更新为 0，而不是不提供这个值。

通过这个模式，我们完美地解决了“更新为空字符串”与“不更新该字段”、“更新为0”与“不更新该字段”之间的语义模糊问题，让 API 的设计更加精确和健壮。

小结：拥抱 Go 的务实与平衡

Go 语言在结构体初始化上提供了从极简到极严谨的选择。结构体字面量是其简约哲学的体现，而 New(…) 工厂模式则是其务实工程思想的结晶。

精通构造模式，意味着你理解了何时需要超越简单的零值和字面量，为你的代码构建起一道保护其核心逻辑与业务规则的坚固屏障。在你的下一个项目中，当遇到一个需要保证初始状态合法性的类型时，请毫不犹豫地为其设计一个清晰、健壮的工厂函数吧。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。