本文永久链接 – https://tonybai.com/2026/01/13/how-markdown-took-over-the-world

大家好，我是Tony Bai。

在这个由科技巨头主导、充斥着复杂算法和封闭生态的数字世界里，有一种技术显得格格不入。它没有专利壁垒，没有复杂的构建流程，甚至不需要特定的软件就能阅读。

它是 Markdown。

近期，知名科技博主 Anil Dash 发布了一篇题为《How Markdown Took Over the World》的长文。他在文中深情回顾了这一格式的诞生与崛起，并指出：在这个由科技巨头主导、充斥着封闭生态的数字世界里，Markdown 是一场属于普通人的胜利。

如今，从 GitHub 上的亿万代码仓库，到 ChatGPT等大模型 生成的每一个回答，再到你随手记下的 Apple Notes，Markdown 无处不在。它不仅成为了技术人员的“普通话”，更意外地成为了 AI 时代的“通用语”。

这一切，都始于 20 年前一位“固执”的苹果博主为了偷懒而写的一个小脚本。今天，让我们跟随 Anil Dash 的视角，回顾这段充满偶然与必然的技术传奇。

缘起：一个博主的“偷懒”计划

2002 年，John Gruber 做了一个在当时看来极其不理性的决定：全职运营一个只关注苹果公司动态的博客——Daring Fireball。

在那个博客刚刚兴起的蛮荒时代，发布内容并不容易。你要么忍受简陋的输入框，要么得手写复杂的 HTML 标签。为了能在写文章时（比如加粗、插入链接）不被繁琐的 HTML 标记打断思路，John 决定为自己开发一套工具。

他的核心理念是：既然 HTML (HyperText Markup Language) 太复杂，那就叫它 Markdown 吧。

如果你想加粗，就用 **；想引用，就用 >；想列表，就用 -。这些符号并非凭空创造，而是深受电子邮件时代纯文本格式习惯的影响。John 的天才之处在于，他将这些约定俗成的习惯标准化，并写了一个 Perl 脚本将它们转换为合法的 HTML。

2004 年 3 月，在 Aaron Swartz（那位早逝的天才少年）的协助测试下，Markdown 正式发布。没有人预料到，这个小小的工具将改变互联网的未来。

统治世界：从程序员到 AI

Markdown 的崛起并非一夜之间，但它的生命力却异常顽强。

1. 开发者的拥抱：GitHub 的出现是关键转折点。它将 README.md 设为项目标配，使得 Markdown 成为了开发者描述项目的标准格式。
2. 应用的普及：从 Slack 到 Discord，从 Notion 到 Obsidian，现代生产力工具几乎全部内置了 Markdown 支持。哪怕是 Google Docs 和 Apple Notes 这样的大众软件，最终也向用户需求妥协，加入了 Markdown 支持。
3. AI 的通用语：最令人意想不到的转折发生在当下。当最前沿的 LLM（大型语言模型）需要一种格式来输出结构化内容时，它们不约而同地选择了 Markdown。因为它既对人类可读，又对机器友好，且完全开放。

Anil Dash 在他的回顾文章中总结了 Markdown 成功的 10 个技术原因，其中几点尤为深刻：

• 解决真实问题：它不是为了“发明一种新格式”，而是为了解决“手写 HTML 太痛苦”这个具体痛点。
• 利用现有习惯：它没有强迫用户学习新符号，而是沿用了电子邮件时代的纯文本习惯（如 > 表示引用）。
• 没有知识产权 (IP) 负担：John Gruber 从未试图将其商业化或申请专利，这种彻底的开放性消除了所有采用者的顾虑。
• “查看源码”的哲学：Markdown 文件本身就是教程。你只需要看一眼源文件，就能立刻学会怎么写。

硬币的另一面：自由的代价

当然，Markdown 这种彻底的自由和缺乏中央控制，也带来了一个长期的副作用——碎片化。

正因为 John Gruber 当年只给出了一个 Perl 脚本而没有定义极其严谨的规范，导致后来出现了各种“方言”。GitHub 有自己的 GitHub Flavored Markdown (GFM)，Reddit 有自己的解析规则，Obsidian 和 Notion 也都添加了各自的私有语法（如双向链接 [[Link]]）。

