本文永久链接 – https://tonybai.com/2026/04/18/ollama-from-open-source-hero-to-community-enemy

大家好，我是Tony Bai。

两年前，在本地大模型的蛮荒时代，Ollama 曾如一道神光，照亮了无数普通开发者的探索之路。

凭借那句魔咒般的 ollama run llama3，它以一种近乎“降维打击”的优雅，将普通人与本地 AI 之间的天堑夷为平地。

一时间，Ollama 被盛赞为“本地 AI 的 Docker”、“开源精神的典范”，几乎成了无数技术布道者口中的“开源英雄”。

但就在几天前，一篇名为《本地大模型生态系统不再需要 Ollama》的文章，在技术社区 Hacker News 上，引发了一场“社区公审”。

文章详细罗列了 Ollama 在享受了社区的赞誉之后，犯下的种种“罪行”：从对核心依赖 llama.cpp 长达 400 多天的“选择性遗忘”，到试图用私有模型格式“绑架”用户，再到其背后若隐若现的“VC 商业化”套路……

一夜之间，Ollama 的形象从“屠龙少年”，变成了那条它曾经挑战的“恶龙”。

今天，我们就来深度复盘这场顶级社区的大讨论，看看这位曾经的“开源英雄”，究竟是如何一步步走向“社区公敌”的深渊的。

第一宗罪：对生身之父的“背叛”与“除名”

Ollama 之所以能如此快速地在各种平台上运行大模型，其背后最大的功臣，是一个名为 llama.cpp 的 C++ 开源库。llama.cpp 是真正负责模型推理的底层引擎。

Ollama 的 v0.0.1 版本，在其 README 中曾明确写道：“一个用 Go 编写的快速推理服务器，由 llama.cpp 驱动。”

Ollama 的本质，是一个基于 llama.cpp 构建的、优化了用户体验的“包装器（Wrapper）”。

然而，随着 Ollama 的声名鹊起，llama.cpp 的名字，却在其官网和宣传中，被刻意地、系统性地抹去了。

在 Hacker News 的帖子中，有用户愤怒地指出：

“这根本不是开源礼仪的问题。MIT 协议只有一个核心要求：包含版权声明。Ollama 没有做到。”

“社区注意到了。GitHub Issue #3185 在 2024 年初就被提出，要求 Ollama 遵守协议。这个 Issue 在 400 多天里，没有得到任何维护者的回应。”

直到社区忍无可忍，发起了 PR，Ollama 的联合创始人才最终在 README 的最底部，加上了一行极其微小的致谢：“llama.cpp 项目由 Georgi Gerganov 创建。”

这种对核心上游项目近乎“羞辱性”的冷处理，被社区视为一种赤裸裸的“背叛”，激怒了所有信奉开源精神的开发者。

第二宗罪：用“私有格式”构建“数据监狱”

比忘记致谢更让开发者无法容忍的，是 Ollama 为了“锁定用户”，而精心设计的私有化模型存储格式。

如果你用过 Ollama，你一定经历过这样的困惑：

你用 ollama pull 下来的模型文件，被存储在你的 Home 目录下，文件名是一串毫无意义的哈希值。你根本无法将这个 GGUF 文件，直接分享给其他工具（比如 LM Studio 或 Jan）使用。

Hacker News 的一位用户一针见血地指出了这个设计的“阴险”之处：

“我停止使用 Ollama 的原因就在于此。我能理解他们可能是为了做去重（Deduplication），但这使得我无法与其他工具共享同一个模型。每个工具都只能指向它自己的文件。无论他们的意图如何，这都在客观上，让你极难尝试其他工具。”

更糟糕的是，Ollama 会在下载模型时，对原始的 GGUF 文件进行一些“魔改”，并使用自己的一套私有配置。这导致了另一个灾难：性能下降。

有人在评论中分享道：“我最近开始使用 Jan，然后用 llama.cpp 和本地的 Ollama 跑同一个模型，llama.cpp 的速度明显更快。”

用更差的性能、更封闭的格式，换取所谓“简单”的用户体验。这背后，是典型的“建立围墙花园”的商业化思维。

第三宗罪：“VC 死亡陷阱”的经典复刻

Ollama 为什么要这么做？

一位用户在评论中扒出了 Ollama 创始团队的“前科”，让所有人恍然大悟。

“Ollama 是一家由 Y Combinator 支持的创业公司，其创始人之前构建了一个被 Docker 收购的 Docker GUI 工具。这个剧本太熟悉了：
1. 包装一个现有的开源项目，做一个用户友好的界面。
2. 建立用户基础，获得社区信任。
3. 融资，然后想办法商业化。
4. 最小化对上游的致谢，让产品看起来是自给自足的。
5. 创造锁定，用私有格式和哈希文件名，让用户无法迁移。
6. 推出闭源组件（GUI App）和云服务，开始收割。”

这套从 Docker 时代的 Kitematic 延续而来的“VC 死亡陷阱”，正在本地大模型领域被完美复刻。

社区的反击：大逃杀与“去 Ollama 化”

在这场社区的“公审”中，愤怒之余，开发者们也给出了大量极具建设性的“替代方案”。一场“去 Ollama 化”的大逃杀正在上演。

方案一：回归 llama.cpp 本身，王者归来

很多用户惊讶地发现，在他们唾弃 Ollama 的这段时间里，llama.cpp 自身已经进化成了一个极其强大的“完全体”。

它现在不仅自带了现代化的 Web UI（通过 llama-server），支持 OpenAI 兼容的 API，甚至还推出了“路由模式”，可以实现模型的“热插拔（Hot-swapping）”。

方案二：拥抱真正开放的“包装器”

社区推荐了大量同样易用，但秉持着真正开源精神的替代品，比如：

• LM Studio：自带强大的 GUI，底层使用 llama.cpp，暴露所有可调参数，支持任何 GGUF 模型，不搞“锁定”。
• Jan (jan.ai)：另一个开源的桌面应用，界面清爽，设计本地优先。
• llamafile：由 Mozilla 支持，可以将模型和 llama.cpp 本身打包成一个“单一可执行文件”，真正实现“一键启动”，且完全开放。

小结：当便利性遭遇开源精神

Ollama 的故事，是近年来开源商业化领域最值得深思的一个案例。

毫无疑问，Ollama 解决了本地大模型领域一个极其真实的痛点：极致的易用性（Ease of use）。它就像当年的 Docker，让无数普通人跨越了复杂的门槛。

但在追求极致 UX 的同时，它却似乎忘记了自己赖以生存的根基——那个由 Georgi Gerganov 等无数开源贡献者用爱发电构建起来的 llama.cpp 生态。

Hacker News 上的这场论战，并没有全盘否定 Ollama 的价值。但它向所有试图通过“包装开源”来构建商业帝国的创业者，提出了一个极其严肃的警告：

用户体验的简化，永远不能以牺牲“开放性”和对上游社区的“尊重”为代价。

你可以站在巨人的肩膀上，但你不能在站上去之后，假装那个巨人不存在。

作为开发者，我们享受着开源带来的巨大红利。但在选择工具时，除了便利性，我们或许也应该多一份清醒：去看看它的背后，是否隐藏着一个正在试图关上的“围墙花园”。

资料链接：

• https://news.ycombinator.com/item?id=47788385
• https://sleepingrobots.com/dreams/stop-using-ollama/

---

今日互动探讨：

你在使用 Ollama 时，是否也曾被它私有的模型管理方式所困扰？对于“包装开源”并进行商业化的模式，你是支持还是反对？

欢迎在评论区分享你的看法！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

---

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/03/13/go-duckdb-micro-data-warehouse-dimensionality-reduction

大家好，我是Tony Bai。

设想这样一个极其普遍的日常工作场景：

产品经理找到你，希望能给业务后台加一个“简单”的数据看板，用来实时统计用户的 PV/UV 漏斗、Nginx 日志的慢查询分析，或者是 IoT 设备的近期时序数据。

面对每天几百万到上千万条的数据量，你陷入了沉思。

如果直接用 MySQL/PostgreSQL 跑 GROUP BY 和 COUNT(DISTINCT)，数据库的 CPU 瞬间飙到 100%，不仅查询要等上十几秒，甚至可能把核心交易业务一起拖死。

如果为了这个需求，去大动干戈地部署一套 ClickHouse、Elasticsearch 、Spark 集群或某个大型时序数据库……不仅运维成本上天，对于这点数据量来说，简直是用高射炮打蚊子。

在“传统关系型数据库跑不动”和“大数据集群太沉重”之间，难道就没有一个恰到好处的方案吗？

今天，我想给你介绍一个在海外工程界使用较多的方案。它不仅能把你从沉重的大数据组件中解救出来，还能在你的 Go 语言单二进制文件中，塞进一个性能恐怖的 OLAP（在线分析处理）引擎。

它就是 DuckDB。结合 Go 语言，它能在普通服务器上跑出每秒 1800 万条记录的写入速度，和毫秒级的亿级数据分析延迟。

这绝对是一场对传统数据架构的降维打击。

为什么 MySQL/PG 做不好数据分析？

很多开发者在职业生涯早期都会踩这个坑：试图用 MySQL 解决一切问题。

当你在 PostgreSQL 或 MySQL 中执行一个跨度为 30 天的聚合分析时，为什么会慢得让人绝望？因为它们的底层是“行式存储（Row-oriented）”。

在行式存储中，即使你只需要 user_id 和 timestamp 这两列，数据库也必须把每一行的所有字段（包括那些庞大的 JSON 或 Text 字段）全部从磁盘加载到内存中。大量无用的 I/O 消耗，让分析查询变成了灾难。

为了解决这个问题，我们被迫引入了 ClickHouse 等“列式存储（Column-oriented）”数据库。列式存储让分析查询的速度提升了上百倍，但代价是：你需要额外部署和维护分布式集群、学习复杂的表引擎配置等。

DuckDB——OLAP 界的 SQLite

难道列式存储就必须伴随着复杂的集群部署吗？

DuckDB 给出了一个极其优雅的答案：做 OLAP 领域的 SQLite。

DuckDB 是一个纯粹的嵌入式列式数据库。它没有独立的服务器进程，而是内嵌在你的应用进程中，不需要你配置任何网络端口。它有很多语言的binding，包括Go。

