本文永久链接 – https://tonybai.com/2025/10/17/detect-charset-in-go

大家好，我是Tony Bai。

在上一篇关于 Go 语言 string 与 rune 设计哲学的文章发布后，我收到了许多精彩的反馈。其中，一位读者提出了一个极具现实意义的后续问题：“既然 Go 的世界以 UTF-8 为中心，那么当我们从外部系统（如老旧的文件、非标准的 API）接收到一段未知编码的字节流时，我们该如何是好？Go 生态是否有成熟的字符集检测工具/库？”

这个问题，将我们从 Go 语言舒适、有序的“理想国”，直接拉回了那个充满了历史遗留问题、编码标准五花八门的“现实世界”。

字符集检测，本质上是一种“隐式”的、带有猜测成分的“黑魔法”。本文将和大家一起探讨这门“黑魔法”背后的原理，审视 Go 生态中现有的解决方案，并最终回答那个核心问题：在 Go 中，我们应该如何优雅地处理未知编码的文本。

在我们深入探讨具体的 Go 库及其实现之前，建立一个正确的预期至关重要。我们必须首先理解这门“黑魔法”的本质，明白为何字符集检测是一项与编码转换截然不同、且充满不确定性的任务。

字符集检测——一门“不精确”的科学

在我们深入探讨具体的 Go 库及其实现之前，我们必须建立一个核心认知：字符集检测与编码转换截然不同，其本质上不是一个确定性的过程，而是一个基于启发式算法和统计学的概率性猜测。

它就像一位语言学家，仅凭一小段文字（字节序列），就要猜出这段文字是用哪国语言（编码）写成的。

• 如果文本足够长且特征明显，他可能会充满信心地说：“这看起来 99% 是日语 Shift-JIS。”
• 如果文本很短，或者内容模棱两可，他可能只能给出一个模糊的答案：“这可能是 latin-1，也可能是 windows-1252。”
• 在最坏的情况下，他甚至可能完全猜错。

因此，任何字符集检测工具，其返回的结果都应该被理解为一个带有置信度 (Confidence Score) 的“最佳猜测”，而非一个 100% 准确的真理。

既然我们已经认识到字符集检测是一门“不精确”的科学，那么我们的探索自然会引向一个问题：在整个软件行业中，谁是解决这个难题的权威？我们继续往下探索。

行业黄金标准——ICU 是什么？

在字符集检测乃至整个国际化（i18n）领域，ICU (International Components for Unicode) 是绕不开的“黄金标准”。

• 它是什么？ ICU 是一套由 Unicode 联盟维护的、极其成熟和全面的 C/C++ 和 Java 库。它为应用程序提供了强大的 Unicode 和全球化支持，是无数大型软件（从操作系统到浏览器）背后处理文本的“隐形英雄”。
• 它能做什么？ ICU 的能力远不止字符集检测，它是一个庞大的工具集，为处理全球化文本提供了“全家桶”式的解决方案，包括：
  • 文本比较 (Collation)：提供符合特定语言文化习惯的字符串排序规则。
    • 示例：在德语中，”Österreich”（奥地利）应该排在 “Zürich”（苏黎世）之前，即使 Ö 在 Unicode 码点上可能大于 Z。在瑞典语中，å, ä, ö 被视为独立的字母，排在 z 之后。ICU 的 Collation 服务能正确处理这些复杂的排序逻辑。
  • 格式化 (Formatting)：精确地格式化和解析日期、时间、数字、货币，并能处理不同地域的表示习惯。
    • 示例：数字 12345.67 在美国被格式化为 “12,345.67″，但在德国则会是 “12.345,67″。同样，日期 2025年9月26日 在美国可能是 “September 26, 2025″，在法国则是 “26 septembre 2025″。ICU 能根据指定的地域 (Locale) 自动进行正确的格式化。
  • 文本转换 (Transformation)：支持大小写转换、全半角转换、音译等。
    • 示例：将土耳其语中的 i 转换为大写，正确的结果应该是带点的 İ，而不是 I。ICU 知道这个特殊的转换规则。它还可以将俄语中的西里尔字母 “Москва” 音译为拉丁字母 “Moskva”。
  • 文本边界 (Text Boundaries)：能根据不同语言的规则，准确的识别出字符边界、字边界、换行边界以及句子边界。