这导致了一个尴尬的现实：虽然 Markdown 到处都是，但你的 Markdown 文件未必能在所有地方都完美渲染。 表格的语法支持不一，数学公式的写法各异，甚至连换行符的处理都有微妙差别。

直到后来 CommonMark 等项目的出现，才试图事后诸葛亮式地去修补这种分裂。

但幸运的是，Markdown 的核心语法（标题、列表、粗体、引用、链接）已经足够稳固，成为了事实上的标准。正是这最基础的 80% 功能，支撑起了它在 AI 时代的通用性。对于大语言模型而言，这些细微的方言差异完全可以忽略不计——它只需要用最基础的语法，就能让全世界读懂。

这也再次印证了那个道理：在规模化面前，简单且“足够好”的方案，往往能战胜完美但复杂的方案。

启示：善良与开放的力量

Markdown 的故事，是对当代科技行业的一种温柔提醒。

真正的互联网基础设施，往往不是由拿了巨额风投的初创公司在董事会里规划出来的。它们往往源于像 John Gruber 或 Aaron Swartz 这样的人——他们有正职工作，但也充满热情；他们为了解决自己的问题而造轮子，然后慷慨地将其分享给世界。

在这个被“护城河”、“生态闭环”和“商业化变现”充斥的时代，Markdown 证明了：一个好的点子，加上一颗慷慨的心，依然可以改变世界。

下次当你用 ** 加粗文字，或者看着 ChatGPT 逐行吐出格式完美的回答时，请记得：这背后没有复杂的商业算计，只有一位在费城看球赛的博主，想让你打字时能稍微轻松一点。

资料链接：https://www.anildash.com/2026/01/09/how-markdown-took-over-the-world/

你的 Markdown 记忆

Markdown 已经陪伴了我们 20 年。你还记得自己第一次接触 Markdown 是在什么场景下吗？是写 GitHub README，还是做笔记？你最喜欢的 Markdown 编辑器又是哪一款？

欢迎在评论区分享你的 Markdown 故事和神器推荐！ 让我们一起致敬这个简单而伟大的工具。

如果这篇文章让你对 Markdown 有了全新的认识，别忘了点个【赞】和【在看】，并转发给你的朋友，哪怕他只是个爱记笔记的非程序员！

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2026/01/02/go-supply-chain-attack-source-code-to-capability-auditing-paradigm-shift

大家好，我是Tony Bai。

在软件供应链安全的传统认知中，我们默认遵循一个假设：“代码即真理”。如果你审查了 GitHub 上的源码，确认它是安全的，那么你部署的服务就应该是安全的。

然而，2025 年初在 Go 生态中爆发的 BoltDB 投毒事件，以及之前的 XZ 后门事件，无情地粉碎了这个假设。攻击者正在利用构建系统的复杂性和 Git 标签的可变性，在“源码”与“构建产物”之间制造出一片致命的盲区。

面对这种不对称的战争，传统的“源码审计”已显疲态。在 GopherCon 2025 上，Google Cloud 安全专家 Jess McClintock 提出了一个新观点：我们需要一场防御范式的转移——从关注代码“写了什么”，转向关注构建产物“能做什么”。

本文将带你深入这场范式转移的核心，剖析攻击手段的演变，并手把手教你使用 Google 开源的 Capslock 工具，开启你的“能力审计”之路。

旧范式的崩塌——当“所见”不再“所得”

“源码审计”失效的根本原因，在于源码仓库不再是单一的事实来源 (Source of Truth)。

以 BoltDB 投毒案为例，这是一场教科书式的“偷天换日”：

1. 投毒：攻击者发布了一个包含恶意后门的版本，打上 v1.3.1 的 git 标签。
2. 缓存：Go Module Proxy（Go 生态的官方镜像）忠实地抓取并缓存了这个恶意版本。
3. 清洗：攻击者随即在 GitHub 上强制推送 (force-push) 了一个同名的 v1.3.1 标签，指向一个干净的提交。

结果是分裂的：

• 审计者在 GitHub 上看到的是“良民”。
• 编译器从 Proxy 拉取的是“恶棍”。

这标志着旧范式的崩塌：你审查的代码，并不是你运行的代码。