在 Go 项目中，你只需要简单地 import “github.com/duckdb/duckdb-go/v2″，它就会作为动态/静态链接库，直接融入你的 Go Application 进程中。

但千万别因为“嵌入式”三个字就觉得它是玩具。社区的一款开源高性能数据库 Arc（基于 Go + DuckDB）给出了一份令人毛骨悚然的实测数据(基于MacBook Pro M3 Max (14 cores, 36GB RAM, 1TB NVMe))：

• 写入性能：高达 18.6M+（1860万）记录/秒
• 写入延迟：P50 < 0.5ms，P99 < 4ms
• 查询性能：6M+（600万）行/秒扫描 (Arrow格式)

它是怎么做到的？除了列式存储，它底层还偷偷藏着两个大杀器：向量化执行引擎（Vectorized Execution） 和对 Parquet 格式的原生支持。

手把手拆解 1800 万/秒的极致写入

口说无凭，我们直接上硬核源码。

很多新手刚接入 DuckDB 时，会习惯性地用标准 SQL 的 INSERT INTO … VALUES 去循环写数据。你会发现速度并不快，一秒钟只能写几万条。

真正的降维打击，藏在 DuckDB 专门为 Go 语言暴露的 Appender API 中。

Appender 绕过了繁琐的 SQL 解析器和规划器，直接将 Go 的内存数据格式，以极低的开销批量“灌”入 DuckDB 的底层列存结构中。来看这段极致狂暴的写入代码：

// https://go.dev/play/p/mHXu-kAydDX
package main

import (
    "context"
    "database/sql"
    "fmt"
    "log"
    "time"

    duckdb "github.com/duckdb/duckdb-go/v2"
)

func main() {
    // 1. 用 NewConnector 创建连接器（指定数据库文件）
    connector, err := duckdb.NewConnector("analytics.db", nil)
    if err != nil {
        log.Fatal(err)
    }
    defer connector.Close()

    // 2. 用 sql.OpenDB 打开标准 db（用于建表等 SQL 操作）
    db := sql.OpenDB(connector)
    defer db.Close()

    _, err = db.Exec(CREATE TABLE IF NOT EXISTS metrics (id INTEGER, name VARCHAR, value DOUBLE, ts TIMESTAMP))
    if err != nil {
        log.Fatal(err)
    }

    // 3. 用 connector.Connect() 获取底层 driver.Conn（Appender 需要这个）
    conn, err := connector.Connect(context.Background())
    if err != nil {
        log.Fatal(err)
    }
    defer conn.Close()

    // 4. 直接传 driver.Conn，无需 Raw()
    appender, err := duckdb.NewAppenderFromConn(conn, "", "metrics")
    if err != nil {
        log.Fatal(err)
    }
    defer appender.Close()

    startTime := time.Now()

    for i := 0; i < 100000; i++ {
        err := appender.AppendRow(
            int32(i),
            fmt.Sprintf("metric_%d", i%10),
            float64(i%100),
            time.Now(),
        )
        if err != nil {
            log.Fatal(err)
        }
    }

    elapsed := time.Since(startTime)
    fmt.Printf("插入 10 万条数据耗时: %v\n", elapsed)
    fmt.Printf("吞吐量: %.0f 记录/秒\n", 100000.0/elapsed.Seconds())
}

在我的一台2019款 普通 MBP 笔记本(Intel芯片)上，上述这段代码写入 10 万条数据仅需 69 毫秒。

插入 10 万条数据耗时: 69.466586ms
吞吐量: 1439541 记录/秒

换算下来，吞吐量轻松突破 143 万条/秒。如果开启并发和更大批次，逼近千万级似乎也毫无压力。这比传统的 SQL INSERT 快了整整 100 倍！

替代 ELK，只需一个 Go 二进制文件

掌握了这把利器，我们该如何在实际业务中发挥它的威力？

假设你有一个 10GB 的 Nginx 日志文件（或者 CSV 文件），老板让你马上查一下昨天的 PV、UV 和慢查询排行。

过去，你需要搭建 Logstash -> Elasticsearch -> Kibana 这一套全家桶。

现在，你只需要写几十行 Go 代码。DuckDB 支持直接查询 CSV 和 Parquet 文件，连数据导入都省了！

你可以直接把底层的统计逻辑嵌在你的 Go REST API 里(仅作说明使用)：

// 直接在 Go 代码中，把 DuckDB 当作微型分析网关
func (adb *AnalyticsDB) GetHourlyStats() (map[string]interface{}, error) {
    // 惊人特性：直接用 SQL 语法查询本地或 S3 上的 Parquet 压缩文件！
    rows, err := adb.db.Query(
        SELECT
            DATE_TRUNC('hour', timestamp) as hour,
            COUNT(*) as pv,
            COUNT(DISTINCT path) as uv
        FROM read_parquet('s3://my-bucket/nginx_logs/*.parquet')  -- 对 Parquet 格式的原生支持与深度优化（谓词下推、列裁剪），可跳过无关数据块，大幅减少实际 I/O
        WHERE timestamp > NOW() - INTERVAL '24 hours'
        GROUP BY hour
        ORDER BY hour DESC
    )
    // ... 解析并返回给前端
}

通过这种架构，你的 Go 语言 Web 服务瞬间拥有了媲美 ClickHouse 的 OLAP 分析能力。

最绝的是，整个系统的部署产物，仅仅是一个几十 MB 的 Go 二进制文件。没有额外的依赖，丢上服务器就能跑。

小结：它不是万能的银弹

虽然 DuckDB 强到离谱，但作为高级工程师，我们必须理智看待边界。

DuckDB 绝对不适合做高并发的 OLTP（在线事务处理）。

如果你用它来扛电商的下单扣库存、或者多用户的并发更新行数据，它会死得很惨。因为它是一头为了“大吞吐分析”而生的巨兽，并没有针对行级锁和高频短事务做优化。

所以，最完美的现代架构公式应该是：

PostgreSQL/MySQL（负责核心业务流） + Go 应用内嵌 DuckDB（负责旁路日志、报表聚合的简单轻量分析）。

---

** 今日互动探讨：**

你在公司里遇到过哪些“为了小数据杀鸡用牛刀，强行部署大集群”的奇葩架构？或者你平时处理百万级数据分析时，最爱用什么工具？

欢迎在评论区疯狂吐槽或分享！

---

认知跃迁：掌控架构降维打击的底层逻辑

看到这里，你是否对日常的业务开发有了全新的视角？

在过去，面对复杂的分析需求，CRUD 程序员的本能反应是“引入一个新的重量级中间件”。

但真正的高级架构师，懂得利用底层技术栈的差异性（如行存与列存、向量化与标量计算），用最轻量、最克制的方案完成“降维打击”。

如果你的 Go 技能依然停留在写写简单的增删改查 API，对更深层的并发控制、内存管理和系统级架构选型感到迷茫——

我的极客时间专栏《Go语言进阶课》正是为你量身打造！

在这 30+ 讲硬核内容中，我将带你剥开语法糖，深入理解 Go 的底层运行机制，不仅教你写代码，更教你像顶级大厂架构师一样思考：如何用最少的组件，设计出极高并发、极低延迟的优雅系统。

目标只有一个：助你完成从“Go 熟练工”到“能做顶级架构决策的 Go 专家”的蜕变！

扫描下方二维码，加入专栏，让我们一起用技术实现“四两拨千斤”的震撼。

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

---

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/03/11/in-memory-of-tony-hoare

大家好，我是Tony Bai。

在这个由代码构建的现代世界里，有些名字如同星辰般指引着航向。但遗憾的是，2026 年 3 月 5 日，其中一颗最明亮的星辰熄灭了。

图灵奖得主、快速排序（Quicksort）发明者、CSP（通信顺序进程）理论之父 Tony Hoare（托尼·霍尔）与世长辞，享年 92 岁。

也许你并不熟悉这个名字。但只要你是一个程序员，你就一定在面试时手写过他发明的快速排序；如果你是一个 Go 开发者，那你每天在键盘上敲下的每一个 go func() 和 make(chan int)，都在调用着他留给这个世界的伟大的遗产。

今天，让我们暂时放下手头的 CRUD，跨越半个世纪的时间洪流，去看看这位非典型天才，是如何用他那近乎神迹的洞察力，赐予了 Go 语言制霸云原生时代的“并发灵魂”。

被“共享内存”支配的黑暗时代

在讲 Tony Hoare 有多伟大之前，我们必须先回忆一下，在他提出那套神级理论之前，程序员们在并发编程的泥潭里经历了怎样暗无天日的挣扎。

随着多核时代的到来，程序需要同时执行多个任务。传统的思路极其简单粗暴：共享内存（Shared Memory）。

一堆线程就像一群饿狼，死死盯着同一块内存区域。为了防止数据被写乱，程序员们被迫发明了互斥锁（Mutex）、信号量（Semaphore）。你必须极其小心地、以上帝视角去加锁、读写、释放锁。

只要你稍有不慎，忘记解锁，或者加锁顺序反了，死锁（Deadlock）和竞态条件（Race Condition） 就会像幽灵一样找上门来。程序在本地跑得好好的，一上生产环境就离奇崩溃，且极难复现、极难调试。

那是一个属于并发编程的“黑暗时代”。天下程序员苦“共享内存与锁”久矣，却找不到破局之法。

从古典哲学到“六便士的赌注”

就在整个计算机科学界在锁的泥潭里打滚时，Tony Hoare 站了出来。

有趣的是，Tony 并非科班出身。他在大学修读的竟然是古典学与哲学，后来又在皇家海军服役期间接受了高强度的俄语训练。这种看似“不务正业”的跨学科背景，赋予了他极其严密的逻辑思辨能力和哲学视角的解构能力。

他年轻时有个极其经典的轶事：在一家公司打工时，老板让他实现 Shellsort（希尔排序）。Tony 完成任务后，怯生生地对老板说：“我知道一种比这快得多的算法。” 老板不屑一顾：“我跟你赌六便士（大约几毛钱），你肯定不知道！”