• 它的重要性？ ICU 是处理国际化文本领域权威且全面的解决方案。它的算法和数据经过了数十年的积累和验证，是业界公认的“事实标准”。

了解了 ICU 在行业中的泰斗地位后，我们自然会好奇其强大能力的来源。现在，就让我们揭开这层神秘的面纱，深入探究其字符集检测算法，究竟是如何在一堆无序的字节中，扮演“文本侦探”的角色的。

ICU 的检测算法——“指纹”与“统计”的侦探艺术

ICU 的字符集检测算法是业界公认最强大的之一，其“侦探工作”主要分为两大策略，分别应对不同类型的编码。

策略一：多字节编码的“指纹匹配”

对于像 UTF-8, GBK, Shift-JIS 这样的多字节编码，它们的字节序列都具有明确的“语法规则”或“指纹”。检测器为每种多字节编码都实现了一个状态机解码器。

多字节编码字符集的检测流程如下图(参考saintfish/chardet的实现整理)：

核心流程说明：

1. 逐字符解码：解码器尝试从字节流中一次解码一个字符。例如，一个 Shift-JIS 解码器知道，如果遇到一个 0×81-0x9F 或 0xE0-0xFC 范围内的字节，那么它后面必须跟一个 0×40-0xFE 范围的字节，两者才能组成一个合法的双字节字符。
2. 统计与评分：在解码过程中，算法会统计几个关键指标：
   • 双字节字符数 (doubleByteCharCount)
   • 错误字节数 (badCharCount)
   • 常用字符命中数 (commonCharCount)：每个编码器都内置了一张包含 50-100 个高频字符的“指纹”列表。解码出的每个字符都会在这张表里进行快速二分查找。
3. 计算置信度：
   • 提前退出：如果错误率过高（例如，badCharCount * 5 >= doubleByteCharCount），则该编码器会立即放弃，返回置信度 0。
   • 综合评分：如果没有提前退出，则会根据上述指标进行综合评分。匹配到的常用字符越多，置信度越高。为了防止长文本导致过度自信，算法还采用了对数缩放来计算最终得分。

这种基于“语法规则”和“高频词指纹”的匹配方式，使得多字节编码的识别相对精确。

策略二：单字节编码的“统计学分析”

对于像 latin-1 或 windows-1252 这样的单字节编码，几乎任何字节序列都是“合法”的，“指纹匹配”策略在此失效。此时，检测器会切换到统计学分析模式。下面是单字节编码字符集的检测流程示意图：

核心流程说明：

1. 字符规范化：首先，通过一个预定义的 charMap 表，将输入的字节流进行规范化处理，例如将大写字母转为小写，将重音符号转为基础字母，将多种标点符号统一视为空格。
2. N-gram 频率分析：算法在一个 3 字节的滑动窗口（即 trigram）中分析文本。每个语言的识别器都内置了一张包含 64 个最常见 trigram 的频率表（例如，英语的频率表会包含 a , an, be 等序列）。
3. 计算命中率与置信度：通过二分查找，计算输入文本中的 trigram 在预定义频率表中出现的次数（ngramHit）。
   • 高置信度：如果命中率超过一个阈值（如 33%），则认为匹配度很高，直接给出一个接近满分（如 98）的置信度。
   • 按比例评分：如果命中率较低，则按比例将其缩放到 0-100 的范围内。

通过检测器会并发地运行所有这些识别器，最终将结果按置信度从高到低排序，返回最佳的猜测。

CGO 方案的启示——uber-go/icu4go 的能力与局限

在了解了 ICU 的字符集检测算法后，我们终于可以进入实践环节。将 ICU 的强大能力引入 Go 生态，最直接的路径是什么？答案似乎是构建一座通往其原生 C 库（ICU4C）的桥梁。

Go 社区曾有过这样的尝试，其中最著名的就是 Uber 开源的 uber-go/icu4go。这是一个通过 CGO，为 ICU4C 提供 Go 语言封装的库。然而，当我们深入探究这个库时，却发现了一个意想不到的事实。

尽管底层的 ICU4C 库确实拥有强大的字符集检测功能（定义于 ucsdet.h），但 uber-go/icu4go 这个 Go 封装并没有暴露这部分 API。它主要专注于 ICU 的另一部分核心能力：

