Obsidian 在短短几年间积累数百万用户、Notion 成为企业标配、GitHub 的 README 几乎全用 Markdown 撰写——这场「纯文字复兴」并非偶然。在 Word、Google Docs 称霸多年之后，为什么越来越多人回头选择看起来「更原始」的纯文字格式？答案藏在格式设计本身的哲学里。
1. 格式战争：.docx vs 纯文字
在 Microsoft Word 普及之前，工程师和学者长期使用纯文字写作。Word 的出现带来了所见即所得（WYSIWYG）的便利，但也带来了几个长期问题：
- 格式锁定：.docx 是封闭的二进制格式，脱离 Word 或 Google Docs 就难以正常打开或编辑
- 格式损坏：版本差异、字体缺失、样式错乱是跨平台分享的常见噩梦
- 版本控制困难：Git 等版本控制工具对二进制格式束手无策，无法有效追踪「谁改了什么」
- 搜索与索引限制：二进制格式让全文搜索更复杂，备份也需要更多空间
纯文字完全不存在这些问题。它是通用格式——任何文字编辑器都能打开，任何操作系统都能搜索，任何版本控制系统都能追踪每一个字符的变化。
2. Markdown：纯文字与格式化之间的完美平衡
纯文字的问题在于：它缺少排版语义。你可以写 # 标题 但阅读时只是一行文字，不会自动显示为视觉上的大标题。
2004 年，John Gruber 和 Aaron Swartz 设计了 Markdown，目标是「让纯文字尽可能接近最终排版的样子」。关键设计决策是：即使不渲染，Markdown 原始码本身也应该是可读的。
# 一级标题 看起来就像标题。**粗体** 看起来就像被强调的文字。- 列表项目 看起来就像列表。这种「视觉一致性」让 Markdown 在纯文字状态下就具有良好的可读性，不需要依赖渲染工具。
3. Markdown 在哪里被使用？
Markdown 的应用范围远比多数人想象的广：
- GitHub / GitLab：所有 README、Issue、Pull Request、Wiki 都支持 Markdown
- 技术文档：Docusaurus、MkDocs、Sphinx 等文档框架以 Markdown 为核心
- 博客平台：Hugo、Jekyll、Hexo 等静态网站生成器使用 Markdown 写文章
- 笔记工具：Obsidian、Logseq、Joplin、Bear 等以 Markdown 存储笔记
- 协作平台：Notion、Confluence、Slack、Discord 都支持 Markdown 语法
- 学术写作：Pandoc 可将 Markdown 转换为 LaTeX、PDF、DOCX，越来越多研究者采用
4. 为什么工程师特别爱用 Markdown？
对工程师来说，Markdown 解决了一个核心问题：文档应该和代码放在一起，接受同样的版本控制。
当项目的说明文档是 Markdown，就可以：
- 用
git diff看出文档的每一次修改，清楚知道谁改了哪一行 - 在 Pull Request 中审查文档变更，就像审查代码一样
- 在 CI/CD 流程中自动验证文档格式或链接有效性
- 让文档随代码一起演进，不出现「文档跟不上代码」的情况
Markdown 之所以适合版本控制，根本原因是纯文字格式让「比对两个版本的差异」变得有意义。Word 文档的差异比对不仅难以阅读，有时甚至需要专用工具才能运作。纯文字的差异比对（diff）是标准化的，任何工具都能处理。
5. Obsidian 为什么爆红？从工具功能看纯文字的优势
Obsidian 于 2020 年推出，两年内积累超过百万用户。它的核心设计决策是：所有笔记都存储为本地 Markdown 文件，而非云端数据库。
这个设计带来了几个关键优势：
| 特性 | 传统云端笔记（Evernote 等） | Obsidian（本地 Markdown） |
|---|---|---|
| 数据所有权 | 数据在厂商服务器 | 数据在自己电脑 |
| 离线使用 | 需要网络同步 | 完全离线运作 |
| 导出灵活性 | 通常需要付费导出 | 直接访问 .md 文件 |
| 搜索速度 | 依赖服务器 | 本地全文搜索，瞬间响应 |
| 厂商锁定 | 高（换工具需大量转换） | 低（任何编辑器都能打开） |
Obsidian 的爆红某种程度上是对「厂商锁定」的反弹——用户意识到，将多年的笔记锁在某个服务的专有格式里，是一种隐性风险。
6. 纯文字的长期性：二十年后还能读吗？
这是许多人从未考虑过的问题：你今天写的笔记，二十年后还能读到吗？
1990 年代的 .doc 文件，现在要用现代 Word 打开往往需要「兼容模式」，格式可能已经走样。而 1990 年代的纯文字文件，今天用任何文字编辑器都能完美打开——因为纯文字格式本身没有版本、没有依赖。
对于需要长期保存的知识（日记、研究笔记、个人知识库），纯文字是目前最能经得起时间考验的数字格式。
7. Markdown 的局限
Markdown 并非万能，有些场景仍不适合：
- 复杂排版：多栏位、精确的图文混排、页眉页脚设计仍需要 Word 或 InDesign
- 协作编辑：同时多人编辑同一份文档，Google Docs 的实时协作体验仍优于大多数 Markdown 工具
- 非技术用户：对不熟悉语法的人来说，
**粗体**不如工具栏按钮直观 - 表格复杂度：Markdown 表格语法相对受限，无法合并单元格或设置复杂公式
工具没有对错，只有适不适合。Markdown 最适合的场景是：需要版本控制、长期保存、跨平台分享，或与代码共存的文字内容。
8. 字数与长度：Markdown 写作的一个隐藏挑战
用 Markdown 写作时，有一个容易被忽略的问题：字数统计可能因渲染状态而有差异。
原始 Markdown 包含语法符号（#、**、[] 等），这些符号在渲染后会消失，但在纯文字状态下会被计入字数。如果你需要精确的字数（如稿费计算、SEO 文章长度要求），要特别注意是计算「原始 Markdown 字数」还是「渲染后纯文字字数」。
9. 小结
纯文字和 Markdown 的复兴，反映了人们对数字内容的重新思考：
- 数据所有权：你的笔记应该是你的，不应该被锁在某个服务里
- 长期可读性：纯文字是最能经得起时间考验的数字格式
- 版本控制友好：代码和文档理应使用同样的工作流程
- 跨平台通用性：Markdown 几乎在所有现代写作和开发工具中都被支持
如果你还没尝试过用 Markdown 写笔记或文档，可以从一个简单的 README 或日记开始——你很可能会发现，移除了多余的格式干扰之后，思路反而变得更清晰。