供应链攻击的进化——隐藏在构建链中的幽灵

Jess 指出，这种攻击并非孤例，而是一种正在蔓延的行业趋势。

• XZ 后门：恶意载荷被伪装成测试文件，只有在特定的构建脚本执行时才会被注入。在源码树中，它是静止的、无害的；但在构建过程中，它“活”了过来。
• npm EventStream：利用版本号策略，让恶意代码只存在于次要版本中，避开对主要版本的审查。

这些案例共同指向一个结论：安全性不能只靠静态的源码分析，必须向右移动，覆盖到最终的构建产物 (Build Artifact)。

新范式确立——能力审计 (Capability Audit)

既然我们无法逐行审查庞大的依赖树，也无法完全信任源码，那么出路在哪里？

答案是：关注行为边界。这就是“能力审计”的核心思想。

借鉴移动端 App 的权限管理模型，我们不再纠结于依赖包内部怎么实现，而是关注它申请了什么能力。

• 一个 JSON 解析库，如果申请了 net.Dial (网络访问) 能力，这就是异常。
• 一个日志库，如果申请了 os.Exec (命令执行) 能力，这就是红色警报。

通过监控依赖包的“能力列表”及其变化，我们可以以极低的成本，通过行为特征识别出潜在的供应链攻击，无论源码如何伪装。

Capslock——Google 的开源防御武器

为了将“能力审计”落地，Google 开源了 Capslock。它是一个针对 Go 语言的静态分析工具，通过解析构建产物，构建完整的函数调用图，从而透视出代码的真实能力。

Capslock 能做什么？

Capslock 的核心价值在于“透视”。它不关心代码的具体逻辑，而是关注代码触及了哪些系统边界。它能识别出以下几类关键能力：

• 网络访问 (NETWORK)：连接互联网或绑定端口。
• 文件系统 (FILES)：读写文件。
• 系统执行 (EXEC)：启动子进程。
• 底层操作 (UNSAFE, REFLECT, CGO)：使用不安全指针、反射或调用 C 代码。

快速上手：Capslock 实战指南

想体验“能力审计”的威力？只需三步。

1. 安装工具

确保你安装了最新的 Go 环境，然后运行：

$go install github.com/google/capslock/cmd/capslock@latest

2. 扫描当前项目

在你的 Go 项目根目录下运行，Capslock 会自动分析当前模块及其所有依赖，以我的issue2md开源项目为例：

$capslock -packages=.
Capslock is an experimental tool for static analysis of Go packages.
Share feedback and file bugs at https://github.com/google/capslock.
For additional debugging signals, use verbose mode with -output=verbose
To get machine-readable full analysis output, use -output=json

FILES: 1 references
NETWORK: 1 references
REFLECT: 2 references

我们看到该issue2md项目使用了文件访问、网络访问以及反射能力。如果你要看具体是哪些代码用到了这些能力，可以让capslock输出verbose信息：

$capslock -packages=. -output=v
Capslock is an experimental tool for static analysis of Go packages.
Share feedback and file bugs at https://github.com/google/capslock.
To get machine-readable full analysis output, use -output=json

FILES: 1 references (1 direct, 0 transitive)
Example callpath:
  github.com/bigwhite/issue2md.main
  main.go:29:11:log.Fatal
  log.go:423:12:(*log.Logger).output
  log.go:244:23:(*os.File).Write

NETWORK: 1 references (1 direct, 0 transitive)
Example callpath:
  github.com/bigwhite/issue2md.main
  main.go:24:23:net/http.FileServer

REFLECT: 2 references (1 direct, 1 transitive)
Example callpath:
  github.com/bigwhite/issue2md.main
  main.go:18:12:flag.Parse
  flag.go:1188:19:(*flag.FlagSet).Parse
  flag.go:1157:26:(*flag.FlagSet).parseOne
  flag.go:1112:11:(*flag.FlagSet).usage
  flag.go:1068:17:(*flag.FlagSet).defaultUsage
  flag.go:690:17:(*flag.FlagSet).PrintDefaults
  flag.go:609:12:(*flag.FlagSet).VisitAll
  flag.go:458:5:(*flag.FlagSet).PrintDefaults$1
  flag.go:630:32:flag.isZeroValue
  flag.go:545:18:reflect.New