• 本地化 (Locale)：处理不同地域的语言和文化习惯。
• 格式化 (Formatting)：提供对数字、货币、日期和时间的精确本地化格式化。

这意味着，即使我们愿意承担引入 CGO 的所有代价，uber-go/icu4go 也无法直接解决我们的字符集检测问题。

注：uber-go/icu4go 如今已stable且被归档 (Archived)。

不过，对于追求简洁的 Go 社区来说，为了一个功能而引入额外沉重的 C 依赖，往往被认为是得不偿失的。这次对 CGO 方案的探索虽然未能直接解决我们的问题，但它清晰地指明了方向：要寻找一个真正符合 Go 语言哲学的解决方案，我们必须将目光投向“纯 Go 之路”。

纯 Go 方案——saintfish/chardet 的移植与局限

用纯 Go 来实现字符集检测是否可行？答案是肯定的。saintfish/chardet 就是这样一个库，它是 ICU 字符集检测算法的一个纯 Go 语言移植版本。

下面是使用chardet对utf-8、GB-18030和eu-jp字符集进行检测的示例：

// https://go.dev/play/p/pxjc_XxDF8v
package main

import (
    "fmt"

    "github.com/saintfish/chardet"
)

func main() {
    // 示例: 检测字节数组的字符集
    detectFromBytes()
}

// detectFromBytes 检测字节数组的字符集
func detectFromBytes() {
    // 不同编码的示例文本
    texts := map[string][]byte{
        "UTF-8 中文": []byte("这是一段UTF-8编码的中文文本"),
        "GB18030 中文": []byte{
            // "Go是Google开发的一种静态强类型、编译型语言"的GB18030编码
            71, 111, 202, 199, 71, 111, 111, 103, 108, 101, 233, 95, 176, 108, 181, 196, 210, 187, 214, 214, 190, 142, 215, 103, 208, 205, 163, 172, 129, 75, 176, 108, 208, 205, 163, 172, 178, 162, 190, 223, 211, 208, 192, 172, 187, 248, 187, 216, 202, 213, 185, 166, 196, 220, 181, 196, 177, 224, 179, 204, 211, 239, 209, 212,
        },
        "日文 EUC-JP": []byte{
            // "こんにちは世界" 的EUC-JP编码示例
            164, 179, 164, 243, 164, 203, 164, 193, 164, 207, 192, 164, 179, 166,
        },
    }

    // 创建文本检测器
    detector := chardet.NewTextDetector()

    for name, data := range texts {
        fmt.Printf("\n=== 检测: %s ===\n", name)

        // 方法1: 获取最佳匹配
        result, err := detector.DetectBest(data)
        if err != nil {
            fmt.Printf("检测失败: %v\n", err)
            continue
        }
        fmt.Printf("最佳匹配:\n")
        fmt.Printf("  字符集: %s\n", result.Charset)
        fmt.Printf("  语言: %s\n", result.Language)
        fmt.Printf("  置信度: %d%%\n", result.Confidence)

        // 方法2: 获取所有可能的匹配
        results, err := detector.DetectAll(data)
        if err != nil {
            fmt.Printf("检测所有匹配失败: %v\n", err)
            continue
        }
        fmt.Printf("\n所有可能的匹配:\n")
        for i, r := range results {
            fmt.Printf("  %d. %s (语言: %s, 置信度: %d%%)\n",
                i+1, r.Charset, r.Language, r.Confidence)
        }
    }
}

这个示例的输出如下:

$go run main.go

=== 检测: 日文 EUC-JP ===
最佳匹配:
  字符集: GB-18030
  语言: zh
  置信度: 10%

所有可能的匹配:
  1. Shift_JIS (语言: ja, 置信度: 10%)
  2. GB-18030 (语言: zh, 置信度: 10%)
  3. EUC-JP (语言: ja, 置信度: 10%)
  4. EUC-KR (语言: ko, 置信度: 10%)
  5. Big5 (语言: zh, 置信度: 10%)

=== 检测: UTF-8 中文 ===
最佳匹配:
  字符集: UTF-8
  语言:
  置信度: 100%