于是，Tony 写出了那个后来被印在全世界每一本数据结构教材里的算法——快速排序（Quicksort）。他不仅赢走了那六便士，还顺手改变了世界。

而在面对并发编程的“绝症”时，Tony 再次展现了他哲学般的降维打击能力。

惊世骇俗的 CSP 理论

1978 年，Tony Hoare 发表了一篇名为《通信顺序进程》（Communicating Sequential Processes, 简称 CSP）的学术论文。

宛如一道闪电，这篇论文劈开了并发编程的混沌。

Tony 的哲学思维告诉他：既然共享内存那么容易出错，那我们干脆就不要共享内存了！

在 CSP 理论中，系统被划分为多个独立的、顺序执行的黑盒（进程）。它们之间没有任何共享状态。当它们需要协作时，唯一的交互方式是通过一条极其明确的管道（Channel）来“发送和接收消息”。

这就像是现实生活中的流水线工人：每个人只管自己手头的活（顺序执行），做完了就通过传送带（Channel）递给下一个人。没人去抢同一个零件，自然就不需要打架（加锁）。

这种高度抽象的数学模型，完美地将复杂的并发控制，降维成了简单的数据流动。

Go 语言与云原生的基石

理论是伟大的，但在 1978 年，CSP 受限于当时的硬件架构，很难大规模工程化普及。它在学术界的象牙塔里，静静等待着一个能将它发扬光大的使者。

30 年后，谷歌的一间办公室里，Rob Pike、Ken Thompson 等几位大神正被 C++ 的并发折磨得痛不欲生。他们决定创造一门新的语言。

由于 Rob Pike 早年深受 CSP 理论启发，他将 Tony Hoare 的毕生心血，直接刻进了这门新语言的基因里。这门语言，就是 Go。

Tony Hoare 论文里的晦涩数学模型，在 Go 语言里被具象化为了两个极其优雅的关键字：

1. 顺序进程，演化成了轻量级的 Goroutine (go func())。
2. 通信管道，演化成了强类型的 Channel (make(chan int))。

Rob Pike 更是将 CSP 的核心思想，提炼成了那句在 Go 圈子里无人不知的至理名言：

“Do not communicate by sharing memory; instead, share memory by communicating.”
（不要通过共享内存来通信，而应该通过通信来共享内存。）

让我们看一眼这被 CSP 灵魂洗礼过的代码，没有任何 sync.Mutex，没有复杂的死锁恐惧，数据的控制权随着流水的管道优雅地传递：

func main() {
    ch := make(chan int) // 创造一条 Tony Hoare 定义的通信管道

    go func() {          // 启动一个 Tony Hoare 定义的顺序进程
        ch <- 42         // 通过通信转移数据
    }()

    fmt.Println(<-ch)    // 完美接收，无需任何锁
}

Tony Hoare 也许没有预料到，他在半个世纪前写下的论文，会在今天成为支撑全球互联网的基石之一。

当我们谈论云原生时代的 Docker、Kubernetes、Prometheus 时，我们谈论的其实是 Go 语言；而当我们惊叹于 Go 语言能轻松扛起千万级的高并发调度时，我们真正应该感谢的，是底层那个名叫 CSP 的幽灵。

我们每一次扩容容器，底层的字节流都在以 Tony Hoare 所描绘的方式，有条不紊地穿梭于硅片与光纤之间。

致敬宗师：最好的纪念，是传承他的思想

Jim Miles 在追忆 Tony 的文章中提到，这位伟大的图灵奖得主极其谦逊。他曾笑着对别人说：“真正的天才不是一蹴而就的，而是在无数个日夜的深度思考中，为了一个单一问题苦苦挣扎的凡人。”

作为普通的开发者，我们无缘与这位伟人共饮下午茶，或听他亲口讲述那六便士的赌注。但作为工程师，我们对宗师最好的纪念，就是停止写那些糟糕的、充满死锁风险的并发代码，去真正理解并传承他的设计哲学。

今天，当你再次在 IDE 中敲下那个简短却充满魔力的 go func() 时，请在心底默默向这位智者致敬。

再见了，一代巨匠 Tony Hoare。

您的代码和算法已是不朽。您赐予计算世界的并发灵魂，将伴随着一代又一代的程序员，在无尽的服务器网络中，永不停止地运行下去。

参考资料

• https://en.wikipedia.org/wiki/Communicating_sequential_processes
• https://blog.computationalcomplexity.org/2026/03/tony-hoare-1934-2026.html

---

今日互动：

你在平时的 Go 开发中，是更喜欢用 Channel（CSP 模型）还是更习惯用 Mutex 锁（共享内存模型）？在并发编程中踩过哪些大坑？

欢迎在评论区分享你的心得！

---

认知跃迁：真正驾驭 Go 的并发灵魂

Tony Hoare 将复杂的并发问题，抽象成了极其优雅的 CSP 理论。但很多 Go 开发者，由于没有看透这层底层哲学，依然在用写 Java/C++（共享内存）的思维来写 Go，最终把 Channel 滥用得一塌糊涂，甚至引发严重的 Goroutine 泄漏。

想要真正吃透 Go 语言的并发灵魂，靠死背语法是绝对不够的。 你必须深入理解底层调度器（G-M-P 模型）是如何运作的，必须明白何时该用 Channel，何时该退回到 Mutex。

如果你渴望突破并发编程的认知瓶颈，不再只做一个“会调关键字”的熟练工，而是想成为能设计出高可用、极高并发架构的 Go 资深专家——

我的极客时间专栏 Go语言进阶课 正是为你量身定制。在这 30+ 讲硬核内容中，我将带你剥开语法糖，直击 Go 并发模型的底层骨架，重塑你的系统级架构审美。

扫描下方二维码，加入专栏。让我们用最扎实的工程实践，去向半个世纪前的伟大思想致敬！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

---

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/03/01/goodbye-google-uuid-go-standard-library-crypto-uuid

大家好，我是Tony Bai。

在 Go 的世界里，有几个第三方库的地位几乎等同于标准库，github.com/google/uuid 绝对是其中之一。无论是微服务架构、数据库主键，还是分布式追踪，UUID 的身影无处不在。

然而，尽管其他主流语言（如 Java, C#, Python）早已将 UUID 纳入标准库，Go 却迟迟未动。直到最近，一个长达近三年讨论的提案 #62026: proposal: crypto/uuid: add API to generate and parse UUID 终于迎来了突破性进展：Go 官方提案审查委员会已将其标记为 “likely accept”（极有可能接受）。

这意味着，在不久的将来（大概率是 Go 1.27 或后续版本），我们终于可以使用官方的 crypto/uuid 包了。

不仅如此，这个issue中的数百条留言也折射出的是 Go 团队对极简主义、安全性以及现代 UUID 标准的深刻思考。

UUID 极简史：从 V1 到 V8 的演进

在深入探讨 Go 的提案之前，我们有必要先补齐 UUID（通用唯一识别码，Universally Unique Identifier）的背景知识。

UUID 是一个 128 位（16 字节）的标识符，通常以 32 个十六进制数字和 4 个连字符表示，形如：f81d4fae-7dec-11d0-a765-00a0c91e6bf6。它的核心目标是：在无需中央协调机构的情况下，保证全球范围内的唯一性。

随着技术的演进，UUID 规范（主要是 RFC 4122 以及最新的 RFC 9562）定义了多种版本，它们在生成机制上各有千秋：

• V1 & V2 (基于时间与 MAC 地址)：早期的 UUID 依赖机器的物理网卡地址和当前时间。缺点：暴露了机器身份和生成时间，存在严重隐私风险，现已极少使用。
• V3 & V5 (基于名称的哈希)：根据特定的命名空间（如 URL）和名称生成。V3 使用 MD5，V5 使用 SHA-1。相同输入永远产生相同输出。缺点：MD5 和 SHA-1 已被认为在密码学上不够安全，使用场景受限。
• V4 (纯随机)：目前最广泛使用的版本。128 位中除了 6 位用于版本和变体标识外，其余 122 位全部由密码学安全的随机数生成。优点：完全匿名，冲突概率极低。缺点：完全无序，作为数据库主键时，会导致 B+ 树索引严重碎片化，影响写入性能。
• V6 (重新排序的 V1)：为了解决 V4 的无序问题，将 V1 的时间戳字段重新排列，使其具有时间上的单调递增性。
• V7 (时间有序的随机)：新一代的王者（RFC 9562 重点推荐）。它的前 48 位是 Unix 毫秒时间戳，后面跟着充足的随机数据。优点：兼顾了 V4 的隐私性/随机性，和时间上的粗略单调递增。作为数据库主键时，插入性能远超 V4。
• V8 (自定义)：为实验性或特定供应商的格式预留。

了解了这些，我们就能理解为什么 Go 团队在设计官方 API 时，会做出一些看似“保守”的选择了。

为什么现在才引入标准库？

既然 UUID 如此重要，为什么 Go 官方拖到现在？

Go 核心成员 neild 的回答非常坦诚：

1. 没有迫切需求：github.com/google/uuid 这个第三方库工作得非常好，API 稳定，没有不可容忍的缺陷。
2. API 设计的迷茫：UUID 标准一直在演进。如果在 2018 年将其纳入标准库，可能只会提供 V4；而今天来看，V7 显然是必需的。由于 Go 极其严苛的向后兼容性承诺，一旦将庞杂的 API 加入标准库，就永远无法删除。

那么，为什么现在又决定引入了呢？

• 事实上的基础设施：UUID 已经成为现代软件开发的基石。
• RFC 9562 的发布：新的标准确立了 V7 的地位，结束了长期的混乱，是时候一锤定音了。
• 原第三方库的维护困境：github.com/google/uuid 包含了大量历史包袱（如已废弃的方法、不再需要的错误返回等），且维护状态堪忧。Go 团队希望提供一个更精简、更现代、与 Go 核心理念更契合的官方实现。

极简的艺术：crypto/uuid API 设计解析

经过社区数月的激烈辩论，官方最终拟定的 crypto/uuid API 极度精简，展现了 Go 语言一贯的克制。

这是目前被标记为 “likely accept” 的 API 概览：

package uuid // 位于 crypto/uuid

// UUID 的本质：16个不透明的字节
type UUID [16]byte