3. 进阶：对比版本差异 (Diff)

这是 Capslock 最核心、也最强大的用法之一。当你想升级某个依赖时，如何知道新版本是否引入了恶意行为？下面以我fork的govanityurls为例，看一下如何进行版本能力的差异对比。我的govanityurls的唯一依赖是gopkg.in/yaml.v2。

# 1. 保存依赖的旧版本的分析结果
capslock -packages=gopkg.in/yaml.v2 -output=json > v2.3.0.json

# 2. 比较新版本 (假设你已经 go get了新版本，比如v2.4.0)
$capslock -packages=gopkg.in/yaml.v2 -output=compare ./v2.3.0.json

如果输出显示新增了 NETWORK 或 EXEC 能力，这就是一个必须要人工介入审查的红色警报。在我这个示例中，gopkg.in/yaml.v2 v2.4.0，相对于v2.3.0没有能力增加。

知己知彼：Capslock 的局限性

作为一个静态分析工具，Capslock 并非全知全能。了解它的盲区，对于正确使用它至关重要：

1. CGO 与汇编盲区：Capslock 无法分析 C 代码或汇编代码。如果一个包使用了 CGO，Capslock 会报告它拥有 CGO 能力，但无法告诉你 C 代码内部具体做了什么。这是静态分析的物理边界。
2. 反射与 Unsafe：通过 reflect 或 unsafe 包进行的动态调用，往往让静态分析难以追踪。Capslock 会诚实地报告这些“不可知”的区域为 REFLECT 或 UNSAFE，提示你需要人工审查。
3. 误报 (False Positives)：静态分析假设所有代码路径都可能被执行。如果一段恶意代码藏在一个永远不会为 true 的 if 分支里，Capslock 依然会报告其能力。但在安全领域，“宁可错杀，不可放过” 是正确的策略。

尽管有这些局限，Capslock 依然是目前 Go 生态中进行大规模、自动化能力审计的最佳工具。它为我们在供应链的汪洋大海中，提供了一个至关重要的“雷达”。

构建零信任的开发流程

从“源码审计”到“能力审计”，代表了我们对供应链安全认知的升级。在 AI 辅助编程日益普及、代码生成速度呈指数级增长的今天，这种基于行为边界的守门人机制，将变得愈发重要。

给团队的落地建议：

1. 锁定 Commit：在 go.mod 中尽量使用伪版本号（pseudo-version）锁定 Commit Hash，因为 Tag 是可变的，但 Hash 是不可伪造的。
2. CI 集成：不要只在本地运行 Capslock，把它变成 CI 的一部分。通过将 Capslock 加入到你的 CI 流水线（例如 GitHub Actions、gitlab ci等），你可以设定一条红线：任何新增的高危能力（如网络、执行），必须触发人工审查阻断。
3. 保持怀疑：当一个纯计算类的库突然想要访问网络时，哪怕源码看起来再正常，也要坚决说不。

小结

安全不是一个状态，而是一个过程。当攻击者学会了“偷天换日”，防御者就必须学会“火眼金睛”。Capslock 和能力审计范式，正是 Go 生态在这个新时代交出的答卷。

参考资料

• The Code You Reviewed is Not the Code You Built by Jess McClintock – https://www.youtube.com/watch?v=70ka67DpLPc
• capslock repo – https://github.com/google/capslock
• Go Supply Chain Attack: Malicious Package Exploits Go Module Proxy Caching for Persistence – https://socket.dev/blog/malicious-package-exploits-go-module-proxy-caching-for-persistence

聊聊你的安全焦虑

供应链攻击防不胜防，Capslock 给了我们一个新的视角。在你日常的开发中，是如何管理第三方依赖安全的？是否遇到过类似的“李鬼”包？或者，你对“能力审计”这种新范式有什么看法？

欢迎在评论区分享你的经验或担忧！ 让我们一起筑牢 Go 生态的安全防线。

如果这篇文章让你对供应链安全有了新的认识，别忘了点个【赞】和【在看】，并转发给你的团队，安全无小事！

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

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

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

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

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

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

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

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

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