所有可能的匹配:
  1. UTF-8 (语言: , 置信度: 100%)
  2. windows-1253 (语言: el, 置信度: 20%)
  3. Big5 (语言: zh, 置信度: 10%)
  4. Shift_JIS (语言: ja, 置信度: 10%)
  5. GB-18030 (语言: zh, 置信度: 10%)

=== 检测: GB18030 中文 ===
最佳匹配:
  字符集: GB-18030
  语言: zh
  置信度: 100%

所有可能的匹配:
  1. GB-18030 (语言: zh, 置信度: 100%)
  2. Big5 (语言: zh, 置信度: 10%)
  3. Shift_JIS (语言: ja, 置信度: 10%)
  4. windows-1252 (语言: fr, 置信度: 5%)

这个结果生动地印证了我们在本文开头的论断：字符集检测是一门“不精确”的科学。对于短小的日文 EUC-JP 文本(14个字节)，chardet 发生了误判(将之识别为GB-18030)，给出了一个置信度仅为 10% 的错误答案。

根据之前我们对检测算法的了解，这次日文检测失败的主要原因很可能是数据量太少。我们提供给检测器的日文 EUC-JP 数据只有 14 字节，这对于字符集检测来说太短了，导致所有候选编码的置信度都只有 10%。下面我们提供更多日文字符，看看检测器是否能做出正确的检测！

这次我们提供的日文字符如下：

"日文 EUC-JP": []byte{
            // "Go言語はGoogleが開発したプログラミング言語です。並行処理が得意で、コンパイル速度も速いです。日本語のテストです。"
            71, 111, 184, 192, 184, 236, 164, 207, 71, 111, 111, 103, 108, 101, 164, 172, 179, 171, 200, 175, 164, 183, 164,
            191, 165, 215, 165, 237, 165, 176, 165, 233, 165, 223, 165, 243, 165, 176, 184, 192, 184, 236, 164, 199, 164, 185,
            161, 163, 202, 195, 185, 212, 189, 232, 164, 234, 164, 172, 196, 192, 176, 213, 164, 199, 161, 162, 165, 179, 165,
            243, 165, 209, 165, 164, 165, 235, 194, 174, 197, 249, 164, 226, 194, 174, 164, 164, 164, 199, 164, 185, 161, 163,
            198, 252, 203, 220, 184, 236, 164, 206, 165, 198, 165, 185, 165, 200, 164, 199, 164, 185, 161, 163,
        },

然后再运行一次检测器，这次得到的结果如下：

// 忽略其他
=== 检测: 日文 EUC-JP ===
最佳匹配:
  字符集: EUC-JP
  语言: ja
  置信度: 100%

所有可能的匹配:
  1. EUC-JP (语言: ja, 置信度: 100%)
  2. GB-18030 (语言: zh, 置信度: 59%)
  3. Big5 (语言: zh, 置信度: 48%)
  4. ISO-8859-1 (语言: fr, 置信度: 11%)
  5. ISO-8859-6 (语言: ar, 置信度: 10%)
  6. Shift_JIS (语言: ja, 置信度: 10%)
  7. EUC-KR (语言: ko, 置信度: 10%)
  8. ISO-8859-7 (语言: el, 置信度: 9%)
  9. windows-1256 (语言: ar, 置信度: 8%)
  10. KOI8-R (语言: ru, 置信度: 6%)
  11. ISO-8859-9 (语言: tr, 置信度: 3%)

这回检测器做出了正确的检查！

在日常做字符集检测时，有一个置信度阈值建议：

• >= 80%: 可以较高把握地采纳该结果。
• 50-80%: 结果可疑，建议结合其他业务逻辑进行验证，或提示用户进行人工确认。
• < 50%: 结果几乎不可信，应视为检测失败。

尽管 chardet 能够工作，但它也面临其自身的局限：早已不再积极维护。这意味着它可能缺少对新编码的支持，也可能存在未修复的 Bug。

标准库的边界——golang.org/x/text 能做什么？

看到 icu4go 和 chardet 两个关键库都已不再活跃，一个自然的问题是：我们能否仅依靠 Go 官方的 golang.org/x/text下面的包，自己实现一个字符集检测工具呢？

最初我也想当然的认为这是可行的。但经过调查后，才发现答案：几乎不可能。 x/text/encoding 包的设计目标是转换 (Conversion)，而非检测 (Detection)。

