为什么我说 Obsidian 的 Markdown 支持「反人类」？

最近看到不少朋友在吐槽 Obsidian 的 Markdown 支持，甚至有人直接把它评为「最垃圾的」。这话说得虽然绝对，但如果你是从标准的 Markdown 编辑器（如 Typora、VS Code）转过来的，这种挫败感我简直太懂了。

很多人觉得 Obsidian 是神器，但它对 Markdown 的处理确实存在一些让人抓狂的「反直觉」设计。今天咱们不吹不黑，就来聊聊 Obsidian 在 Markdown 上到底哪让人不爽，以及有没有什么解决办法。

Obsidian 的 Markdown 到底有什么问题？

1. 语法的「私生饭」行为 Obsidian 用的不是纯粹的 CommonMark 标准。虽然它大体兼容，但在很多细节上搞了自己的那一套。最典型的就是 [[wikilink]] 这种双向链接语法。在很多纯 Markdown 编辑器里，这就是一堆乱码，但在 Obsidian 里这就是核心功能。这导致你的笔记迁移成本极高，一旦想换个软件，光是处理这些链接就能让你头皮发麻。

2. HTML 和 CSS 的渲染限制 如果你习惯在 Markdown 里写内联 HTML 来做复杂的布局或样式，Obsidian 可能会给你浇一盆冷水。出于安全考虑，它默认屏蔽了很多 HTML 标签和内联样式（比如 <style> 或者某些 on* 事件属性）。这就导致你原本在其他编辑器里跑得好好的高亮框、折叠块，到了 Obsidian 里全变成了纯文本。

3. 图片和附件的处理逻辑 标准的 Markdown 图片语法固然简单，但在实际使用中，绝对路径和相对路径总是容易打架。Obsidian 虽然有自己的附件管理机制，但当你尝试把文件导出为 HTML 或发给别人看时，经常会出现图片挂掉的情况。这种封闭生态在本地好用，一出去就水土不服。

4. 实时预览的「怪癖」 Obsidian 有个「实时预览」模式，号称是所见即所得，但本质上它还在编辑文本。在某些换行、空格或者列表嵌套的处理上，它和 GitHub 风格的渲染结果经常不一致。这种细微的视觉差异对于强迫症来说简直是折磨。

难道只能忍着？当然不

虽然 Obsidian 的原生支持有局限，但它强就强在插件生态。如果你不想换软件，可以试试这几招来缓解症状：

• 修复兼容性插件：社区里有一些插件专门用来修复标准的 Markdown 兼容问题，或者强制渲染某些原本被屏蔽的 HTML 标签（比如配合 Dataview 插件有时候能绕过一些限制）。
• 导出工具的选择：不要妄想直接把 .md 文件发给别人就能完美展示。利用 Pandoc 配合自定义模板，或者使用「Obsidian HTML」这类工具，可以在导出时规避掉很多渲染不一致的问题。
• 拥抱它的逻辑：如果决定长期用 Obsidian，就尽量按照它的 「Wiki」逻辑来写笔记，而不是把它当成纯粹的 Markdown 编辑器。利用它特有的属性和链接语法，反而能发挥出最大效率。

不想折腾？试试这些替代方案

如果你就是想要纯净、标准、所见即所得的 Markdown 体验，或许以下工具更适合你：

1. Typora：老牌王者，真正的所见即所得，对标准 Markdown 支持堪称教科书级别，除了收费（现在）几乎没有短板。
2. VS Code + Markdown Preview Enhanced：程序员的首选，渲染能力极强，支持数学公式、Mermaid 图表、甚至执行代码块，几乎支持你能想到的所有非标准扩展语法。
3. Obsidian 原生导出/编辑模式：其实很多人不知道，把 Obsidian 切换回到纯编辑模式（Ctrl+E 切换），它就是一个比较标准的文本编辑器，虽然界面没那么花哨，但渲染干扰最小。

结语

Obsidian 并不完美，它的 Markdown 支持在「标准化」和「功能扩展」之间做了取舍，偏向了后者。这让它成了一个强大的知识库，但同时也成了一个不那么标准的 Markdown 编辑器。

吐槽归吐槽，工具终究是为人服务的。你是忍受它的怪脾气换取强大的插件功能，还是投奔标准 Markdown 的怀抱，完全取决于你的工作流更看重哪一点。