// 变量：极值
var Nil = UUID{}
var Max = UUID{0xff, 0xff, ...} // 16个 0xff

// 构造函数
func New() UUID { return NewV4() } // 默认提供 V4
func NewV4() UUID
func NewV7() UUID

// 解析函数
func Parse(s string) (UUID, error)
func MustParse(s string) UUID

// 序列化与格式化
func (u UUID) String() string
func (u UUID) MarshalText() ([]byte, error)
func (u UUID) AppendText(b []byte) ([]byte, error)
func (u *UUID) UnmarshalText(b []byte) error

// 比较
func (u UUID) Compare(v UUID) int

乍一看，这个 API 似乎比 google/uuid 少了很多东西。这些“缺失”正是设计的精髓所在。让我们逐一解析背后的考量。

为什么底层类型是 [16]byte？

有人提议用 struct 隐藏实现，有人提议用 string。官方最终坚持使用 [16]byte。

• 兼容性：它与 google/uuid 的底层类型完全一致，这意味着两者之间的转换仅仅是一个零成本的类型强转（Type Cast），极大降低了生态迁移的成本。
• 语义准确：UUID 本质上就是 16 个字节的数据，没有任何序列是“非法”的。

为什么 New 函数不再返回 error？

在使用 google/uuid 时，最让人烦躁的就是 uuid.NewRandom() 会返回 (UUID, error)。因为在底层，它调用的是 crypto/rand.Read。理论上，读取系统随机数可能会失败。

但现实中，现代操作系统的安全随机源（如 /dev/urandom 或 getrandom 系统调用）几乎不可能失败。如果它失败了，说明你的系统内核已经崩溃，此时程序 panic 才是最正确的选择。

Go 1.24 引入的 #66821 提案明确了 crypto/rand 会在失败时直接致命退出（Fatal）。因此，在新的 crypto/uuid 中，所有的 New 函数都去掉了冗余的 error 返回值，极大地净化了调用方的代码。

// 以前
id, err := uuid.NewRandom()
if err != nil { ... }

// 现在
id := uuid.New() // 爽！

为什么只提供 V4 和 V7？V1、V3、V5 呢？

Go 安全团队负责人 Roland Shoemaker 对开源生态进行了大规模的数据挖掘，发现：

• 超过 90% 的调用是生成随机 UUID（V4）。
• 生成 V5 的函数（NewSHA1）使用率不足 0.05%。

基于“如无必要，勿增实体”的原则，官方决定只提供 V4 和 V7。

• NewV4：当你只需要一个纯随机的唯一标识符时。
• NewV7：当你的标识符会被用作数据库主键，且你希望获得更好的插入性能（时间局部性）时。

如果你真的需要 V5 这种基于 SHA-1 的弱哈希 UUID 怎么办？社区的回答是：自己写，或者继续用第三方库。标准库不应该为这种罕见且安全性存疑的场景买单。

V7 的争议：要不要提供时间偏移量（Offset）？

这是提案中最激烈的交锋之一。

一些数据库专家强烈要求提供类似 NewV7WithOffset(offset) 的方法。他们认为，在极高并发的分布式数据库中，完全连续的时间戳会导致 B 树索引的写入热点（Hotspot）。通过稍微偏移时间戳，可以打散写入压力。同时，偏移也能隐藏真实的创建时间，保护隐私。

然而，Go 核心团队（neild）坚决拒绝了这个提议：

• 偏离规范：RFC 9562 的初衷就是利用时间局部性。如果你故意打乱时间，那为什么要用 V7？不如直接用 V4。
• 隐私悖论：如果你担心泄露创建时间，V7 本身就不是正确的选择。
• 增加复杂性：这属于极少数高级数据库引擎才会考虑的特性，不应该污染基础库的通用 API。

为什么没有 Version() 和 Time() 等解析方法？

在 google/uuid 中，你可以通过方法提取 UUID 的版本号或时间戳。但在新标准库中，这些被全部砍掉。

原因：遵循 RFC 9562 的“不透明性”（Opacity）原则。规范明确指出：“建议尽可能将 UUID 视为不透明（Opaque）的值，除非绝对必要，应避免解析 UUID。”

UUID 是用来比较和标识的，不是用来承载业务逻辑的。如果你试图从 UUID 中提取时间，并依此执行业务判断，那么你的架构设计大概率出了问题。

数据库集成与生态迁移

对于 Gopher 来说，UUID 最常见的作用就是存入数据库。

google/uuid 之所以流行，很大程度上是因为它实现了 database/sql/driver.Valuer 和 sql.Scanner 接口，可以无缝与各种 ORM（如 GORM）和数据库驱动配合。

令人惊讶的是，新的 crypto/uuid 并没有实现这些接口。

这是因为 Go 团队认为方向搞反了。 不应该是底层的 crypto 库去依赖 database/sql，而应该是 database/sql 原生认识 UUID 这种基础类型。

目前的计划是，与 crypto/uuid 同步，修改 database/sql 和底层驱动框架，使其在遇到 uuid.UUID 类型时，自动完成与字符串（或字节）的转换。这种解耦设计更加优雅。

小结

crypto/uuid 的提案，表面上只是增加了一个小小的包，实则又是一场关于 Go 工程哲学的集中展示：

1. 极度克制：砍掉 99% 开发者不需要的 80% 的功能（V1-V3, V5, 提取内部信息），只保留最核心的骨架（V4, V7, 解析, 格式化）。
2. 安全性优先：放在 crypto 目录下，强调其依赖密码学安全的随机数；拒绝支持已被攻破的弱哈希算法（MD5/SHA1）。
3. 零冗余处理：借助语言底层的进化（crypto/rand 必定成功），去掉了无意义的 error 返回。

对于我们普通的 Go 开发者来说，未来的迁移路径将非常简单：

当 Go 版本更新后，我们只需要将 import 路径从 github.com/google/uuid 替换为 crypto/uuid。由于底层类型都是 [16]byte，甚至不用担心性能下降。

告别那些臃肿的、历史包袱沉重的第三方库，拥抱一个清爽、安全、原生的 crypto/uuid，Gopher 们，准备好了吗？

资料链接：https://github.com/golang/go/issues/62026

---

你会第一时间切换吗？

面对即将到来的原生 crypto/uuid，你是支持“极简主义”的官方版本，还是离不开功能丰富的 google/uuid？在你的项目中，UUID V7 的单调递增特性是否真的解决了数据库索引碎片的问题？

欢迎在评论区分享你的看法，我们一起坐等 Go 1.27！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

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

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

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

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

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

---

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/02/11/go-1-26-json-v2-delay-7-technical-roadblocks

大家好，我是Tony Bai。

Go 1.26 预计将于本月（2026 年 2 月）正式发布。然而，在即将到来的 release notes 的欢呼声中，有一个备受瞩目的名字依然带着“实验性”的标签躲在 GOEXPERIMENT 背后——那就是 encoding/json/v2。

作为 Go 生态中最核心的基础设施之一，JSON 库的每一次呼吸都牵动着数百万开发者的神经。从 v1 到 v2，不仅仅是性能的提升，更是一场关于API 设计哲学、向后兼容性与极致性能的艰难博弈。

很多人以为 v2 的延迟是因为“官方动作慢”或“设计理念之争”。但当我们深入 json/v2 工作组的看板，剥开表层的讨论，会发现横亘在稳定版之前的，是七个具体而微、却又关乎全局的技术“钉子”。这些问题并非宏大的路线图分歧，而是关乎浮点数精度、错误处理语义、API 封装性等实打实的工程细节。

本文将基于最新的 GitHub Issues 讨论（截至 2026 年 2 月），带你通过显微镜审视这七大阻塞问题，一窥 Go 标准库演进背后的严谨与妥协。

七大阻塞问题（Blockers）一览

深度解析：魔鬼藏在细节中