它提供了一套极其强大和高效的工具，用于在已知源编码和目标编码的情况下，进行精确的转换。它就像一个多语言的“翻译官”，但前提是你必须告诉他：“请把这段 GBK 编码的文本，翻译成 UTF-8。”

import (
    "golang.org/x/text/encoding/simplifiedchinese"
    "golang.org/x/text/transform"
    "io"
    "os"
)

func convertGBKtoUTF8(gbkReader io.Reader) io.Reader {
    // gbkReader 是一个读取 GBK 编码文件的 io.Reader
    // utf8Reader 将会是一个在读取时自动转换为 UTF-8 的 io.Reader
    utf8Reader := transform.NewReader(gbkReader, simplifiedchinese.GBK.NewDecoder())
    return utf8Reader
}

由此也可以看出，Go标准库(包括golang.org/x/…)为你提供了最强大、最正确的转换工具，但将“猜测”这个不确定的、充满风险的任务，留给了开发者自己或第三方库去解决。它不提供用于“猜测”的统计模型或状态机。

小结

在梳理完所有线索后，我们终于可以为“Go 开发者如何处理未知编码”这个问题，给出一份清晰的实践指南：

1. 最高法则：尽可能避免检测。在设计系统时，应始终将显式声明编码作为第一原则。例如：

   • HTTP API：强制要求客户端在 Content-Type 头中明确指定 charset。
   • 文件上传：在 UI 中提供一个下拉菜单，让用户（如果可能）指定其上传文件的编码。
   • 系统间通信：在服务间约定统一使用 UTF-8。

2. 务实的选择：当必须检测时。如果你的业务场景（如处理用户上传的各种历史遗留文件）让你别无选择，那么：

   • saintfish/chardet 是目前最符合 Go 语言习惯（纯 Go、无 CGO）的起点。尽管它已不再活跃，但其代码和原理依然是构建自定义解决方案的最佳参考。
   • 在使用任何检测库时，必须对返回的置信度进行判断，并为低置信度的结果设计 fallback 逻辑。
   • 可以考虑自己维护一个 chardet 的 fork，或者参考其原理，针对你的特定业务场景（例如，只在几种有限的编码中进行猜测）实现一个更轻量级的检测器。

3. 最后的手段：CGO 的重量级武器。如果你的应用场景对检测的准确率要求极高，且你愿意承担 CGO 带来的所有复杂性，那么封装 ICU4C 依然是一条可行的、但充满挑战的道路。

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/10/16/rethink-996-culture

大家好，我是Tony Bai。

“996”——早上九点到晚上九点，一周工作六天。这个术语早已成为国内科技行业高强度工作文化的代名词。其背后的逻辑似乎坚不可摧：如果你无法用才华取胜，那就用时间取胜。努力工作，加倍努力，似乎成为了通往成功的唯一路径。随着AI赛道竞争的白热化，996文化开始“传染”给美国西部的高科技行业，这种现象也引起了欧美开发者的关注。

近日一篇名为《996 只是意味着你没有杠杆》的文章，对这一“努力神话”提出了一个颠覆性的批判。作者 J.A. Westenberg 在文中提出了一个尖锐的理论：当一家公司或个人将 996 作为其核心战略时，他们实际上已经输了。他们炫耀的不是自己的力量，而是自己的弱点。

这篇文章既是是对工作文化的批判，也是一堂关于战略、价值和杠杆思维的深刻一课，值得每一位技术从业者深思。

996 的本质：没有帆，只能拼命划船

Westenberg 的核心观点可以用一个生动的比喻来概括：

“The grind-maxxed founder is trying to row the boat harder. The leverage-maxxed founder has a sail.”
（拼命“卷”的创始人，正试图更用力地划船。而善用杠杆的创始人，早已扬起了帆。）

他认为，996 文化盛行的根本原因，往往不是因为团队充满激情，而是因为他们的想法不够好，不足以在每天八小时内取得成功。

• 没有 PMF (产品市场契合) 的蛮力冲锋： 当一家公司还没有找到真正被市场需要的产品时，剩下的唯一选择似乎就是“动量表演”——通过让团队长时间工作来制造一种增长的假象。Westenberg 观察到，这种试图用蛮力冲破迷雾的方式，往往在找到突破口之前，就已将团队燃烧殆尽。
• 用努力掩盖洞察的缺失： 过度沉迷于工作，会给人一种虚假的正义感和安慰感，让人误以为成功只是时间的函数，而非品味、判断力或时机的产物。作者直言：“没有洞察力的痴迷，只是一种病态。”

当一家公司最好的名片是“我们所有人都在拼命工作”时，在 Westenberg 看来，它其实什么都没说。

努力不是价值，“孔雀开屏”式的表演

为什么在没有独特优势（如顶尖人才、强大网络或创新想法）时，人们会倾向于崇拜“埋头苦干”？作者认为，这是一种“身份焦虑”的副作用。

你需要向世界证明你是认真的、投入的。还有什么比所有人都下班回家后，你依然在办公室奋战，并拍照发推更好的方式呢？Westenberg 将这种行为称为“孔雀开屏 (peacocking)”式的表演，目的是展示“看我有多努力”。

然而，这种表演混淆了两个根本不同的概念：

• 努力 ≠ 价值 (Effort is not value)
• 工时 ≠ 产出 (Hours are not outcomes)
• 工作 ≠ 进展 (Work is not the same as progress)

Westenberg 指出，如果你的唯一优势就是“努力”，那么你是可以被轻易替代的。因为总有比你更年轻、更饥渴、更绝望的人，愿意投入更长的时间。疲惫本身，构不成任何长期的护城河。

真正的优势：在不同的轴线上竞争

作者观察到，那些他真正钦佩的人，他们拥有的“不公平优势”往往与时间无关。

• 有些人极擅长销售。
• 有些人是天才的设计师。
• 有些人是简化复杂系统的大师。

关键在于，他们在完全不同的轴线上竞争。他们不需要用 996 的方式工作，因为他们在四小时内创造的价值，可能比大多数人十二小时创造的还要多。

你很少听到真正伟大的创始人吹嘘“我只是比所有人都更努力工作”。你听到的是：

• “我们找到了人们想要的东西，然后我们把它做了出来。”
• “我们知道一个秘密。”
• “我们有不同的思考方式。”

在 Westenberg 看来，他们的成功，源于找到了独特的杠杆。

寻找你的帆：超越时间的竞争

“努力”是线性且有上限的，而“杠杆”则是非线性且能带来指数级回报的。作者认为，最有价值的公司，正是由那些找到了杠杆的人建立的。

• 智力杠杆 (Intellectual Leverage): 你是否拥有别人不知道的“秘密”？一个独特的洞察，一个创新的算法，一个更优越的架构。
• 产品杠杆 (Product Leverage): 你的产品是否足够好，以至于它能“自我行走”？一个精心设计的产品，会在你睡觉时被用户自发分享。一个有用的工具，会为世界创造比其开发者投入的多得多的价值。
• 分销杠杆 (Distribution Leverage): 你是否建立了别人难以企及的渠道或网络？

花再多的时间划船，也无法拯救一个航向错误的游戏。

小结：别再建造一台“跑步机”

996 的神话，美化了“受苦”，并将其与“成功”错误地绑定。但 Westenberg 揭示的真相或许有些残酷：最有价值的工作，往往不是最辛苦的工作。

文章最后，作者给出了一个尖锐的拷问：

“The next time someone brags about 996, ask them what they’re building. Ask them what they know that others don’t. Ask them what would keep working if they stopped. Because if the answer is “nothing,” then they haven’t built a company. They’ve just built a fucking treadmill.”
（下次有人吹嘘 996 时，问问他们在做什么。问问他们知道哪些别人不知道的事情。问问他们，如果他们停下来，还有什么能继续运作。因为如果答案是“什么都没有”，那么他们并没有建立一家公司，他们只是造了一台他妈的跑步机。）

Westenberg 的文章提醒我们，作为技术从业者，我们的目标不应该是成为跑步机上跑得最久的人，而应该是那个找到更好的交通工具，甚至学会飞行的人。我们的价值，最终体现在我们创造的杠杆上，而非消耗的时间里。是时候停止奋力划桨，开始抬头寻找风向了。

资料链接：https://www.joanwestenberg.com/p/996-just-means-you-have-no-leverage

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

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

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

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

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

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