1. API 设计的“丑陋妥协”：jsontext.Internal (#73435)

在当前的 encoding/json/jsontext 包中，竟然存在一个导出的 Internal 类型。这在 Go 标准库的审美中，简直是“房间里的大象”。

jsontext 是 v2 引入的底层包，专注于 JSON 的语法解析（Tokenizing），而上层的 json 包负责语义绑定（Binding）。为了让上层包能够访问底层的缓冲区或状态机，当前的实现不得不导出一个 Internal 符号。

这违背了 Go 标准库的黄金法则之一：公共 API 必须是为用户设计的，而不是为实现者自己设计的。

Joe Tsai (dsnet) 提出了一种解决方案：将 jsontext 的核心逻辑移入 encoding/json/internal/jsontext，然后通过类型别名（Type Alias）在公共包中暴露 API。然而，这带来了一个新的难题：godoc 对类型别名的支持并不友好，生成的文档可能会让用户感到困惑，因为方法都挂载在内部类型上。

这个问题已经上升为工具链生态问题。如果这个问题不解决，v2 发布后将面临两个风险：要么用户依赖了这个“临时” API 导致未来无法修改，要么标准库留下了一个永久的“伤疤”。

2. 致命的递归：当 Unmarshaler 遇到指针 (#75361)

这是一个真实且诡异的 Bug。一位开发者在迁移旧代码时发现，以下模式在 v1 中正常工作，但在开启 GOEXPERIMENT=jsonv2 后会导致栈溢出（Stack Overflow）：

type MyType string

// 自定义 Unmarshal 方法
func (m *MyType) UnmarshalJSON(b []byte) error {
    // 试图通过定义一个新类型来“剥离”当前类型的方法，以回退到默认行为
    type MyTypeNoMethods *MyType
    var derived MyTypeNoMethods = MyTypeNoMethods(m)

    // v2 在这里会错误地再次识别出 derived 拥有 UnmarshalJSON 方法
    // 从而导致无限递归调用自己
    return json.Unmarshal(b, derived)
}

在 v1 中，开发者习惯通过类型转换来“剥离”自定义方法。但在 v2 中，为了修复 v1 中某些指针方法无法被调用的 Bug（如 #22967），引入了更激进的方法集查找逻辑。

v2 的逻辑是：只要这个值的地址（Addressable）能找到 UnmarshalJSON 方法，就调用它。在上面的例子中，derived 虽然是新类型，但它底层的指针指向的还是 MyType，v2 过于“聪明”地认为应该调用 (MyType).UnmarshalJSON，结果造成了死循环。

这是一个典型的“修复了一个 Bug，却引入了另一个 Bug”的案例。Go 团队目前倾向于保留 v2 的正确逻辑（即更一致的方法调用），但也必须为这种遗留代码提供一种检测机制。目前的计划是引入运行时检测或 go vet 检查，明确告知用户：请使用 type MyTypeNoMethods MyType（非指针别名）来剥离方法，而不是使用指针别名。

3. 浮点数的“薛定谔精度”：float32 (#76430)

下面是展示该问题的一段示例代码：

var f float32 = 3.1415927 // math.Pi 的 float32 近似值
json.Marshal(f)

输出应该是 3.1415927（保持 float32 精度），还是 3.1415927410125732（提升到 float64 精度以确保无损）？

Go v1 的 json 包为了兼容性，倾向于将所有浮点数视为 float64 处理。这导致 float32 在序列化时经常会出现“精度噪音”——那些用户并不想要的、只有在 float64 精度下才有意义的尾数。

然而，v2 的 jsontext 包默认使用 64 位精度。这导致了 json.Marshal（上层）和 jsontext.Encoder（底层）在行为上的不一致。

• 用户期望：float32 就该像 float32，短小精悍。
• 技术现实：JSON 标准（RFC 8259）并没有区分浮点精度。
• 性能视角：处理 32 位浮点数理论上更快，但需要专门的算法路径。

Go 团队正在考虑引入 Float32 构造器和访问器到 jsontext 包中，并修改底层的 AppendFloat 逻辑，以支持显式的 32 位浮点数格式化。这不仅是为了“好看”，更是为了数值正确性——避免“双重舍入”（Double Rounding）带来的微小误差。

4. 选项系统的“任督二脉”：透传难题 (#76440)

你调用 json.Marshal(v, json.WithIndent(” “)) 很爽，但如果你想控制底层的 jsontext 行为（比如“允许非法 UTF-8”或“允许重复键名”），你发现：顶层函数把路堵死了。目前的 MarshalEncode 只接受 json.Option，不接受 jsontext.Option。

v2 将 json（语义层）和 jsontext（语法层）拆分是架构的一大进步。但这也带来了配置穿透的问题。

如果为了保持 API 纯洁，强迫用户必须先创建一个 jsontext.Encoder 并在那里配置选项，再传给 json.MarshalEncode，那么 99% 的简单用例都会变得无比繁琐。

Go团队给出的提案是打破层级隔离，允许 json.Marshal 等顶层函数直接接受 jsontext.Option。这是一个实用主义战胜洁癖的胜利。

5. 功能做减法：unknown 标签的存废 (#77271)

v2 曾引入了一个 unknown 结构体标签，用于指示某个字段专门用来捕获所有未知的 JSON 字段。同时，还有一个 DiscardUnknownMembers 选项用于丢弃未知字段。

dsnet（Joe Tsai）发起提案，建议删除两个功能。理由如下：

1. 功能重叠：v2 已经引入了 inline 标签，它与 unknown 的行为非常相似，仅仅是语义上的微小差别（是否包含“已知”字段）。这种微小的差别会让用户感到困惑。
2. API 极简主义：如果用户真的需要处理未知字段，可以通过自定义 Unmarshaler 来实现，或者利用 inline 标签配合后期处理。
3. 向后兼容的智慧：添加功能永远比删除功能容易。现在删除，未来如果真有需求还可以加回来；但如果现在保留，未来想删就难了。

6. 控制流的缺失：SkipFunc (#74324)

json.SkipFunc 是 v2 引入的一个 Sentinel Error，用于告诉编码器“跳过当前字段/值”。目前它只能在 MarshalToFunc（用户自定义函数）中使用。但如果我在类型的方法 MarshalJSONTo 中想跳过自己怎么办？目前是不支持的。

这是一个典型的“二等公民”问题。用户自定义的函数拥有比类型方法更高的权限。这导致在迁移旧代码时，如果要实现“条件性跳过”，必须写出非常丑陋的 hack 代码（比如定义一个空结构体来占位）。

允许 MarshalJSONTo 返回 SkipFunc 看似简单，但它要求调用者必须处理这个错误。这意味着不能直接调用 v.MarshalJSONTo，而必须通过 json.Marshal 来调用，否则你会收到一个未处理的错误。这需要文档和工具链的配合。

7. 文档真空：新接口的最佳实践 (#76712)

v2 引入了 MarshalerTo 和 UnmarshalerFrom 两个高性能接口，它们直接操作 jsontext.Encoder/Decoder，避免了内存分配。但是，到底该什么时候用它们？

目前缺乏明确的文档指导。如果用户在任何时候都直接调用 v.MarshalJSONTo(enc)，可能会绕过 json.Marshal 中处理的许多全局选项（如大小写敏感、省略零值等）。

Go 团队计划在文档中明确：这属于“高级 API”，普通用户应始终使用 json.Marshal，除非你在编写极其底层的库。

路线图：我们何时能用上“真v2”？

根据最新的工作组纪要和 Issue 状态，我们可以画出一条清晰的时间线：

• 当前 (Go 1.26, 2026.02)：GOEXPERIMENT=jsonv2 继续存在。v2 代码库已进入主仓库，但 API 仍未冻结。此时适合库作者进行集成测试，但不建议在生产环境核心业务中大规模铺开。
• 决战期 (2026 H1)：必须彻底解决上述 7 个 Blocker。特别是 API 签名相关的修改（如 float32 支持和 SkipFunc），一旦定型就是 10 年承诺。
• 目标 (Go 1.27, 2026.08)：如果一切顺利，我们有望在今年 8 月发布的 Go 1.27 中，看到移除实验标签、正式可用的 encoding/json/v2。这意味着 Go 语言将迎来其历史上最大规模的标准库升级之一。

小结：给 Gopher 的建议

1. 别急着重构：现有的 encoding/json (v1) 依然稳健。除非你有极端的性能需求（v2 性能提升显著）或需要 v2 独有的某些特性，否则请按兵不动。
2. 关注 jsontext：即使不用 v2 的序列化，新独立的 jsontext 包也是一个处理 JSON Token 流的神器，非常适合写高性能的底层解析工具。它的 API 设计比 v1 的 Scanner 更加现代化和高效。
3. 参与反馈：现在是影响 Go 未来 10 年 JSON 处理方式的最后窗口期。如果你对上述 Issue 有独到见解，去 GitHub 上发声吧！

Go 团队的“慢”，是对生态的“敬”。这七个拦路虎，每一个都是为了让未来的十年里，我们能写出更少 Bug、更快速度的 Go 代码。好事多磨，让我们静候佳音。

参考资料

• json/v2 工作组的看板 – https://github.com/orgs/golang/projects/50
• encoding/json/v2: working group meeting minutes – https://github.com/golang/go/issues/76406

---

你更在意什么？

Go 团队为了 API 的洁癖和严谨，宁愿让 json/v2 多飞一会儿。在你的开发实践中，你更倾向于“尽快用上新特性”，还是“哪怕慢一点也要保证接口设计的绝对完美”？你对 float32 的精度噪音有切肤之痛吗？

欢迎在评论区分享你的看法，我们一起坐等 Go 1.26 官宣！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

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

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

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

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

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

---

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/02/05/brad-fitzpatrick-cachelink-reduce-go-test-wait-time

大家好，我是Tony Bai。

在维护大型 Go 单体仓库（Monorepo）时，你是否遇到过这样的场景：明明只是修改了测试的运行参数（比如 -run 的正则），或者在不同的 CI 节点上运行同一个包的测试，却发现 go test 依然在缓慢地执行“链接（Linking）”步骤？

对于代码量巨大的项目，链接过程往往是构建链条中最耗时的一环。为了解决这一痛点，Go 社区领袖、Tailscale 核心开发者 Brad Fitzpatrick 近日提交了 #77349 提案，建议引入 -cachelink 标志。这一看似微小的改动，有望在分布式测试和重复执行场景下，显著“挤出”原本被浪费的等待时间。

被忽视的瓶颈：重复链接的代价

Go 的构建缓存（GOCACHE）机制已经非常高效，它能很好地缓存编译阶段的中间产物（.a 文件）。但是，当你运行 go test 时，工具链的最后一步——将所有依赖链接成一个可执行的测试二进制文件——通常是“一次性”的。

这意味着，即使你的代码没有任何变动，只要测试指令稍有变化（例如多次运行 go test 但指定不同的测试用例），Go 工具链往往会重新触发链接器。

# 第一次运行：链接 + 执行
$ go test -run=^TestFoo$ ./pkg/

# 第二次运行（代码未变）：依然触发重新链接 + 执行
$ go test -run=^TestBar$ ./pkg/

对于依赖项数以千计的大型项目，链接过程可能长达数秒甚至更久。在本地频繁调试或 CI 流水线中，这些重复的秒数累积起来就是巨大的时间浪费。

Brad 的解法：-cachelink

Brad Fitzpatrick 的提案非常直接：允许将链接器输出的最终测试二进制文件，也写入 GOCACHE。

通过显式开启 -cachelink，go test 的行为将发生变化：

1. 它会基于构建输入（代码、依赖、环境变量等）计算哈希。
2. 如果发现 GOCACHE 中已经存在已链接好的测试二进制文件。
3. 直接跳过链接步骤，复用该文件进行测试。

这样，上述例子中的第二次调用将瞬间启动，因为最耗时的构建步骤被完全省去了。

为什么不做成默认行为？

既然能提速，为什么不默认开启？Brad 在提案讨论中给出了专业的权衡分析：

空间 vs. 时间。

测试二进制文件通常包含完整的符号表和调试信息，体积比普通的中间对象文件大得多。如果默认缓存所有测试二进制文件，开发者的磁盘空间（GOCACHE）会迅速膨胀。因此，这是一个以空间换时间的策略，更适合由开发者根据项目规模手动开启，或者在 CI 环境中配置。

分布式 CI 的“加速器”

该提案真正的杀手级应用场景是 分布式 CI 系统。

许多大厂使用 GOCACHEPROG 来在构建集群间共享缓存。在典型的 CI 流程中，测试任务往往会被分片（Sharding）到数十台机器上并发执行。

• 现状：每一台机器拉取源码后，都需要各自进行一次链接操作，浪费计算资源。
• 引入 -cachelink 后：第一台完成构建的机器会将二进制文件上传到共享缓存。后续几十台机器直接下载该文件并运行，全集群的链接成本降为“1”。

不仅是 go test -c

有经验的开发者可能会问：“我为什么不直接用 go test -c 手动编译成二进制文件，然后分发运行呢？”

Brad 指出，手动管理二进制文件会绕过 Go 原生的测试结果缓存。而 -cachelink 的精妙之处在于，它既复用了二进制文件，又保留了 go test 完整的缓存与输出管理体验。你不需要编写复杂的脚本来管理这些文件，一切依然由 go 命令自动处理。

小结

目前，该提案已进入活跃评审阶段，并有了初步的代码实现。对于深受“构建慢”和“测试慢”困扰的大型项目维护者来说，这无疑是一个值得期待的性能优化利器。我们有望在 Go 1.27 或后续版本中见证它的落地。

资料链接：https://github.com/golang/go/issues/77349

---

聊聊你的构建之苦

链接时间正在成为你的“带薪摸鱼”理由吗？在你的项目中，go test 运行一次通常需要多久？你为了缩短测试反馈周期，还尝试过哪些黑科技（比如 GOCACHEPROG）？

欢迎在评论区分享你的实战经验或吐槽！让我们一起期待 -cachelink 的落地。

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

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

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

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

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

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

---

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/02/03/russ-cox-15-year-war-on-floating-point-conversion

大家好，我是Tony Bai。

“浮点数到十进制的转换一直被认为很难。但本质上，它们非常简单直接。” —— Russ Cox (2011)

“我错了。快速的转换器也可以很简单，这篇文章将展示如何做到。” —— Russ Cox (2026)

在计算机科学的深处，潜伏着一条名为“浮点数转换”的恶龙。将一个二进制浮点数（如 float64）转换为人类可读的十进制字符串（如 “0.1″），看似简单，实则是一个困扰了业界半个世纪的难题。

2011 年，Go 语言的核心人物 Russ Cox 写下了一篇博文，试图用一种简单的算法来“驯服”这条龙。然而，在随后的十几年里，学术界和工业界爆发了一场军备竞赛：Dragon4, Grisu3, Ryū, Schubfach, Dragonbox… 每一个新算法都试图在速度上压倒前一个，但也让代码变得越来越复杂，数学证明越来越晦涩。

2026 年初，Russ Cox 带着他的新系列文章强势回归。这一次，他不仅带来了一套比所有已知算法都更快的全新算法，而且证明了：极致的性能不需要极致的复杂性。

这套算法已被确定将在 Go 1.27 (2026年8月) 中发布。今天，我们就来深度解析这项可能改写浮点数处理历史的技术突破。

历史的迷宫与“不可能三角”

要理解 Russ Cox 的成就，我们首先要理解这个问题的难度。一个完美的浮点数打印算法，必须同时满足三个苛刻的条件（“不可能三角”）：

1. 正确性 (Correctness)：转换必须是双射的。Parse(Print(f)) == f 必须恒成立。这意味着你不能随意丢弃精度。
2. 最短性 (Shortest)：输出的字符串必须是所有能转回原值的字符串中最短的。例如，0.3 在二进制中无法精确表示，打印时应该是 “0.3″ 而不是 “0.2999999999999999889″。
3. 速度 (Speed)：在大规模数据处理（如 JSON 序列化）中，转换速度直接决定了系统的吞吐量。

历史的演进：
* Dragon4 (1990)：实现了正确性和最短性，但依赖大整数（BigInt）运算，慢如蜗牛。
* Grisu3 (2010)：Google 的 V8 引擎引入。速度极快，但不保证最短性，约 0.5% 的情况会失败并回退到慢速算法。
* Ryū (2018) & Dragonbox (2020)：通过复杂的数学技巧（查表法），终于在不使用 BigInt 的情况下实现了正确且最短。这是性能的巅峰，但代码极其复杂，充满魔术数字。

Russ Cox 的目标，就是打破这个迷宫：能不能既像 Ryū 一样快且正确，又像 2011 年的那个算法一样简单？

核心技术——“未舍入缩放” (Unrounded Scaling)

Russ Cox 的新算法核心，源于一个极其精妙的数学原语：快速未舍入缩放 (Fast Unrounded Scaling)。

什么是“未舍入数”？

在传统算法中，我们总是纠结于“何时舍入”。Russ Cox 引入了 “未舍入数” (Unrounded Number) 的概念 ⟨x⟩。它由三部分组成：

• 整数部分: floor(x)
• ½ bit: 标记 x – floor(x) >= 0.5
• sticky bit (粘滞位): 标记 x 是否有非零的小数残余。

这种表示法不仅保留了用于正确舍入（Round half to even）的所有必要信息，而且可以通过极其廉价的位运算（| 和 &）来维护。这就像是在计算过程中保留了一个“高精度的尾巴”，直到最后一步才决定如何截断。

缩放的魔法

浮点数打印本质上是计算 f = m * 2^e 对应的十进制 d * 10^p。核心步骤是将 m * 2^e 乘以 10^p。

Russ Cox 使用查表法（预计算 10^p 的 128 位近似值）来实现这一缩放。但他最惊人的发现是：在 64 位浮点数转换的场景下，我们甚至不需要完整的 128 位乘法！

他证明了：只需计算 64 位 x 64 位的高位结果，并利用低位的“粘滞位”来修正，就能得到完全正确的结果。这意味着，曾经需要几十次乘法或大整数运算的转换过程，现在被缩减为极少数几次 CPU 原生乘法。

这一发现被称为 “Omit Needless Multiplications”（省略不必要的乘法），它是新算法性能超越 Ryū 的关键。

从理论到 Go 1.27

基于这个核心原语，Russ Cox 构建了一整套算法家族：

• FixedWidth: 定点打印（如 %.2f）。
• Shortest: 最短表示打印（如 %g）。
• Parse: 字符串转浮点数。

性能碾压

Russ Cox 在 Apple M4 和 AMD Ryzen 9 上进行了详尽的基准测试：

• 定点打印：新算法 (uscale) 显著快于 glibc 和 double-conversion，甚至快于 Ryū。
• 最短打印：在纯算法层面，新算法与业界最快的 Dragonbox 持平或更快，但代码逻辑要简单得多。
• 解析：同样基于该原理的解析算法，性能超越了目前业界标杆 fast_float (Eisel-Lemire 算法)。

更令人兴奋的是，Go 1.27 将直接集成这套算法或算法的一部分。对于 Gopher 来说，这意味着你的 fmt.Sprintf、json.Marshal 和 strconv.ParseFloat 将在下个版本中自动获得显著的性能提升，而无需修改一行代码。

证明的艺术

除了代码，Russ Cox 还做了一件很“极客”的事：他用 Ivy（一种 APL 风格的语言）编写了完整的数学证明。

他没有选择形式化验证工具（如 Coq），而是通过编写可执行的代码来验证算法在每一个可能的 float64 输入下都是正确的。这种“通过计算来证明” (Proof by Computation) 的方法，不仅验证了算法的正确性，也为后来者留下了一份可交互的、活生生的文档。

小结：简单是终极的复杂

从 2011 年的初次尝试，到 2026 年的最终突破，Russ Cox 用 15 年的时间完成了一个完美的闭环。

这一系列文章是一种工程哲学的胜利。它告诉我们：当我们面对复杂的遗留问题时，不要只是盲目地堆砌优化技巧。回到数学的源头，重新审视问题的本质，或许能找到那条既简单又快的“捷径”。

现在的 Go 标准库中，即将拥有一颗比以往任何时候都更强大、更轻盈的“心脏”。

资料链接：https://research.swtch.com/fp-all

---

你更看重哪一点？

在算法的世界里，正确性、最短表示、运行速度，这“不可能三角”总是让我们反复权衡。在你平时的开发中，有哪些场景曾让你被浮点
能或精度困扰？或者，你对 Russ Cox 这种“死磕 15 年”的工程精神有何感触？

欢迎在评论区分享你的看法！如果这篇文章让你对浮点数实现算法方面有了新的认识，别忘了点个【赞】和【在看】，并转发给你的Go开发朋友们！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

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

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

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

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

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

---

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/02/02/beads-bd-distributed-task-tracking-engine-for-ai-agent

大家好，我是Tony Bai。

在 AI 编码智能体（如 Claude Code、Gemini CLI 等）日益普及的今天，我们面临着一个棘手的工程难题：AI Agent 虽然极其聪明，但它们通常是”健忘”的。

它们在处理一个长期、复杂的重构任务时，往往会在海量的上下文切换中迷失方向。传统的 Issue Tracker（如 Jira）对 AI 来说太重、太慢且难以集成；而简单的 Markdown 文件又缺乏结构化和版本控制。

于是，Beads（命令行工具 bd）应运而生。它是 Gas Town —— 那个被誉为 AI Coding 领域”Kubernetes”的宏大愿景 —— 的底层记忆基石。它巧妙地利用 Git 作为分布式数据库，为 AI Agent 提供了一个持久化、可协作、依赖感知的任务追踪系统。

为什么 AI Agent 需要 Beads？

传统的软件工程工具是为人类设计的，而 Beads 是为AI 智能体设计的。

上下文的持久化

AI 模型的上下文窗口（Context Window）虽然越来越大，但依然昂贵且有限。当一个 Agent 需要处理跨越数周、涉及数百个文件的任务时，它不能一直把所有信息都塞进 Prompt 里。

Beads 提供了一个外部的、结构化的存储，让 Agent 可以随时”卸载”和”重载”任务状态，就像人类使用笔记本一样。

原生的依赖管理

复杂的编码任务往往是一张有向无环图（DAG）：“先重构数据库 Schema，再更新 API，最后修复前端。”

Beads 原生支持任务依赖（Dependency Graph）。它能自动计算出当前的 Ready Work（就绪工作） ，告诉 Agent：”别瞎忙，现在你只能做这个，其他的都还被阻塞着。”

分布式协作

如果是多个 Agent（或者人类与 Agent）同时工作怎么办？

Beads 将任务数据存储为 .beads/ 目录下的 JSONL 文件。 这意味着：任务即代码。你可以像合并代码一样，通过 Git 分支、合并、解决冲突来管理任务。

核心架构：Git as a Database

Beads 的设计哲学极其硬核：它不想引入任何外部的中心化服务，它只想利用你现有的 Git 仓库。

三层分层架构：清晰的职责边界

Beads 采用了经典的三层架构，但在每一层都做了针对性的优化：

• CLI Layer：基于 spf13/cobra 构建，负责命令解析和用户交互。 它不直接操作数据，而是优先通过 RPC 与守护进程通信，失败时才降级到直接数据库访问。
• Daemon Process：每个工作区运行独立的后台守护进程，处理 RPC 请求、协调自动同步时机，并持有数据库连接以加速查询。通过 Unix domain socket（Windows 上为 named pipes）进行通信。
• Storage Layer：这是核心。它通过接口隔离原则定义了 Storage 接口，支持 SQLite、Dolt 甚至内存等多种后端。这种设计使得底层的存储实现可以被轻松替换，而不影响上层逻辑。

更为完整的架构参考下图：

来自deepwiki.com对beads源码的分析结果

双存储写屏障：SQLite 与 JSONL 的完美同步

Beads 最精妙的设计之一是它的双存储写屏障 (Dual-Storage Write Barrier)。它是如何解决 SQLite（高性能查询）与 JSONL（版本控制）之间的数据一致性的呢？

• 写入路径：当用户创建任务时，数据首先写入 SQLite，保证了毫秒级的操作反馈。
• 防抖刷新 (Debounced Flush)：为了避免频繁的磁盘 I/O 和 Git 操作，Beads 实现了一个基于 Go Channel 的事件驱动 FlushManager。所有 flush 状态（isDirty、needsFullExport、debounceTimer）由单个后台 goroutine 拥有，通过 channel 通信消除了竞态条件。

系统默认配置 30 秒的防抖窗口（可通过 flush-debounce 配置调整），这为批量操作提供了”事务窗口”——30 秒内的多次修改会被合并成一次 JSONL 导出，避免了频繁的 Git commit。

这种机制确保了在高频操作下（如批量导入），系统不会因为频繁的 Git Commit 而卡顿。

并发安全与锁机制

在分布式和多进程环境下，数据竞争是最大的敌人。Beads 采取了多重防御：

• 进程级互斥：使用文件锁（Unix 上为 flock，Windows 上为 LockFileEx）对守护进程（daemon.lock）和同步操作（.sync.lock）加锁，确保同一时间只有一个守护进程在运行，且不会有并发的 sync 操作导致数据损坏。

• 数据库连接池优化：SQLite 连接池根据数据库类型进行智能配置：

  • 内存数据库：SetMaxOpenConns(1) 强制单连接，因为 SQLite 的内存数据库在连接间是隔离的。
  • 文件数据库：SetMaxOpenConns(runtime.NumCPU() + 1) 利用 SQLite WAL 模式的”1 writer + N readers”特性，同时防止写锁竞争导致的 goroutine 堆积。

• Context 传播：所有的存储操作都强制要求传递 context.Context，确保了超时控制和优雅退出的能力，这对于一个长期运行的后台守护进程至关重要。

自适应哈希 ID：算法的胜利

为了在”简短易读”和”全局唯一”之间取得平衡，Beads 没有使用 UUID，而是设计了一套自适应哈希算法：

• 综合哈希源：ID 并非简单的标题哈希，而是综合了 title、description、creator、timestamp 和 nonce 的 SHA256 哈希，确保了即使标题相同，不同时间创建的 issue 也有不同的 ID。

• Base36 编码：使用 base36（0-9, a-z）而非 hex 编码，提供了更高的信息密度，让 ID 更短。

• 动态长度：系统根据当前数据库的规模，使用生日悖论数学计算碰撞概率，自动调整 ID 的长度：

  • 小型数据库：bd-a1b2 (4 字符)
  • 中型数据库：bd-a1b2c3 (6 字符)
  • 大型数据库：最多 8 字符

• 碰撞处理：在生成 ID 时，如果检测到碰撞，系统会尝试最多 10 个 nonce 值，如果仍然碰撞，则增加哈希长度。这是一种典型的用计算换取协作体验的策略。

Beads Issue 状态

Beads 定义了 8 个核心状态：

• open – 可开始的工作
• in_progress – 正在进行中
• blocked – 被依赖阻塞
• deferred – 暂时延期
• closed – 已完成
• tombstone – 软删除（30天后清理）
• pinned – 永久保持开放
• hooked – AI智能体钩子工作

它们的状态机转换流程如下图所示：

这个状态机设计确保了数据一致性、合并安全性和自动化工作流。

依赖管理的多样性

Beads 支持多种依赖类型，不同类型有不同的语义：

• blocks：阻塞依赖，Issue X 必须关闭后 Y 才能开始，影响 bd ready 计算
• parent-child：层级关系，用于 Epic 和子任务，父节点被阻塞时子节点也被阻塞
• related：软链接，仅用于引用，不影响执行顺序
• discovered-from：记录在执行某任务时发现的新问题

系统使用递归 CTE(Common Table Expression) 检测循环依赖，确保依赖图始终是一个有向无环图（DAG）。

Blocked Issues Cache：性能的飞跃

在大型项目中，实时计算哪些 issue 被阻塞可能非常耗时。Beads 引入了 Blocked Issues Cache 机制，这是一个关键的性能优化：

• 问题：在 10K issue 的数据库上，使用递归 CTE 实时计算阻塞状态需要约 752ms。
• 解决方案：使用 blocked_issues_cache 表物化阻塞计算结果。
• 效果：查询时间降至约 29ms，性能提升 25 倍。

缓存在每次依赖变更或状态变更时完全重建（DELETE + INSERT），虽然重建需要 <50ms，但由于依赖变更相对读取操作非常罕见，这个权衡是值得的。

实战：Agent 的工作流

让我们看看在一个典型的 AI 编码场景中，Beads 是如何工作的。

场景：你需要重构一个遗留系统的用户认证模块。

1. 初始化与规划：
   Agent 首先通过 bd create 创建主任务（Epic）。 注意，Beads 支持层级 ID，这对于 AI 拆解任务非常有帮助。

   # 创建 Epic
   $ bd create "重构用户认证模块"
   Created: bd-auth01
   
   # 拆分子任务（注意：Beads 支持层级结构，或者我们可以手动关联）
   $ bd create "设计新 User 表结构"
   Created: bd-db002
   
   $ bd create "迁移旧数据"
   Created: bd-migr03
   
   $ bd create "切换 API 逻辑"
   Created: bd-api004
   

2. 建立依赖：
   Agent 知道事情有轻重缓急，它会建立依赖关系。根据 bd dep add 格式（child 依赖 parent，即 parent blocks child）：

   # bd-migr03 (Child) 依赖于 bd-db002 (Parent)
   # 意味着：必须先设计完表结构，才能迁移数据
   $ bd dep add bd-migr03 bd-db002
   
   # bd-api004 (Child) 依赖于 bd-migr03 (Parent)
   # 意味着：必须先迁移完数据，才能切换 API
   $ bd dep add bd-api004 bd-migr03
   

3. 获取就绪工作：
   Agent 不再迷茫，它只需要问 Beads：”我现在能做什么？”

   $ bd ready --json
   {
     "issues": [
       {
         "id": "bd-db002",
         "title": "设计新 User 表结构",
         "status": "pending",
         "blocks": ["bd-migr03"]
         ...
       }
     ]
   }
   

   Beads 会告诉它，只有”设计表结构”是 Ready 的，其他的都被阻塞了。

4. 执行与更新：
   Agent 完成任务后，关闭 Issue。

   $ bd close bd-db002
   

   此时，后台的 blocked cache 自动重建，”迁移旧数据” (bd-migr03) 的任务状态瞬间变为 Ready。

高阶实战：Claude Code 与 Beads 的”双人舞”

如果说上面的命令是基本舞步，那么当 Claude Code 遇上 Beads，它们能跳出怎样的双人舞？让我们看一个“任务中断与恢复”的真实场景。

0. 前置配置：教会 Claude 使用工具

要让 Claude Code 懂得使用 Beads，我们首先需要在项目的根目录下创建一个CLAUDE.md 文件(其它Coding agent一般支持AGENTS.md)。这是 Claude Code 的”行动指南”。

创建beads-demo目录，使用git init初始化该目录：

$mkdir beads-demo
$cd beads-demo
$git init .

执行bd init初始化该目录：

bd init
  Repository ID: 3f0bbad4
  Clone ID: c15058f43e4678f2
  ✓ Created AGENTS.md with landing-the-plane instructions

✓ bd initialized successfully!

  Backend: sqlite
  Database: .beads/beads.db
  Issue prefix: beads-demo
  Issues will be named: beads-demo-<hash> (e.g., beads-demo-a3f2dd)

Run bd quickstart to get started.

⚠ Setup incomplete. Some issues were detected:
  • Git Hooks: Missing 1 recommended hook(s)
  • Sync Divergence: 1 sync divergence issue(s) detected
  • Claude Integration: Not configured
  • Git Working Tree: Uncommitted changes present
  • Git Upstream: No upstream configured for master
  • Version Tracking: Version tracking not initialized

Run bd doctor --fix to see details and fix these issues.

beads创建了AGENTS.md文件，我们将之改名为CLAUDE.md，并写入下面这行文字：

$mv AGENTS.md CLAUDE.md
$echo "Use 'bd' for task tracking" >> CLAUDE.md

有了CLAUDE.md 这份”说明书”，Claude Code 就会在启动时自动扫描并理解这套规则。

1. 记忆的建立

场景：你让 Claude Code (在plan模式下，disable一些不必要的插件或skill)使用 Go 开发一个”简单的并发下载器”。它会创建了任务，并建立任务间的依赖关系：

● Bash(bd create --type feature --title "项目初始化" --description "初始化Go项目结构和基础配置…)
  ⎿  ✓ Created issue: beads-demo-dee
       Title: 项目初始化
       Priority: P2
       Status: open                                                                                                               

● Bash(bd create --type feature --title "核心下载逻辑实现" --description "实现下载器的核心功能…)
  ⎿  ✓ Created issue: beads-demo-9uq
       Title: 核心下载逻辑实现
       Priority: P2
       Status: open                                                                                                               

● Bash(bd create --type feature --title "进度显示实现" --description "实现终端进度条功能…)
  ⎿  ✓ Created issue: beads-demo-8pf
       Title: 进度显示实现
       Priority: P2
       Status: open                                                                                                               

● Bash(bd create --type feature --title "断点续传实现" --description "实现状态持久化和恢复功能…)
  ⎿  ✓ Created issue: beads-demo-fhv
       Title: 断点续传实现
       Priority: P2
       Status: open                                                                                                               

● Bash(bd create --type feature --title "CLI入口实现" --description "实现命令行工具入口…)
  ⎿  ✓ Created issue: beads-demo-4bb
       Title: CLI入口实现
       Priority: P2
       Status: open 

... ...

● 现在设置依赖关系：                                                                                     09:24 AM  glm-4.7        

● Bash(bd dep add beads-demo-9uq --blocked-by beads-demo-dee)
  ⎿  ✓ Added dependency: beads-demo-9uq depends on beads-demo-dee (blocks)                                                        

● Bash(bd dep add beads-demo-8pf --blocked-by beads-demo-9uq)
  ⎿  ✓ Added dependency: beads-demo-8pf depends on beads-demo-9uq (blocks)                                                        

● Bash(bd dep add beads-demo-fhv --blocked-by beads-demo-9uq)
  ⎿  ✓ Added dependency: beads-demo-fhv depends on beads-demo-9uq (blocks)                                                        

● Bash(bd dep add beads-demo-4bb --blocked-by beads-demo-9uq --blocked-by beads-demo-8pf --blocked-by beads-demo-fhv)
  ⎿  ✓ Added dependency: beads-demo-4bb depends on beads-demo-fhv (blocks)                                                        

● Bash(bd dep add beads-demo-4id --blocked-by beads-demo-4bb)
  ⎿  ✓ Added dependency: beads-demo-4id depends on beads-demo-4bb (blocks)                                                        

● Bash(bd list)
  ⎿  ○ beads-demo-4id [● P2] [task] - 编写测试
     ○ beads-demo-4bb [● P2] [feature] - CLI入口实现
     ○ beads-demo-fhv [● P2] [feature] - 断点续传实现
     ○ beads-demo-8pf [● P2] [feature] - 进度显示实现
     ○ beads-demo-9uq [● P2] [feature] - 核心下载逻辑实现
     ○ beads-demo-dee [● P2] [feature] - 项目初始化                                                                               

● Bash(bd graph --all)
  ⎿  Dependency graph for beads-demo-4id:                                                                                      

       Status: ○ open  ◐ in_progress  ● blocked  ✓ closed                                                                         

       Layer 0 (ready)
       ┌────────────────────────────┐
       │ ○ 项目初始化                    │
       │ beads-demo-dee             │
       │ blocks:1                   │
       └────────────────────────────┘
           │
           ▼                                                                                                                      

... ...
∴ Thinking…                                                                                                                       

  现在bd issues已经创建完成，依赖关系也设置好了。我可以看到：- Layer 0: 项目初始化 (ready)
  - Layer 1: 核心下载逻辑实现
  - Layer 2: 进度显示实现、断点续传实现
  - Layer 3: CLI入口实现
  - Layer 4: 编写测试                                                                                                             

  现在我需要调用ExitPlanMode来请求用户批准计划。                                                                                  

● 完美！bd issues已创建完成，依赖关系如下：                                                              09:25 AM  glm-4.7        

  Layer 0 (ready):     项目初始化
             │
             ▼
  Layer 1:            核心下载逻辑实现
             │
             ├──────────────┐
             ▼              ▼
  Layer 2:      进度显示实现    断点续传实现
             │              │
             └──────┬───────┘
                    ▼
  Layer 3:            CLI入口实现
                    │
                    ▼
  Layer 4:            编写测试                                                                                                    

  现在退出计划模式，准备开始实现：

之后让Claude Code基于bd中的任务逐个进行实现即可。

❯ 使用bd获取要完成的任务并实现任务。                                                                                              

● Bash(bd ready)
  ⎿  Ready work (1 issues with no blockers):                                                                                   

     1. [● P2] [feature] beads-demo-dee: 项目初始化                                                                               

● Bash(bd list)
  ⎿  ○ beads-demo-4id [● P2] [task] - 编写测试
     ○ beads-demo-4bb [● P2] [feature] - CLI入口实现
     ○ beads-demo-fhv [● P2] [feature] - 断点续传实现
     … +3 lines (ctrl+o to expand)                                                                                                

● Bash(bd show beads-demo-dee)
  ⎿  ○ beads-demo-dee · 项目初始化   [● P2 · OPEN]
     Owner: Tony Bai · Type: feature
     Created: 2026-01-27 · Updated: 2026-01-27
     … +11 lines (ctrl+o to expand)                                                                                               

● Bash(bd update beads-demo-dee --status in_progress)
  ⎿  ✓ Updated issue: beads-demo-dee                                                                                              

● 开始执行项目初始化：                                                                                                            

● Bash(mkdir -p cmd/downloader pkg/downloader)
  ⎿  (No content)                                                                                                                 

● Bash(go mod init github.com/tonybai/beads-demo)
  ⎿  go: creating new go.mod: module github.com/tonybai/beads-demo
     go: to add module requirements and sums:
        go mod tidy                                                                                                               

● Write(README.md)
  ⎿  Wrote 43 lines to README.md
       1 # beads-downloader
       2
       3 A simple concurrent download tool written in Go.
       4
       5 ## Features
       6
       7 - Concurrent chunked download with automatic HTTP Range detection
       8 - Resumable downloads (breakpoint resume)
       9 - Progress bar display
      10 - Graceful exit on Ctrl-C
     … +33 lines (ctrl+o to expand)                                                                                               

● Bash(ls -la && find . -type f -name "*.md" -o -name "go.mod" | head -10)
  ⎿  total 44
     drwxr-xr-x 7 root root 4096 Jan 27 09:34 .
     drwxr-xr-x 3 root root 4096 Jan 27 09:10 ..
     … +14 lines (ctrl+o to expand)                                                                                               

● Bash(bd close beads-demo-dee)
  ⎿  ✓ Closed beads-demo-dee: Closed                                                                                              

如果中途退出再继续会话，可以告诉Claude Code基于bd中的任务继续进行实现即可：

❯ 使用bd获取未完成的任务，继续完成                                                                                                

● 我来使用 bd 获取未完成的任务。                                                                                                  

● Bash(bd ready)
  ⎿  Ready work (2 issues with no blockers):                                                                                   

     1. [● P2] [feature] beads-demo-8pf: 进度显示实现
     2. [● P2] [feature] beads-demo-fhv: 断点续传实现                                                                             

● 有2个未完成的任务。让我查看详细信息：                                                                                           

● Bash(bd show beads-demo-8pf)
  ⎿  ○ beads-demo-8pf · 进度显示实现   [● P2 · OPEN]
     Owner: Tony Bai · Type: feature
     Created: 2026-01-27 · Updated: 2026-01-27
     … +11 lines (ctrl+o to expand)                                                                                               

● Bash(bd show beads-demo-fhv)
  ⎿  Running…

这就是 Beads 的魔力：它将 AI 的短期记忆（Context Window）转化为项目的长期记忆（Git Database），让 AI 能够像人类一样，跨越时间，有条不紊地推进复杂工程。

小结与展望

Beads 不仅仅是一个工具，它代表了一种“任务即代码” (Tasks as Code) 的新范式。

在 Gas Town 的宏大构想中，未来的软件开发将是由无数个 AI Agent 协作完成的。而 Beads，正是连接这些 Agent 的神经网络。它让任务的状态、依赖和历史，像代码一样被版本控制、被分发、被协同。

对于正在构建 AI Coding Agent 的开发者来说，集成 Beads 或许是让你的 Agent 拥有”长期记忆”和”战略规划能力”的最短路径。

项目地址：github.com/steveyegge/beads

附录

为了便于开发者查看当前beads中的issue状态，社区开源了多款图形化的Beads viewer工具，包括网页版的beads-ui、终端TUI版的beads_viewer等。

这里以TUI版的beads_viewer为例，简单看看这些viewer的用法。

安装beads_viewer：

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/beads_viewer/main/install.sh?$(date +%s)" | bash
==> Installing bv...
==> Detected platform: linux_amd64
==> Checking for pre-built binary...
==> Latest release: v0.13.0
==> Selected asset: bv_0.13.0_linux_amd64.tar.gz
==> Downloading https://github.com/Dicklesworthstone/beads_viewer/releases/download/v0.13.0/bv_0.13.0_linux_amd64.tar.gz...
==> Extracting...
==> Installed bv v0.13.0 to /root/.local/bin/bv
==> Run 'bv' in any beads project to view issues.

Tip: You can also install via Homebrew:
  brew install dicklesworthstone/tap/bv

使用beads_viewer查看beads中的issue列表和状态：

进入beads-demo目录，执行bv命令即可，你将看到类似下面的输出：

从图中，我们可以看到issue列表、优先级、状态，以及处于选择状态下的issue详情（包括依赖图）。

---

你的 Agent 记忆法

Beads 用 Git 解决了 Agent 的“长期记忆”问题。你在使用 AI 编程时，是如何管理任务上下文的？是靠手动复制粘贴，还是有什么独门秘籍？你
觉得“任务即代码”这种理念会成为未来的主流吗？

欢迎在评论区分享你的工作流或对 Beads 的看法！让我们一起探索 AI 协作的最佳实践。

如果这篇文章为你打开了 AI 任务管理的新视界，别忘了点个【赞】和【在看】，并转发给你的极客朋友，邀请他们一起体验 Beads！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

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

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

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

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

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

---

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

© 2026, bigwhite. 版权所有.