问题

Markdown 语法与编辑器深度调研

  1. Markdown 语法解析
    Markdown 简介与基础语法:
    Markdown 是一种轻量级标记语言,由约翰·格鲁伯(John Gruber)在 2004 年创建​
    EN.WIKIPEDIA.ORG
    。它采用纯文本方式书写,通过使用特殊符号实现标题、列表、加粗、链接、图片等格式。Markdown 的设计初衷是让书写的源文本具有良好的可读性,同时能方便地转换为 HTML 等格式​
    CREATE.XYZ
    。常用的基础语法包括:
    标题(Headers): 使用 # 符号标记一级至六级标题,例如 # 一级标题。
    段落(Paragraphs): 段落之间空一行分隔。
    换行(Line Break): 在行尾插入两个空格或使用<br>标签。
    强调(Emphasis): 使用 *或_包裹文本实现斜体(一个符号)和粗体(两个符号)。如 加粗斜体
    列表(Lists): 使用 -、*或数字+点创建无序/有序列表。嵌套列表通过缩进实现。
    代码(Code): 行内代码使用反引号 ` 包裹,多行代码块用三个反引号 ``` 围住(或缩进4空格)。
    引用(Blockquote): 在行首使用 > 引用文字。可嵌套多级引用。
    链接(Links): 使用 链接文本,图像类似但前面加 !,如 Alt文本
    这些是 Markdown 原始版本的核心语法,适用于一般写作场景。它的优点是语法简单、易读易写,专注内容而非排版​
    BLOG.CSDN.NET
    。例如,在技术文档或博客中,用纯文本就能写出结构良好的文档而无需复杂的富文本编辑。 扩展语法与不同标准:
    由于 Markdown 最初的描述比较简略,实施中产生了一些差异和局限。社区和不同平台为满足需求,发展出了多种 Markdown 扩展 和标准,包括 GitHub Flavored Markdown (GFM)、CommonMark、Pandoc Markdown、Markdown Extra、MultiMarkdown 等​
    EN.WIKIPEDIA.ORG
    。这些变体在原始 Markdown 基础上增加了新语法或规则:
    GitHub Flavored Markdown (GFM): GitHub 早期在原始 Markdown 基础上增加了对表格、任务列表、删除线等格式的支持​
    EN.WIKIPEDIA.ORG
    。2017 年 GitHub 发布了 GFM 的正式规范,规定 GFM 是 CommonMark 的严格超集,除了遵循 CommonMark 标准外,额外添加了表格、删除线、自动链接和任务列表这四项扩展​
    EN.WIKIPEDIA.ORG
    。例如,在 GFM 中可以使用三条或以上的竖线和连字符绘制表格,在列表项前使用[ ]或[x]标记任务清单。GFM 现已成为许多平台(GitHub、Stack Overflow 等)的默认 Markdown 格式​
    EN.WIKIPEDIA.ORG

    CommonMark: 这是为解决各实现不一致而发起的标准化努力​
    EN.WIKIPEDIA.ORG
    。CommonMark 从2014年开始制定,旨在提供一个明确的 Markdown 规范。它兼容原始 Markdown 的核心语法,并消除歧义。CommonMark 本身偏保守,但作为底层规范被广泛采用​
    EN.WIKIPEDIA.ORG
    。例如 GitHub 将 CommonMark 作为基准,再加上自己扩展形成 GFM​
    EN.WIKIPEDIA.ORG
    。许多编辑器(如 VS Code、Obsidian)也使用 CommonMark 标准或其解析库。
    Markdown Extra: 由 PHP Markdown 的作者开发的一套扩展,实现了一系列实用功能​
    EN.WIKIPEDIA.ORG
    。Extra 新增了 表格、HTML 区块内使用 Markdown、带 ID/类的元素、多行围栏代码块、定义列表、脚注、缩略语 等​
    EN.WIKIPEDIA.ORG
    。比如 Extra 支持直接写脚注^[脚注内容]并在文末自动生成对应的注释列表​
    EN.WIKIPEDIA.ORG
    。这些扩展在技术文档中很常用,部分被后来的标准(如 GFM、Pandoc)吸收。
    MultiMarkdown: 由 Fletcher Penney 开发,是最早扩展 Markdown 的方案之一。它在 Markdown 基础上增加了 表格、脚注、图片属性、内部引用和交叉引用、元数据头信息等功能,并支持部分 TeX 数学公式语法。MultiMarkdown 常用于学术写作和 Mac 平台的写作工具中,影响了 Ulysses、Bear 等编辑器对 Markdown 的实现。
    Pandoc Markdown: Pandoc 是强大的文档转换工具,它定义了一种扩展 Markdown语法,几乎囊括了上述所有特性。Pandoc Markdown 支持 Extra 和 GFM 的大多数元素,以及 定义列表、下标/上标、强调高亮(==标记==)、引用文献、LaTeX 数学公式、Div块元素等数十种扩展​
    MARKDOWNGUIDE.ORG

    MARKDOWNGUIDE.ORG
    。Pandoc 将这些扩展设计为可开关的模块,用户可通过启用/禁用选项选择需要的语法​
    PANDOC.ORG
    。因此 Pandoc Markdown 非常灵活,常被用于复杂文档(如学术论文)的写作和格式转换。
    下表对比了几种主要 Markdown 变体对一些扩展语法的支持情况:
    语法功能 原始 Markdown GFM (CommonMark) Markdown Extra MultiMarkdown Pandoc Markdown
    表格 Tables 不支持 支持(管道表格)​
    EN.WIKIPEDIA.ORG
    支持​
    EN.WIKIPEDIA.ORG
    支持 支持(Pipe tables 等)
    脚注 Footnotes 不支持 不支持<small>(GitHub近期实现)</small> 支持​
    EN.WIKIPEDIA.ORG
    支持 支持(^注释语法)
    删除线 Strikethrough 不支持 支持(text)​
    EN.WIKIPEDIA.ORG
    不支持 不支持 支持
    任务列表 Task List 不支持 支持​
    EN.WIKIPEDIA.ORG
    不支持 不支持 支持 (+列表扩展)
    定义列表 Def. List 不支持 不支持 支持​
    EN.WIKIPEDIA.ORG
    不支持 支持 (+definition_lists)
    HTML 块嵌套 Markdown 不支持 不支持 支持​
    EN.WIKIPEDIA.ORG
    不支持 支持 (+markdown_in_html_blocks)
    数学公式 Math 不支持<small>(纯文本插入)</small> 不支持 (需插件) 不支持 部分支持<small>(仅转HTML)</small> 支持 (TeX 公式)
    链接引用和元数据 支持基本链接 支持 支持(缩略语等)​
    EN.WIKIPEDIA.ORG
    支持(文献引用) 支持(文献引用、YAML元数据)
    注:上表概括了各标准对部分常见扩展的支持。“支持”表示该变体内建支持相应语法;“不支持”表示需通过 HTML 或插件实现。 不同解析标准的兼容性: 各 Markdown 版本在细节上也有差异,需要注意兼容性。例如:
    换行规则:原始 Markdown 需要行尾两个空格才能换行,而 GFM/CommonMark 允许直接单换行作为换行(不需要两个空格)。编辑时如果跨平台查看,要小心换行处理差异。
    强调符号:有的实现对下划线 _ 非字母字符两侧的行为不同,CommonMark 对强调语法的规定更严格,避免了早期 Markdown 一些歧义。
    标题语法:GFM 要求 # 后必须有空格才识别为标题​
    EN.WIKIPEDIA.ORG
    ;一些旧实现则不严格。
    HTML 支持:多数实现支持内嵌 HTML 标签,但严格模式(如Pandoc的markdown_strict)会禁止 HTML。
    扩展差异:例如 Markdown Extra 的脚注语法 [^1] 与 Pandoc 脚注语法相同,都可兼容;但 Ulysses 等工具用 ^^或||等非标准标记来表示批注或删除线​
    MARKDOWNGUIDE.ORG

    MARKDOWNGUIDE.ORG
    ,在他处可能显示为原字符而非格式,需要转换。
    Markdown 使用教程与场景技巧:
    Markdown 语法简单,但在不同场景下有一些使用技巧:
    技术文档撰写: 使用 Markdown 编写README、API文档、教程等非常高效。可利用标题和列表组织层次,使用代码块展示代码片段,并辅以表格列出参数或对比数据。结合扩展语法,可以添加脚注引用文献、使用公式表达数学内容(配合 KaTeX/MathJax 渲染),非常适合技术和学术内容的书写。许多项目托管平台原生支持 Markdown 渲染,使其成为事实上的技术文档标准​
    EN.WIKIPEDIA.ORG
    。撰写时建议遵循某一规范(如 GFM),并使用 lint 工具检查语法以确保在不同解析器下显示一致。
    日常写作笔记: Markdown 常用于博客文章、笔记记录等。书写时可专注文字内容,不必分心于排版。利用引用来插入引言或提示块,使用分隔线 --- 分割章节。对于纯文本写作者,可在支持所见即所得的编辑器中实时预览样式(见下文编辑器部分)。写作完成后,可以通过转换工具将 Markdown 导出为 HTML、PDF 等格式发表。在写作中,良好使用 Markdown 还能帮助梳理思路,例如用列表列提纲、用粗体突出关键词等。
    AI 生成内容编辑: 近年来大量 AI 工具(如 ChatGPT)产出 Markdown 格式的内容,以便保留结构和格式​
    CREATE.XYZ
    。这意味着我们可以让 AI 自动生成带有标题、列表、表格等排版的 Markdown 文本,然后再在人类可读的基础上加以调整。例如,可要求 AI “用 Markdown 格式输出一篇介绍机器学习的博文,包含二级标题和列表”​
    CREATE.XYZ
    。AI 输出后,我们在编辑器中对照预览快速修改。Markdown 易于清理和转换,可用简单查找替换修正 AI 输出中的格式问题(如删除多余的反引号)。同时,Markdown 结构清晰,方便后续将 AI 内容转换为 HTML、Word 等格式用于发布。正因为 Markdown 简洁且结构化,它成为 AI 内容常用格式:“Markdown 比 HTML 简单得多,非常适合标示标题、列表、粗体等格式”​
    CREATE.XYZ
  2. Markdown 编辑器全景分析
    Markdown 编辑器种类繁多,功能侧重各异。我们可以按编辑模式和使用平台将其分类,并介绍国内外主流编辑器的特点、使用说明、快捷操作以及优缺点。
    2.1 编辑模式分类
    所见即所得 (WYSIWYG) 编辑器: 这类编辑器在编写时直接渲染格式,不显示原始 Markdown 符号,让用户“所见”即为最终排版效果。典型如 Typora、Mark Text、Bear、Ulysses 等。它们通过隐藏语法符号提供专注的写作体验​
    TYPORA.IO
    。优点是无需频繁在源码和预览间切换,所见即所得;缺点是有时可能无法精细编辑 Markdown 源文本(例如处理不常用语法或调试格式)。
    纯文本源码编辑器: 典型如 VS Code、Vim/Emacs(配合插件)等。这类工具把 Markdown 当作代码来编辑,直接显示 # ** [] 等源码符号,并通常提供侧边实时预览​
    CODE.VISUALSTUDIO.COM
    。优点是对 Markdown 语法掌控力强,所编即所得,可精确输入特殊符号;缺点是需要脑中预想排版或借助预览窗口,初学者可能觉得不直观。
    双栏模式编辑器: 介于上述两者之间,一侧是 Markdown 源文本,另一侧实时渲染预览,例如 Joplin(早期模式)、StackEdit 默认布局等​
    STACKEDIT.IO
    。这样可以同时查看源码和效果,并自动滚动同步定位​
    CODE.VISUALSTUDIO.COM
    。适合希望了解 Markdown 源码又想方便预览的人。
    混合模式编辑器: 一些新式编辑器提供“部分所见即所得”,即在编辑时对某些元素渲染(如粗体、斜体、公式),而对另一些仍保留源符号(如标题符号),实现源码与渲染并存。例如 Obsidian 的“实时预览”模式、Zettlr 的可定制渲染​
    ZETTLR.COM
    、iA Writer 显示 Markdown 标记但使用不同颜色/样式淡化处理。这种方式兼顾了直观和精确,日益流行。
    此外,还可按使用平台分类:
    桌面应用: 包括 Windows/Mac/Linux 本地运行的软件,如 Typora、VS Code、Obsidian、Mark Text、Joplin、Zettlr、Bear (Mac)、Ulysses (Mac) 等。它们通常功能强大,整合系统功能(文件系统、窗口管理)。
    Web 在线编辑: 通过浏览器即可使用的编辑器,如 StackEdit、HackMD、语雀 (Yuque) 等。不需安装软件,适合协作和随时访问,有的支持实时协同编辑。
    移动端应用: 专为手机/平板设计,如 Bear (iOS)、iA Writer (iOS/Android)、Joplin (iOS/Android)、Obsidian 移动版等。它们优化了触摸交互和小屏幕阅读,方便随时记录。
    下面按名称逐一介绍主流 Markdown 编辑器,每款都包含功能特点、使用要点以及适用场景的分析:
    Typora
    定位及特点: Typora 是一款广受欢迎的所见即所得 Markdown 编辑器。它以简洁优雅著称,在编辑时不显示任何冗余标记符号,实现“所见即所得”的流畅体验​
    TYPORA.IO
    。用户在 Typora 中输入文本,立即看到排版后的效果,比如输入 bold 会马上渲染为加粗。Typora 支持几乎所有常见 Markdown 语法和扩展,包括表格、代码块、数学公式、任务列表、目录等​
    TYPORA.IO

    TYPORA.IO
    。例如,可直接用 ...... 输入 LaTeX 数学公式,它将即刻渲染为公式结果。又如输入 - [x] 任务 会生成可勾选的任务列表​
    TYPORA.IO
    。Typora 还内置了图床上传、大纲视图、主题自定义、图片拖拽等实用功能​
    TYPORA.IO

    TYPORA.IO
    。其 Outline 大纲面板可以根据文档标题生成文档结构,方便导航​
    TYPORA.IO
    。 使用体验: Typora 所见即所得的体验非常顺滑,没有编辑/预览模式切换的干扰,这让很多人感觉“写作就像在纸上书写”般自然​
    TYPORA.IO
    。你可以直接在排版好的文本上编辑,就如同在 Word 等富文本工具中操作,但实际上保存的是纯 Markdown。它提供常用的快捷键(和富文本类似),如 Ctrl+B 加粗、Ctrl+I 斜体、Ctrl+Shift+K 插入链接等,降低 Markdown 学习成本。通过右键或菜单也能方便插入表格、列表等。Typora 支持所见即可调整:比如直接拖拽表格边框可调整列宽,拖动图片角实现缩放​
    TYPORA.IO
    。这使得编辑 Markdown 表格等复杂元素变得直观。Typora 另一个优点是导入导出格式丰富,它内置 Pandoc 转换,支持将 Markdown 一键导出为 PDF(含书签)、HTML、Word (docx)、OpenOffice、LaTeX、ePub 等多种格式​
    TYPORA.IO
    。这在需要发布或与不同软件交互时非常实用。此外,Typora 还有黑暗模式、打字机模式、专注模式等界面功能,满足深色环境和专心写作需求​
    TYPORA.IO
    。 优缺点总结: Typora 的优势在于极佳的写作体验和全面的功能:所见即所得减少了格式干扰,同时又几乎涵盖所有 Markdown 扩展,用途广泛。它跨平台支持 Windows/Mac/Linux,适合写博客、技术文档、日常笔记等各种场景。劣势方面,一是目前不支持插件拓展(功能由官方提供固定),个性化拓展性略有限;二是对于追求看到原始 Markdown 源码的人来说,它隐藏了符号可能不习惯。不过用户可随时用快捷键或View Source Code查看源文本。需要注意的是,Typora 现已收费:自2021年正式版起采用一次性买断制,价格为 14.99 美元,可免费试用15天​ TYPORA.IO 。相对于其强大功能和后续更新支持,这个价格对重度写作者而言是值得的投资。 Mark Text 定位及特点: Mark Text 是一款开源免费的所见即所得 Markdown 编辑器,被视为 Typora 的有力替代品。它同样提供实时渲染的写作界面,支持 GFM 和 CommonMark 全部规范,并选择性支持 Pandoc 扩展​ GITHUB.COM 。Mark Text 的特色包括:内建数学公式 (KaTeX)、YAML 前置Front Matter、表情符号支持等扩展​ GITHUB.COM ;提供多种主题和编辑模式(包括源码模式、打字机模式、专注模式)​ GITHUB.COM ;可将 Markdown 导出为 HTML、PDF 等格式​ GITHUB.COM 。作为 MIT 开源项目,Mark Text 跨平台(Win/Mac/Linux)且永久免费​ GITHUB.COM 。 使用体验: 打开 Mark Text,界面简洁清爽,左侧为文档列表管理,右侧编辑区域即时预览。用户输入 Markdown 时,格式会立即呈现(和 Typora类似)。Mark Text 特别之处在于,它允许用户切换到源码模式:如果需要精修 Markdown 源码,可启用 Source Code Mode 来查看原始标记​ GITHUB.COM 。这对熟悉 Markdown 的技术用户很有帮助,可随时检查有没有遗漏符号等。Mark Text 提供段落和行内格式快捷键,可提升写作效率​ GITHUB.COM 。例如,输入 ** 会自动补全双星号并放置光标于中间。它还支持粘贴截图/图像直接生成 Markdown 图片链接​ GITHUB.COM ,方便插入图片。编辑表格时,可以通过上下文菜单增删行列。Mark Text 预置了一些主题(如浅色 Cadmium Light、深色 Material Dark 等)以适应不同喜好​ GITHUB.COM 。另外,它也具备打字机模式(当前行居中高亮)和焦点模式(只突出正在编辑的段落),有助于沉浸写作​ GITHUB.COM 。 优缺点总结: Mark Text 的优势在于开源免费且功能完善。它实现了 Typora 大部分特性​ GITHUB.COM (实时预览、数学公式等),对个人和学生特别友好,不用担心付费问题。其代码模式满足进阶用户需求。缺点方面,目前 Mark Text 仍在积极开发中(截至 2025 年仍未出1.0正式版),稳定性稍逊,有时可能遇到渲染 bug 或性能问题。但随着社区支持,这些问题在逐步改善。总体而言,Mark Text 非常适合不想付费又想要所见即所得体验的用户,尤其在 Typora 收费后,它成为很多人的首选替代工具​ BLOG.CSDN.NET 。 Obsidian 定位及特点: Obsidian 是近年崛起的强大 Markdown 知识库管理工具。它本质是一个本地笔记软件,所有笔记以 Markdown 文件形式保存在用户硬盘,被称为“Vault”。Obsidian 最大的特色在于双链式笔记和知识图谱:用户可通过[[笔记名]]创建笔记间的双向链接,软件会自动维护连接关系,并提供可视化的节点网络图(Graph View)展示笔记之间关联​ OBSIDIAN.MD ​ OBSIDIAN.MD 。这使 Obsidian 非常适合构建个人知识管理(PKM)系统。Obsidian 使用 CommonMark/GFM 语法作为基础解析,加上了Wiki链接、标签(#tag)等扩展,以及支持Mathematics(LaTeX公式)、Mermaid流程图、任务列表等常用元素。它的核心和插件系统几乎涵盖了笔记软件的一切功能:全文检索、笔记嵌入、附件管理、加密、日记、模板等等。 使用体验: Obsidian 默认提供编辑模式和预览模式,v0.13 以后的版本还提供了所见即所得的实时预览模式。一般写作时,用户处于实时预览模式下,大部分语法会渲染(例如粗体、链接会高亮),而在当前编辑行上会暂时显示 Markdown 源,以便修改。这样兼顾了格式直观和源码控制。Obsidian 的界面可自定义布局,典型布局是一左一右两个面板:左侧为笔记列表/大纲/标签等侧边栏,右侧是编辑/预览区域。用户可开多个笔记窗口便于参考。Obsidian 支持常用的 Markdown 快捷输入,如输入 [ 时弹出笔记名称联想,用于快速创建/链接其他笔记(wiki链接)。通过 Ctrl+O 可以模糊搜索笔记标题快速打开,非常高效。它还提供大纲视图(根据文内标题生成导航)、背链面板(显示所有链接到当前笔记的引用)。对于高级用户,Obsidian 有强大的插件系统:官方和社区提供了上千个插件扩展功能​ OBSIDIAN.MD 。比如 Calendar 日历插件用于日志笔记,Kanban 看板插件将笔记呈现为任务板,甚至有 AI 自动摘要插件等。UI 主题也可通过社区主题自由更换,或使用自定义 CSS 调整​ HELP.OBSIDIAN.MD 。总的来说,Obsidian 更像一个Markdown平台而非单纯编辑器。 优缺点总结: Obsidian 的优势在于知识管理和扩展性。它不仅是写作工具,更是个人知识库:双向链接+图谱让笔记形成有机网络,适合科研笔记、学习笔记等场景。其插件生态极其繁荣,可根据需要拓展几乎任意功能,界面和工作流高度可定制​ OBSIDIAN.MD 。此外,Obsidian 离线本地储存,数据完全归用户自己​ OBSIDIAN.MD ;官方没有云端,确保私密性,同时可自行选择网盘或 Obsidian Sync 同步。劣势方面,一是初学者上手可能略有门槛——功能太多,需要一定学习成本去配置最优工作流;二是虽然基本功能免费,但一些增值服务收费(如同步服务每月 8,发布服务每月 16)​BLOG.CSDN.NETObsidian本身并非开源(源码未公开),仅插件社区开源,这点与完全开源的软件有所区别。对于只想要简洁写作的人来说,Obsidian可能显得“过重”。但对于希望将Markdown笔记进行长期管理和深入挖掘的个人或团队,Obsidian是强大的利器。VSCode定位及特点:VisualStudioCodeVSCode)本质是代码编辑器,但因其优秀的扩展能力和性能,也常被用作Markdown编辑器。VSCode自带Markdown基本支持:内置Markdown语法高亮和预览功能​CODE.VISUALSTUDIO.COM。在VSCode中编辑.md文件,可以通过快捷键Ctrl+Shift+V切换右侧预览,在编写文本的同时实时看到渲染效果​CODE.VISUALSTUDIO.COM。预览窗格和编辑窗会同步滚动定位​CODE.VISUALSTUDIO.COMVSCodeMarkdown提供了一些增强:代码块会自动做语法高亮,支持任务列表和表格渲染,以及通过设置启用数学公式(KaTeX)支持​CODE.VISUALSTUDIO.COM。从v1.45起,VSCode内置KaTeX,可以直接在Markdown预览中渲染16)​ BLOG.CSDN.NET 。Obsidian 本身并非开源(源码未公开),仅插件社区开源,这点与完全开源的软件有所区别。对于只想要简洁写作的人来说,Obsidian 可能显得“过重”。但对于希望将 Markdown 笔记进行长期管理和深入挖掘的个人或团队,Obsidian 是强大的利器。 VS Code 定位及特点: Visual Studio Code(VS Code)本质是代码编辑器,但因其优秀的扩展能力和性能,也常被用作 Markdown 编辑器。VS Code 自带 Markdown 基本支持:内置 Markdown 语法高亮和预览功能​ CODE.VISUALSTUDIO.COM 。在 VS Code 中编辑 .md 文件,可以通过快捷键 Ctrl+Shift+V 切换右侧预览,在编写文本的同时实时看到渲染效果​ CODE.VISUALSTUDIO.COM 。预览窗格和编辑窗会同步滚动定位​ CODE.VISUALSTUDIO.COM 。VS Code 对 Markdown 提供了一些增强:代码块会自动做语法高亮,支持任务列表和表格渲染,以及通过设置启用 数学公式(KaTeX) 支持​ CODE.VISUALSTUDIO.COM 。从 v1.45 起,VS Code 内置 KaTeX,可以直接在 Markdown 预览中渲染 ... 和 $$...$$ 数学表达式​ CODE.VISUALSTUDIO.COM 。此外,VS Code 有丰富的Markdown 扩展插件,如 Markdown All in One(提供目录自动生成、列表自动续编号等功能)、Markdown PDF(导出为 PDF)、Mermaid 支持(渲染流程图)等,可按需安装。 使用体验: VS Code 作为综合编辑器,对于经常需要在代码和文档间切换的开发者非常方便。在写代码的同时,可以直接打开 README.md 编写项目文档。它提供快捷键快速预览或侧边预览​ CODE.VISUALSTUDIO.COM 。并且 VS Code 允许同时编辑多份文档,对比查看非常容易。Markdown 编辑中,VS Code 支持快捷补全:例如输入 [ 会提示已有文档链接(如果启用了相应插件);输入表格 | 分隔时插件可自动对齐列;输入 ![]() 插入图片时,如果安装 Paste Image 插件,可以直接贴图生成本地文件和路径。VS Code 也支持 Emojis 短代码和 Tex 数学,配置简单开关即可​ CODE.VISUALSTUDIO.COM 。对于需要版本控制的文档,VS Code 与 Git 集成,可方便地对 Markdown 文档进行 Git 跟踪、差异比较(Markdown 纯文本的优势也在此)。例如用 VS Code 打开Git管理的Wiki或博客仓库,撰写完成后直接提交。调试预览也不成问题:VS Code 预览窗口本质是 HTML,可通过开发者工具检查元素和样式,便于发现 Markdown 渲染问题。 优缺点总结: VS Code 的长处在于扩展性和集成度。对于开发者或技术作者来说,它能在同一工具内完成编码和文档写作,并利用其强大的插件生态满足各种额外需求。VS Code 本身完全免费且跨平台,对个人和企业都是零成本。不足之处在于,相较专门的 Markdown 工具,它缺少一些针对写作的便捷功能(比如 Typora 那样的直观表格编辑、截图粘贴等需插件实现)。其所见即所得体验也不如 Typora/Mark Text 那般无缝——VS Code 还是偏向源码编辑,要看效果必须开预览分屏。对于不熟悉 VS Code 的纯文案人员,上手也不如专用编辑器直观。不过通过安装 All in One 等插件,VS Code 也能变得对 Markdown 更友好​ BLOG.CSDN.NET 。总的来说,如果你本身就在 VS Code 开发,那么顺便用它写 Markdown 是非常顺畅的选择;但若纯粹为了写作,Typora 等或许更省事。 Joplin 定位及特点: Joplin 是一个开源免费的跨平台笔记软件,主打 Markdown 笔记和待办管理。它支持 Windows、macOS、Linux 以及 Android、iOS,是少数全平台覆盖的 Markdown 应用​ SSPAI.COM ​ SSPAI.COM 。Joplin 界面类似 Evernote 等笔记工具,但底层笔记格式都是 Markdown。这意味着每条笔记都可以用 Markdown 语法书写,Joplin 会在笔记视图中渲染显示。其特性包括:多设备云同步(支持 OneDrive、Dropbox、NextCloud 等,或订阅官方 Joplin Cloud)​ MARKDOWNGUIDE.ORG ;端到端加密 (E2EE),保证笔记云端存储安全​ MARKDOWNGUIDE.ORG ;笔记本和标签分类,方便组织;笔记历史(版本管理);待办事项(每条笔记可设为待办并打勾);网页剪裁(浏览器插件将网页保存为 Markdown)等​ SSPAI.COM ​ SSPAI.COM 。Joplin 对 Markdown 语法的支持非常全面,“100% 支持 Markdown,包括 LaTeX 数学公式”​ GITHUB.COM 。它实现了 GFM 的所有元素,如表格、任务列表、删除线等,以及脚注、下划线、高亮、下标/上标等扩展​ MARKDOWNGUIDE.ORG ​ MARKDOWNGUIDE.ORG 。许多扩展示例需要在设置中开启对应插件(Joplin 内置了若干开关项用于启用扩展语法)​ MARKDOWNGUIDE.ORG 。例如定义列表和Emoji shortcode默认关闭,需要在设置中启用插件支持​ MARKDOWNGUIDE.ORG 。Joplin 还支持 Katex 数学公式(行内和块)和 Mermaid 流程图等,通过插入特定代码块语法实现。 使用体验: 打开 Joplin,左侧是笔记本树状列表,中间是笔记的 Markdown 编辑区域,右侧是渲染预览区域(可关闭)——默认为三栏布局,也可切换为所见即所得编辑模式。在分栏模式下,一边写 Markdown 一边看效果​ MARKDOWNGUIDE.ORG 。Joplin 提供富文本编辑器模式(Beta特性),对于不熟悉 Markdown 的人也可以用类似 Word 的工具栏编辑,但背后仍生成 Markdown。所以一般推荐直接使用 Markdown 编辑。Joplin 的编辑器有自动完成一些格式,例如输入 [] 会提示输入待办框 [ ] 或 [x]。每条笔记可以拖入附件(图片、PDF等)并引用,数据文件都会同步。通过搜索可以全文检索笔记内容(包括 OCR 图片/PDF 中的文字,在开启插件的情况下)​ BEAR.APP 。Joplin 帮助用户维护链接引用:如果笔记 A 内有链接指向笔记 B,重命名 B 时 Joplin 会自动更新 A 中的链接,防止失效。Joplin 也支持 模板,可以保存常用笔记格式以便新建时套用。对于使用习惯来说,Joplin 结合了传统笔记软件的管理便利和 Markdown 的简洁。例如,写日记时可以有一个“日记”笔记本,每天一条,用模板生成标题日期;写待办则创建待办笔记,用 - [ ] 列出任务,可通过勾选来打完成功能​ SSPAI.COM 。Joplin 的同步设置灵活,你可以选择自己信任的云(如坚果云WebDAV)进行同步,而不必依赖官方服务。启用端到端加密后,即使云端泄露数据也因密文而确保安全​ MARKDOWNGUIDE.ORG 。这一点对于注重隐私的用户很有吸引力。 优缺点总结: Joplin 的优势在于全面且自由:功能上“该有的都有”,甚至超过很多商业笔记应用(例如支持加密、多平台同步,这是不少竞品缺乏的)​ SSPAI.COM 。它的 Markdown 支持非常完整​ MARKDOWNGUIDE.ORG ,脚注、公式等一应俱全,完全可以满足技术笔记需求。作为开源项目,Joplin 社区也开发了插件(从2.0版本起支持插件扩展),可进一步增强功能。它完全免费,没有容量或设备数量限制,对个人非常友好。劣势方面,一些用户界面不够华丽、细节有待打磨。例如某些菜单项翻译不完善​ SSPAI.COM ,笔记共享协作能力较弱(缺少多人实时编辑,只能导出分享)。另外 Joplin 由于要维护大量功能,性能上在笔记特别多时稍有影响。不过总体来看,Joplin 是取代 Evernote 等笔记应用的开源利器,非常适合需要离线笔记+Markdown的人士​ SSPAI.COM 。尤其程序员群体,对其评价很高:“除了拥有 Typora 正常的编辑能力外,Joplin 还支持多种云盘同步... 还支持端到端加密、To-Do 待办事项、笔记历史版本... 等等功能”​ SSPAI.COM 。许多用户(包括引用作者)已经完全用 Joplin 替代 Typora 等,成为日常主力​ SSPAI.COM 。 Zettlr 定位及特点: Zettlr 是面向学术和专业写作者的开源 Markdown 编辑器,被称为“写作工作台”。它以 Markdown 为核心,融合了Zettelkasten(卡片笔记)思想和文献管理功能,特别适合科研论文写作和知识管理​ MARKDOWNGUIDE.ORG 。Zettlr 免费开源(GPLv3),支持 Win/Mac/Linux。其主要特色:文献引用管理 – 原生支持 BibTeX/CSL 文献库,提供引用键自动完成功能,可直接在文中插入[@引用]格式,预览中渲染文后参考文献列表​ DOCS.ZETTLR.COM ​ ZETTLR.COM ;Pandoc 集成 – 和 Pandoc 联动,可一键将 Markdown 导出为 PDF、DOCX、LaTeX 等,支持自定义 CSL 样式以套用期刊格式​ ZETTLR.COM ;Zettelkasten支持 – 每篇笔记可生成唯一 ID,并可以双链引用其他笔记,软件提供快速搜素和跳转,帮助构建知识网络​ MARKDOWNGUIDE.ORG ;多文件项目 – 可以将多个 Markdown 组织成项目,甚至有“Book Mode”类似功能将其拼合输出,适合写书或长文档;语法高亮与扩展 – 支持 GFM 全部语法以及 LaTeX 公式、Mermaid 图表等渲染,支持 YAML 元数据和页面注释等元素​ ZETTLR.COM 。此外,Zettlr 还有内容面板(显示当前文档标题列表)、黑暗模式、批量查找替换等贴心功能。 使用体验: 初次使用 Zettlr,会感觉界面类似 VS Code + Typora 的结合:左侧是文件和笔记列表,中间是编辑器(显示 Markdown 源,但高亮不同语法元素),右侧可选打开预览或文献列表。Zettlr 默认是所见即所得程度中等的编辑体验:例如数学公式 $E=mc^2$ 会渲染出公式字符​ ZETTLR.COM ,Mermaid 代码块也会直接渲染图表,从而“所见即所得”;但普通粗体仍显示为 **粗体**(只是加粗高亮显示文本),因此用户可同时看到语法符号和格式效果。这个折衷让学术用户很受用——既能确认渲染是否正确,又不会完全隐藏标记符号。写作过程中,通过快捷键或菜单,可以插入引用文献:如按 Ctrl+Shift+O 弹出文献库搜索,选中后插入 [@文献ID]。预览或导出时,会自动根据 CSL样式生成规范的参考文献列表​ DOCS.ZETTLR.COM 。Zettlr 的搜索功能强大,支持跨笔记全文搜索(方便从几十上百篇笔记中检索信息)​ HENDRIK-ERZ.DE 。对于论文写作场景,它有注释模式,可以插入注释块而不会计入最终导出字数​ ZETTLR.COM 。它还有统计功能,实时显示当前字数、字符数等。Zettlr 非常注重与外部工具集成:可调用系统的 PDF 阅读器、与 Zotero 引文管理联动(自动更新文献库),与 Linguee 集成进行翻译查词等等​ ZETTLR.COM 。用 Zettlr 写论文,可以在一个软件里完成:查资料、写正文、插入引用、检查格式、最后用 Pandoc 转格式。整个流程无缝衔接。 优缺点总结: Zettlr 的优势在于专为学术和专业写作设计:文献管理、一键导出发表格式、省心的引用与注释,这些功能在一般 Markdown 编辑器中是缺乏的。它让非代码出身的研究者也能享受 Markdown 的好处,而无需深究技术细节​ MARKDOWNGUIDE.ORG 。作为开源软件,Zettlr 免费且不断改进,官方文档和用户手册也非常完善。劣势方面:Zettlr 相对于轻量编辑器要“重”一些,启动和运行占用资源较高;对于单纯写笔记的人,它的一些高级功能可能用不上,界面稍显复杂。另外,Zettlr 强大的 Pandoc 导出需要用户安装 Pandoc 软件,并可能安装 LaTeX 环境以导出 PDF,初次配置稍有门槛。不过文档对此有详细指导。总的来说,如果你需要写论文、科研笔记或者想用 Markdown 写一本书,Zettlr 是理想选择。如果只是日常随笔,Zettlr 可能有些大材小用。但不论如何,它丰富的特性让它在 Markdown 编辑器中独树一帜,被誉为“科研写作一站式工作台”​ MARKDOWNGUIDE.ORG 。 语雀 (Yuque) 定位及特点: 语雀是阿里巴巴出品的在线知识库与文档协作平台,广泛用于团队知识管理。它支持 Markdown 语法编辑,但采用了浏览器富文本界面,提供所见即所得的编辑体验。语雀将文档按“知识库”组织,可设置团队协作权限,非常适合企业内部 Wiki、技术文档库等。多人实时协作是语雀的重要功能:多名成员可同时编辑一篇文档,光标和更改会实时同步(类似石墨文档、Google Docs)​ BLOG.CSDN.NET 。对 Markdown 的支持方面,语雀编辑器允许直接粘贴 Markdown 内容或以 Markdown 语法书写,并提供工具栏按钮插入标题、粗体、代码块、数学公式等,使非技术背景的用户也能使用 Markdown 强大的格式能力​ GEEKDAXUE.CO 。语雀还集成了评论批注、历史版本、文档导出(PDF、Markdown 等格式)等知识库所需功能。作为阿里生态一部分,语雀和钉钉、飞书等办公IM集成,可以在钉钉中直接查看语雀文档。​ BLOG.CSDN.NET 使用体验: 使用语雀需要登录 Web 或客户端。在新建文档时,可以选择 Markdown 编辑模式。界面上部有格式工具栏(标题、加粗、引用等按钮),但用户也可直接输入 Markdown 标记。语雀对 Markdown 语法兼容良好,支持标准语法和流程图Mermaid、LaTeX公式等高级内容,满足技术文档需求​ BLOG.CSDN.NET 。在协作中,每个编辑者的光标用不同颜色标识,并可以在文档侧边留下评论(不会出现在正文)。团队成员可对文档设置阅读或编辑权限,方便知识沉淀与分享。语雀的搜索和分类功能强大,可以按知识库/标签/标题搜索大量文档​ BLOG.CSDN.NET 。另外,语雀支持 API 与导出,用于与本地工具集成。例如可以将整个知识库导出为离线 HTML 或 Markdown 包,以备份或迁移。对于个人用户,语雀也可以当作云笔记使用,但它真正强势在于团队协作和国内服务优化:在国内网络下访问速度快、稳定性高​ BLOG.CSDN.NET 。和国外的 Notion 相比,语雀有本地化优势,无需担心连接不稳定或界面语言问题​ BLOG.CSDN.NET 。 优缺点总结: 语雀的优势集中在团队场景:本土部署带来速度和稳定,多人实时协作编辑顺畅​ BLOG.CSDN.NET ;专注文档和知识库管理,提供分类、标签、全文搜索等强大管理能力​ BLOG.CSDN.NET ;良好支持 Markdown,受到技术团队青睐​ BLOG.CSDN.NET 。它对个人免费,团队版也相对经济(阿里云用户可直接开通,商业版费用相比 Notion 等低一些)。劣势方面,语雀作为商业产品,个性化定制和第三方集成略少​ BLOG.CSDN.NET ;相比 Obsidian 等,本地数据掌控弱一些(需要联网访问,离线使用不便)。另外,语雀虽然支持 Markdown,但编辑体验更接近富文本,纯 Markdown 发烧友可能更倾向本地工具。不过对于国内企业和团队,语雀无疑是非常实用的协作文档平台,在国内服务可用性和数据安全(大厂背书,不会轻易关停)上有很大优势​ BLOG.CSDN.NET 。总而言之,如果需要一款支持 Markdown 的多人在线文档,语雀是推荐选择。 Notion 定位及特点: Notion 是一款集成笔记、文档、数据库、项目管理等功能的全能型协作工具。虽然 Notion 不是传统意义上的 Markdown 编辑器,它采用块(Block)结构的所见即所得编辑,但对 Markdown 语法有良好支持:用户可以在 Notion 文本块中直接使用 **、# 等 Markdown 标记,Notion会实时将其渲染为格式。Notion 可以将页面导出为 Markdown 文件,并支持从 Markdown 导入。它的强项在于多功能集成,可以在同一页面管理富文本、表格、任务板、嵌入内容等​ BLOG.CSDN.NET 。Notion 提供个人、团队和企业不同层级的服务:个人版如今免费且不限页数,团队版需要订阅。对于习惯 Markdown 的用户,Notion 依然可以通过 Markdown 快捷输入来高效编辑内容,只是最终存储并非纯 Markdown 文件,而在 Notion 云端数据库中。 使用体验: 在 Notion 中,所有内容都是块。编辑文本块时,可以直接键入 Markdown 标记,例如输入 ## 标题 然后空格,会自动转换为二级标题样式;输入 - [ ] 会出现复选框。Notion 也支持在块内插入行内代码、代码块(带语法高亮)、数学公式等(使用 触发公式块)。这种体验对 Markdown 用户很友好,无需学习 Notion 特有语法。Notion 更强大的是拖拽排版和模板:块可以自由拖动调整顺序、左右分栏,提供很多现成模板实现 Wiki、看板、日历等视图​
    BLOG.CSDN.NET
    。比如,可以创建一个 Markdown 风格的知识库页面,其中一部分是使用 Markdown 写的文档说明,另一部分是嵌入的任务列表数据库。Notion 的多媒体和嵌入功能也胜过一般 Markdown 编辑器,图片、视频、甚至 Figma 文件都能直接嵌入。协作上,Notion 支持多人编辑和评论,但免费版实时协作功能有限制。全局搜索可以搜索所有页面文本,迅速定位内容。在和 Markdown 的融合上,Notion 可以将某个页面导出 Markdown(每个子页面成为一个 .md 文件文件夹),这使得内容可以迁移或备份到本地​
    BLOG.CSDN.NET
    。然而要注意 Notion 导出的 Markdown 可能包含一些 Notion 特有标记(如 :: 高亮等需要后处理)。 优缺点总结: Notion 的优势是极高的灵活性和强大的整合能力。它几乎可以“做任何事”,从写笔记到项目管理,在一个工具中完成​
    BLOG.CSDN.NET
    。界面美观现代,可拖拽布局,对于追求一体化和美观界面的用户很有吸引力​
    BLOG.CSDN.NET
    。对 Markdown 用户来说,其支持 Markdown 输入和导出,降低了迁移门槛。劣势方面,正因功能众多,新用户可能不知如何下手,上手曲线较陡​
    BLOG.CSDN.NET
    。另外它是云服务,国内访问有时速度慢甚至无法连接​
    BLOG.CSDN.NET
    (目前官方已支持简体中文界面,但服务器仍在国外)。对于关注数据私有的用户,Notion 数据托管在云端也可能有顾虑​
    BLOG.CSDN.NET
    。最后,Notion 免费版虽强大,但高级功能(如团队权限、更大上传空间)需要订阅付费,个人每年约 48 美元​ BLOG.CSDN.NET 。总之,如果需要一款跨笔记/文档/数据库的全能工具,并且可以接受联网使用,那么 Notion 非常出色;而若重点是离线 Markdown 写作,可能还是专用编辑器更合适。很多团队会将 Notion 作为 Wiki 知识库,同时个人使用 Obsidian 等做本地笔记,根据需求各取所长。 Bear 定位及特点: Bear 是一款专注于美观写作和笔记的 Markdown 应用,适用于 macOS 和 iOS 平台。Bear 以简洁优雅的界面、顺滑的写作体验著称,深受苹果生态用户喜爱。它采用混合 Markdown 编辑模式:大多数 Markdown 语法会即时渲染(如粗体、标题以不同文本样式显示),但源符号仍部分可见(如 ** 会被淡化显示)​ MARKDOWNGUIDE.ORG 。这对 Markdown 新手友好,因为能同时学习语法和看效果。Bear 支持 Markdown 扩展较丰富,包括 GFM 表格、脚注、高亮标记==、下划线、任务列表等,还支持一些自定义标记(比如 ::标记:: 用于高亮,^^注释^^ 添加注释)。Bear 特色功能有:标签系统 – 任意笔记内打 #标签 自动归类,支持层级标签;双链 – 用 [[笔记名]] 可链接其他笔记;附加画草图 – 在 iOS 上可用 Apple Pencil 在笔记中插入手写图;多格式导出 – Bear Pro 订阅用户可将笔记导出为 TXT, Markdown, PDF, HTML, DOCX, ePub 等多种格式​ BEAR.APP ​ BEAR.APP 。Bear 注重跨设备同步,通过 iCloud 实现苹果设备间笔记无缝同步(需订阅)。安全性方面,Bear 支持为笔记上锁和加密。 使用体验: Bear 打开就是干净的三栏:左边标签列表,中间笔记列表,右边编辑区域。无繁杂按钮,所有格式以 Markdown 输入。写作时,当前行或所选文字的 Markdown 语法符号会隐藏,仅显示格式效果,其它地方则淡化显示语法符号​ MARKDOWNGUIDE.ORG 。例如正在编辑一段粗体时,会看到加粗效果而无 **;一旦移开,该 ** 符号会以半透明形式可见。这种设计被称为“混合模式”,兼具直观和可控。Bear 有一些提升效率的小功能:输入 # 会弹出已有标签列表自动补全;双击某词可一键将其加粗或变斜体;在 Mac 上有丰富的 快捷键(如 Cmd+1~Cmd+6 切换标题级别,Cmd+B/I 加粗斜体等)。Bear 的主题很多,Pro 用户可以切换二十多种精美主题,使编辑器成为赏心悦目的创作环境​ BEAR.APP 。Bear 也支持 焦点模式,隐藏所有侧边栏,让用户专注在文字上。另外 Bear 能识别程序代码块并高亮,支持任务清单的复选框渲染,对于日常记事和轻量技术笔记都够用。通过 Bear Pro 订阅,用户还能在不同苹果设备之间通过 iCloud 同步笔记,速度很快且数据加密传输​ BEAR.APP ​ BEAR.APP 。对于需要将笔记发布或备份,Bear 的导出功能相当实用:可以一键把带图片的笔记打包为 PDF,或者输出为带附件的 TextBundle,方便与他人分享或迁移。 优缺点总结: Bear 的优势在于极佳的用户体验:界面美观、操作流畅、编辑体验介于纯文本和所见即所得之间,让写作本身充满愉悦感​ BLOG.BEAR.APP 。它的标签组织+全文搜索组合,使个人笔记管理既灵活又高效。对于苹果用户,Bear 深度优化了 macOS/iOS 的交互,支持 Handoff、Apple Watch 快速记录等生态功能,并通过 iCloud 保持数据私密和同步便利​ BEAR.APP ​ BEAR.APP 。Bear 也注重隐私,笔记数据仅存本地/iCloud,开发商无法窥视​ BEAR.APP 。劣势方面,Bear 有平台局限:没有官方的 Windows/Android 客户端,这使非苹果用户无法使用,也是Bear被诟病的一点。其次,高级功能需要订阅 Bear Pro(每月 2.99 或每年 29.99)​BEAR.APP,免费版功能有限(不含同步、导出PDF/DOCX、主题等​BEAR.APP)。另外,Bear不支持插件扩展,功能相对固定。对于写作极客来说,它缺少比如双向链接图谱等高级功能(不过Bear2已开始支持部分双链)。总的说来,如果你处在苹果生态,喜欢简洁又漂亮的笔记工具,Bear是非常理想的选择,尤其适合日记、散文、随笔这类创作和日常记录。它的设计哲学就是让用户“专注内容而非排版”,正吻合Markdown的初衷​CREATE.XYZUlysses定位及特点:UlyssesmacOS/iOS上知名的写作应用,专为职业作家和长文写作者打造。它采用自己的标记语言MarkdownXL作为底层格式​STORIES.ULYSSES.APPMarkdownXL扩展自标准Markdown,增加了注释、脚注、评论等功能,以满足写作过程中的标注需求​STORIES.ULYSSES.APPHELP.ULYSSES.APPUlysses提供无干扰的写作环境和强大的组织管理(基于“片段”分章节),拥有目标字数设定、写作进度跟踪、语法检查等专业功能。同时,Ulysses的导出发布能力极强:可自定义样式将文稿导出为PDFDOCXHTML,甚至直接发布到博客平台(WordPressMedium)等。作为所见即所得的代表,Ulysses在编辑时几乎不让用户看到Markdown语法符号——粗体、斜体通过字体样式表示,链接以下划线高亮但不显示[](),图片则以缩略图显示。这给人一种“纯文本却富格式”的独特体验​MARKDOWNGUIDE.ORG。使用体验:Ulysses的界面与Bear有点类似:左侧文集组织,右侧编辑器。但Ulysses更侧重项目级管理,支持将多个文档组织成层级章节。写作时,没有可见的Markdown标记干扰,你直接输入内容并通过快捷键或菜单设置格式。如选中文本按Cmd+B就变粗体(但源文件实际用了MarkdownXL特定标记)。值得注意的是,Ulysses不完全兼容标准Markdown语法:​MARKDOWNGUIDE.ORG它不支持传统Markdown链接和图片语法,你需要用快捷菜单插入链接或图片;也不支持行内代码和围栏代码块的常规语法,而是通过菜单插入代码块元素​MARKDOWNGUIDE.ORG。这意味着,如果导出纯MarkdownUlysses会使用自己的标记格式:比如用删除内容表示删除线,而非  ​MARKDOWNGUIDE.ORG;用::高亮::表示高亮,而不是==MARKDOWNGUIDE.ORG。编辑时这些标记对用户是不可见的,看到的只是删除线效果或高亮底色。不过,这对希望在别的Markdown工具打开原文的人造成了麻烦(需要特殊转换)。Ulysses非常强大的地方在于审稿和排版:它有注释和备注功能,可在文中插入仅作者可见的备注而不影响导出​HELP.ULYSSES.APP;支持设定每篇文章的写作目标(字数/字符),实时显示进度;提供多个窗口同时编辑不同章节。Ulysses的导出样式可深度定制,你可以编写自定义样式表控制PDF/DOCX的字体、间距、页眉页脚等,使之符合出版社要求。内置的一些模板已经能导出很漂亮的电子书或稿件格式。通过发布功能,可以直接将文章推送到WordPress博客或Medium平台,一键完成线上发布。Ulysses还支持iCloud同步,在MaciPhoneiPad上无缝衔接写作进度。优缺点总结:Ulysses的优势在于作为专业写作工具的方方面面:界面优雅干净,功能强大但不干扰写作;提供写作所需的几乎所有辅助功能(从灵感笔记到排版发布)​STORIES.ULYSSES.APP。它的多格式导出和发布是顶尖水平,对于需要投稿或出书的人非常实用。Ulysses通过MarkdownXL满足了很多标准Markdown无法直接表达的编辑需求,如批注、评论,这对严谨写作有帮助​HELP.ULYSSES.APP。劣势也正来自于它脱离标准Markdown:如果用户希望其文档能在别的Markdown编辑器中正常显示,Ulysses生成的标记需要额外转换​MARKDOWNGUIDE.ORG。如业内评论所说:“用UlyssesMarkdown会让人抓狂,很多语法不支持,还用非标准符号替代”​MARKDOWNGUIDE.ORG。这意味着Ulysses更适合专门在其生态内从写作到发布一条龙完成,锁定效应较强。另外,Ulysses没有Windows/Android版本,局限于苹果平台。并且自2017年起改为订阅制收费,每月约29.99)​ BEAR.APP ,免费版功能有限(不含同步、导出 PDF/DOCX、主题等​ BEAR.APP )。另外,Bear 不支持插件扩展,功能相对固定。对于写作极客来说,它缺少比如双向链接图谱等高级功能(不过 Bear 2 已开始支持部分双链)。总的说来,如果你处在苹果生态,喜欢简洁又漂亮的笔记工具,Bear 是非常理想的选择,尤其适合日记、散文、随笔这类创作和日常记录。它的设计哲学就是让用户“专注内容而非排版”,正吻合 Markdown 的初衷​ CREATE.XYZ 。 Ulysses 定位及特点: Ulysses 是 macOS/iOS 上知名的写作应用,专为职业作家和长文写作者打造。它采用自己的标记语言 Markdown XL 作为底层格式​ STORIES.ULYSSES.APP 。Markdown XL 扩展自标准 Markdown,增加了注释、脚注、评论等功能,以满足写作过程中的标注需求​ STORIES.ULYSSES.APP ​ HELP.ULYSSES.APP 。Ulysses 提供无干扰的写作环境和强大的组织管理(基于“片段”分章节),拥有目标字数设定、写作进度跟踪、语法检查等专业功能。同时,Ulysses 的导出发布能力极强:可自定义样式将文稿导出为 PDF、DOCX、HTML,甚至直接发布到博客平台(WordPress、Medium)等。作为所见即所得的代表,Ulysses 在编辑时几乎不让用户看到 Markdown 语法符号——粗体、斜体通过字体样式表示,链接以下划线高亮但不显示[ ](),图片则以缩略图显示。这给人一种“纯文本却富格式”的独特体验​ MARKDOWNGUIDE.ORG 。 使用体验: Ulysses 的界面与 Bear 有点类似:左侧文集组织,右侧编辑器。但 Ulysses 更侧重项目级管理,支持将多个文档组织成层级章节。写作时,没有可见的 Markdown 标记干扰,你直接输入内容并通过快捷键或菜单设置格式。如选中文本按 Cmd+B 就变粗体(但源文件实际用了 Markdown XL 特定标记)。值得注意的是,Ulysses 不完全兼容标准 Markdown 语法:​ MARKDOWNGUIDE.ORG 它不支持传统 Markdown 链接和图片语法,你需要用快捷菜单插入链接或图片;也不支持行内代码和围栏代码块的常规语法,而是通过菜单插入代码块元素​ MARKDOWNGUIDE.ORG 。这意味着,如果导出纯 Markdown,Ulysses 会使用自己的标记格式:比如用 ||删除内容|| 表示删除线,而非 ~~​ MARKDOWNGUIDE.ORG ;用 ::高亮:: 表示高亮,而不是 ==​ MARKDOWNGUIDE.ORG 。编辑时这些标记对用户是不可见的,看到的只是删除线效果或高亮底色。不过,这对希望在别的 Markdown 工具打开原文的人造成了麻烦(需要特殊转换)。Ulysses 非常强大的地方在于审稿和排版:它有注释和备注功能,可在文中插入仅作者可见的备注而不影响导出​ HELP.ULYSSES.APP ;支持设定每篇文章的写作目标(字数/字符),实时显示进度;提供多个窗口同时编辑不同章节。Ulysses 的导出样式可深度定制,你可以编写自定义样式表控制 PDF/DOCX的字体、间距、页眉页脚等,使之符合出版社要求。内置的一些模板已经能导出很漂亮的电子书或稿件格式。通过发布功能,可以直接将文章推送到 WordPress 博客或 Medium 平台,一键完成线上发布。Ulysses 还支持iCloud同步,在 Mac、iPhone、iPad 上无缝衔接写作进度。 优缺点总结: Ulysses 的优势在于作为专业写作工具的方方面面:界面优雅干净,功能强大但不干扰写作;提供写作所需的几乎所有辅助功能(从灵感笔记到排版发布)​ STORIES.ULYSSES.APP 。它的多格式导出和发布是顶尖水平,对于需要投稿或出书的人非常实用。Ulysses 通过 Markdown XL 满足了很多标准 Markdown 无法直接表达的编辑需求,如批注、评论,这对严谨写作有帮助​ HELP.ULYSSES.APP 。劣势也正来自于它脱离标准 Markdown:如果用户希望其文档能在别的 Markdown 编辑器中正常显示,Ulysses 生成的标记需要额外转换​ MARKDOWNGUIDE.ORG 。如业内评论所说:“用 Ulysses 写 Markdown 会让人抓狂,很多语法不支持,还用非标准符号替代”​ MARKDOWNGUIDE.ORG 。这意味着 Ulysses 更适合专门在其生态内从写作到发布一条龙完成,锁定效应较强。另外,Ulysses 没有 Windows/Android 版本,局限于苹果平台。并且自 2017 年起改为订阅制收费,每月约 5.99 或每年 39.99ULYSSES.APPSCALARLY.COM,价格相对高,对非职业写作者来说性价比不佳。如果你是专业作者、重度苹果用户,并能接受订阅费用,那么Ulysses是极为出色的写作环境;如果你更在意开放性和跨平台兼容,可能更愿意选择别的Markdown工具。StackEdit定位及特点:StackEdit是一款Web在线Markdown编辑器,不用安装软件,只需浏览器即可使用​STACKEDIT.IO。它特别适合希望随时编写Markdown并存储云端的人,以及团队线上协作场景。StackEdit提供两栏模式界面:左侧为实时渲染的富文本区域,右侧为源码区域,或反之排列​STACKEDIT.IO。它支持离线使用(PWA技术),即使断网也能继续编辑​STACKEDIT.IOStackEdit拥有丰富的Markdown扩展:支持GFMMarkdownExtraCommonMark等多种风格,并允许用户按需启用/禁用某些语法特性​STACKEDIT.IO。此外,它内置KaTeX数学公式渲染、MermaidUML图支持、以及ABC乐谱渲染等罕见功能​STACKEDIT.IOSTACKEDIT.IOStackEdit非常强调云同步和发布:可以绑定GoogleDriveDropboxGitHub仓库进行文档同步​STACKEDIT.IO;也可直接将文档发布到BloggerWordPressZendesk等平台作为博文​STACKEDIT.IO。这些集成功能令其成为一个“云端Markdown工作台”。使用体验:在浏览器打开stackedit.io即可开始。它提供欢迎文档指导基本用法。编辑时,StackEdit会高亮Markdown语法,让文本格式一目了然​STACKEDIT.IO。右侧预览窗口保持与左侧源码滚动同步,确保编辑者随时看到最终效果​STACKEDIT.IO。同时,它也提供所见即所得按钮:顶部工具栏有加粗、斜体、插入链接等按钮,便于不熟悉语法的人操作​STACKEDIT.IOStackEdit的布局灵活,你可以切换只看预览或源码,或上下分割窗口,以适应不同屏幕​STACKEDIT.IO。在协作方面,StackEdit并非实时多人编辑,而是通过共享工作空间和版本合并机制:多人可共享访问同一个文档链接,不同时间的编辑在云端合并时StackEdit会提示冲突并帮助合并​STACKEDIT.IO。对于评论需求,它支持行内评论功能,类似Word/GoogleDocs的批注,在预览时可见评论内容​STACKEDIT.IOStackEdit作为浏览器应用,也可以安装为浏览器扩展随时使用。它支持将文章以MarkdownHTML等格式保存到本地。同时,它可以应用Handlebars模板输出结果,用于自定义发布格式​STACKEDIT.IO。总体来说,StackEdit在功能上几乎不输桌面编辑器,而且免除了安装和设备限制,甚为方便。优缺点总结:StackEdit的优势是在线即用、功能全面。对于无法安装软件或偏好云端的人,它是理想选择。它整合云端存储和发布平台,省去了手动复制粘贴的麻烦​STACKEDIT.IO。对Markdown扩展的支持也很丰富,数学公式、流程图、甚至音乐简谱都包含在内​STACKEDIT.IOSTACKEDIT.IO。再加上离线模式、评论系统,StackEdit足以满足绝大多数Markdown写作需求。劣势主要在于在线工具共通的问题:对浏览器依赖较强,如果浏览器不支持可能出现性能或兼容问题;协作虽然可行但不如真正实时同步那么直观。另外,StackEdit需要信任其云端,如果用于私密文档要考虑数据安全(可以使用本地浏览器存储避免上传)。而且StackEdit的界面相对偏英文,国内用户社区较小。综合来看,如果你想要零成本跨平台的Markdown编辑体验,并且重视云同步,StackEdit是非常值得一试的。尤其在没有权限安装软件的办公环境或使用平板、公用电脑时,用浏览器打开StackEdit就能继续你的Markdown写作。它真正做到了“WriteAnywhere”的理念。HackMD定位及特点:HackMD是一款主打实时协作的在线Markdown编辑器,被誉为“开发者的在线笔记本”(可类比GoogleDocs但面向Markdown)​HACKMD.IO。用户可以在浏览器中多人实时编辑同一文档,非常适合团队协作会议记录、头脑风暴、技术分享等。HackMD完全支持CommonMark标准和GFM扩展,并针对技术社区需求,内置了MathJax公式、Mermaid/GraphVizUML图、VegaLite数据可视化等高级功能​MARKDOWNGUIDE.ORG。它还有“SlideMode”,可将文档直接转换为演示幻灯片,以及“BookMode”将系列文档组织成在线书籍​HACKMD.IO。与StackEdit类似,HackMD也支持与云端服务集成,如GitHubDropbox等,方便导入导出和身份认证​MARKDOWNGUIDE.ORG。值得一提的是,HackMD有开源版本CodiMD(现名HedgeDoc),企业和个人可自建私有服务​MARKDOWNGUIDE.ORG。使用体验:HackMD的界面设计简洁实用。进入一个笔记,可以邀请他人通过笔记链接访问协作。所有协作者对文档的修改都会实时同步,每个人的光标位置和选区都有标注,与Google文档的实时协同类似​HACKMD.IO。编辑区域支持双栏模式或所见即所得模式切换。对于Markdown语法之外的扩展,HackMD提供了简单指令:例如在文档开头YAML中加入mathjax:true即可启用MathJax公式渲染;插入一个代码块并标记类型为mermaid就渲染出图表。这使得技术文档编写如鱼得水——你可以一边和同事编写说明,一边画架构图、写公式推导。HackMD还有评论模式,可针对文本段落发表评论,适合审阅讨论​STACKEDIT.IO。它内置了多种模板帮助新手上手,如会议记录模板、自述文档模板等​MARKDOWNGUIDE.ORG。分享方面,可以生成文档的只读公开链接,方便发布成果。安全性上,可以将笔记设为私有仅团队可见。HackMD还支持版本历史,可以查看和回滚过去的修改版本,保障协作编辑的可靠性。对于开发者,HackMD提供GitHub同步,可以将笔记内容推送到GitHub仓库,同步管理项目文档​MARKDOWNGUIDE.ORG。此外,其演示模式可以把Markdownremark.js渲染成幻灯片,方便技术分享时直接投影笔记进行讲解。优缺点总结:HackMD的最大优势就是实时协作+Markdown。在团队写作场景下,它提供了前所未有的效率:不必妥协为富文本编辑,在熟悉的Markdown中就能多人协同,加上对代码和公式的良好支持,非常契合开发、学术团队需求​MARKDOWNGUIDE.ORG。它功能完备,包括模板、版本控制、导出等,几乎是一站式的协同编辑方案。HackMD有免费计划,也有企业版可私有部署,这对注重隐私的组织很重要​MARKDOWNGUIDE.ORG。劣势方面,如果单人使用,HackMD相对StackEdit没有明显优势(反而StackEdit功能更侧重个人)。HackMD必须联网使用(除非自建服务),对网络依赖强。界面目前以英文为主,国内用户可能需要适应。总体来说,若有多人协同需求或者想要云端笔记和知识分享,HackMD是不二之选;纯个人本地写作则更偏向Obsidian/Typora之类。很多团队将HackMD用于文档初稿协作,然后再迁入正式知识库,可见它在协同编辑体验上的确出色​HACKMD.IO。(以上列举的各编辑器关键数据整理见下表)编辑器模式平台主要特点不足价格/开源Typora所见即所得Win/Mac/Linux无预览窗格,实时渲染;支持数学公式、表格、目录​TYPORA.IOTYPORA.IO;导出多格式​TYPORA.IO;界面简洁美观无插件扩展;需付费39.99​ ULYSSES.APP ​ SCALARLY.COM ,价格相对高,对非职业写作者来说性价比不佳。如果你是专业作者、重度苹果用户,并能接受订阅费用,那么 Ulysses 是极为出色的写作环境;如果你更在意开放性和跨平台兼容,可能更愿意选择别的 Markdown 工具。 StackEdit 定位及特点: StackEdit 是一款 Web 在线 Markdown 编辑器,不用安装软件,只需浏览器即可使用​ STACKEDIT.IO 。它特别适合希望随时编写 Markdown 并存储云端的人,以及团队线上协作场景。StackEdit 提供两栏模式界面:左侧为实时渲染的富文本区域,右侧为源码区域,或反之排列​ STACKEDIT.IO 。它支持离线使用(PWA技术),即使断网也能继续编辑​ STACKEDIT.IO 。StackEdit 拥有丰富的 Markdown 扩展:支持 GFM、Markdown Extra、CommonMark 等多种风格,并允许用户按需启用/禁用某些语法特性​ STACKEDIT.IO 。此外,它内置 KaTeX 数学公式渲染、Mermaid UML 图支持、以及 ABC 乐谱渲染等罕见功能​ STACKEDIT.IO ​ STACKEDIT.IO 。StackEdit 非常强调云同步和发布:可以绑定 Google Drive、Dropbox、GitHub 仓库进行文档同步​ STACKEDIT.IO ;也可直接将文档发布到 Blogger、WordPress、Zendesk 等平台作为博文​ STACKEDIT.IO 。这些集成功能令其成为一个 “云端 Markdown 工作台”。 使用体验: 在浏览器打开 stackedit.io 即可开始。它提供欢迎文档指导基本用法。编辑时,StackEdit 会高亮 Markdown 语法,让文本格式一目了然​ STACKEDIT.IO 。右侧预览窗口保持与左侧源码滚动同步,确保编辑者随时看到最终效果​ STACKEDIT.IO 。同时,它也提供所见即所得按钮:顶部工具栏有加粗、斜体、插入链接等按钮,便于不熟悉语法的人操作​ STACKEDIT.IO 。StackEdit 的布局灵活,你可以切换只看预览或源码,或上下分割窗口,以适应不同屏幕​ STACKEDIT.IO 。在协作方面,StackEdit 并非实时多人编辑,而是通过共享工作空间和版本合并机制:多人可共享访问同一个文档链接,不同时间的编辑在云端合并时 StackEdit 会提示冲突并帮助合并​ STACKEDIT.IO 。对于评论需求,它支持行内评论功能,类似Word/Google Docs的批注,在预览时可见评论内容​ STACKEDIT.IO 。StackEdit 作为浏览器应用,也可以安装为浏览器扩展随时使用。它支持将文章以 Markdown 或 HTML 等格式保存到本地。同时,它可以应用Handlebars 模板输出结果,用于自定义发布格式​ STACKEDIT.IO 。总体来说,StackEdit 在功能上几乎不输桌面编辑器,而且免除了安装和设备限制,甚为方便。 优缺点总结: StackEdit 的优势是在线即用、功能全面。对于无法安装软件或偏好云端的人,它是理想选择。它整合云端存储和发布平台,省去了手动复制粘贴的麻烦​ STACKEDIT.IO 。对 Markdown 扩展的支持也很丰富,数学公式、流程图、甚至音乐简谱都包含在内​ STACKEDIT.IO ​ STACKEDIT.IO 。再加上离线模式、评论系统,StackEdit 足以满足绝大多数 Markdown 写作需求。劣势主要在于在线工具共通的问题:对浏览器依赖较强,如果浏览器不支持可能出现性能或兼容问题;协作虽然可行但不如真正实时同步那么直观。另外,StackEdit 需要信任其云端,如果用于私密文档要考虑数据安全(可以使用本地浏览器存储避免上传)。而且 StackEdit 的界面相对偏英文,国内用户社区较小。综合来看,如果你想要零成本跨平台的 Markdown 编辑体验,并且重视云同步,StackEdit 是非常值得一试的。尤其在没有权限安装软件的办公环境或使用平板、公用电脑时,用浏览器打开 StackEdit 就能继续你的 Markdown 写作。它真正做到了“Write Anywhere”的理念。 HackMD 定位及特点: HackMD 是一款主打实时协作的在线 Markdown 编辑器,被誉为“开发者的在线笔记本”(可类比 Google Docs 但面向 Markdown)​ HACKMD.IO 。用户可以在浏览器中多人实时编辑同一文档,非常适合团队协作会议记录、头脑风暴、技术分享等。HackMD 完全支持 CommonMark 标准和 GFM 扩展,并针对技术社区需求,内置了MathJax 公式、Mermaid/GraphViz UML 图、Vega-Lite 数据可视化等高级功能​ MARKDOWNGUIDE.ORG 。它还有“Slide Mode”,可将文档直接转换为演示幻灯片,以及“Book Mode”将系列文档组织成在线书籍​ HACKMD.IO 。与 StackEdit 类似,HackMD 也支持与云端服务集成,如 GitHub、Dropbox 等,方便导入导出和身份认证​ MARKDOWNGUIDE.ORG 。值得一提的是,HackMD 有开源版本 CodiMD(现名 HedgeDoc),企业和个人可自建私有服务​ MARKDOWNGUIDE.ORG 。 使用体验: HackMD 的界面设计简洁实用。进入一个笔记,可以邀请他人通过笔记链接访问协作。所有协作者对文档的修改都会实时同步,每个人的光标位置和选区都有标注,与 Google 文档的实时协同类似​ HACKMD.IO 。编辑区域支持双栏模式或所见即所得模式切换。对于 Markdown 语法之外的扩展,HackMD 提供了简单指令:例如在文档开头 YAML 中加入 mathjax: true 即可启用 MathJax 公式渲染;插入一个代码块并标记类型为 mermaid 就渲染出图表。这使得技术文档编写如鱼得水——你可以一边和同事编写说明,一边画架构图、写公式推导。HackMD 还有评论模式,可针对文本段落发表评论,适合审阅讨论​ STACKEDIT.IO 。它内置了多种模板帮助新手上手,如会议记录模板、自述文档模板等​ MARKDOWNGUIDE.ORG 。分享方面,可以生成文档的只读公开链接,方便发布成果。安全性上,可以将笔记设为私有仅团队可见。HackMD 还支持版本历史,可以查看和回滚过去的修改版本,保障协作编辑的可靠性。对于开发者,HackMD 提供 GitHub 同步,可以将笔记内容推送到 GitHub 仓库,同步管理项目文档​ MARKDOWNGUIDE.ORG 。此外,其演示模式可以把 Markdown 用 remark.js 渲染成幻灯片,方便技术分享时直接投影笔记进行讲解。 优缺点总结: HackMD 的最大优势就是实时协作 + Markdown。在团队写作场景下,它提供了前所未有的效率:不必妥协为富文本编辑,在熟悉的 Markdown 中就能多人协同,加上对代码和公式的良好支持,非常契合开发、学术团队需求​ MARKDOWNGUIDE.ORG 。它功能完备,包括模板、版本控制、导出等,几乎是一站式的协同编辑方案。HackMD 有免费计划,也有企业版可私有部署,这对注重隐私的组织很重要​ MARKDOWNGUIDE.ORG 。劣势方面,如果单人使用,HackMD 相对 StackEdit 没有明显优势(反而 StackEdit 功能更侧重个人)。HackMD 必须联网使用(除非自建服务),对网络依赖强。界面目前以英文为主,国内用户可能需要适应。总体来说,若有多人协同需求或者想要云端笔记和知识分享,HackMD 是不二之选;纯个人本地写作则更偏向 Obsidian/Typora 之类。很多团队将 HackMD 用于文档初稿协作,然后再迁入正式知识库,可见它在协同编辑体验上的确出色​ HACKMD.IO 。 (以上列举的各编辑器关键数据整理见下表) 编辑器 模式 平台 主要特点 不足 价格/开源 Typora 所见即所得 Win/Mac/Linux 无预览窗格, 实时渲染; 支持数学公式、表格、目录​ TYPORA.IO ​ TYPORA.IO ; 导出多格式​ TYPORA.IO ; 界面简洁美观 无插件扩展; 需付费 14.99 买断​
    TYPORA.IO
    Mark Text 所见即所得 Win/Mac/Linux 开源免费; 实时预览+源码模式​
    GITHUB.COM
    ; 数学公式和 GFM/部分Pandoc支持​
    GITHUB.COM
    ; 导出HTML/PDF​
    GITHUB.COM
    开发中有bug; 无移动版 开源免费 (MIT)​
    GITHUB.COM
    Obsidian 混合(编辑+预览) Win/Mac/Linux/iOS/Android 双向链接+知识图谱; 插件丰富​
    OBSIDIAN.MD
    ; 本地存储; 支持 Mermaid/公式​
    ZETTLR.COM
    学习曲线略陡; 非开源, 商业增值服务 基础免费 (同步/发布需订阅)
    VS Code 源码+侧边预览 Win/Mac/Linux/Web 插件极其丰富; 内置预览&滚动同步​
    CODE.VISUALSTUDIO.COM
    ; 支持 KaTeX 数学​
    CODE.VISUALSTUDIO.COM
    ; 集成Git 需装插件完善功能; 界面相对复杂 免费 (开源)
    Joplin 源码+侧边预览 Win/Mac/Linux/iOS/Android 开源笔记软件; 云同步+E2EE​
    MARKDOWNGUIDE.ORG
    ; 支持待办复选框​
    SSPAI.COM
    ; 功能超丰富(剪藏/历史)​
    SSPAI.COM
    界面一般; 协作弱 免费 (开源)
    Zettlr 源码为主(部分渲染) Win/Mac/Linux 开源写作工具; 文献管理&引用​
    ZETTLR.COM
    ; Pandoc 集成导出; Mermaid/公式渲染​
    ZETTLR.COM
    稍耗资源; 初用需配Pandoc 免费 (开源)
    语雀 所见即所得(富文本) Web(有桌面客户端封装) 阿里云产品, 国内访问快​
    BLOG.CSDN.NET
    ; 多人实时协同​
    BLOG.CSDN.NET
    ; 知识库分类和权限; Markdown 友好​
    BLOG.CSDN.NET
    个性化弱; 依赖联网 免费(个人)/企业版订阅
    Notion 所见即所得(块编辑) Web/Win/Mac/iOS/Android 全能笔记+数据库; 模板多​
    BLOG.CSDN.NET
    ; 支持部分 Markdown 语法输入; 界面美观可拖拽 非完全Markdown格式; 国内访问慢 个人免费/团队8每人月​BLOG.CSDN.NETBear混合(部分渲染)Mac/iOS(Win/Android)界面优美;标签体系;跨笔记链接;多格式导出​BEAR.APP;iCloud同步​BEAR.APP平台局限;高级功能需订阅年8每人月​ BLOG.CSDN.NET Bear 混合(部分渲染) Mac/iOS (无Win/Android) 界面优美; 标签体系; 跨笔记链接; 多格式导出​ BEAR.APP ; iCloud同步​ BEAR.APP 平台局限; 高级功能需订阅 年29.99 订阅 (无免费同步)​
    BEAR.APP
    Ulysses 所见即所得 Mac/iOS 专业长文写作; 组织/目标进度; 导出发布强大; Markdown XL 标记注释等​
    STORIES.ULYSSES.APP
    非标准MD语法​
    MARKDOWNGUIDE.ORG
    ; 订阅贵 年$39.99 订阅​
    ULYSSES.APP
    StackEdit 源码+预览 Web 在线使用/离线支持; 云同步(Drive等)​
    STACKEDIT.IO
    ; 插入评论; 支持公式、Mermaid、乐谱​
    STACKEDIT.IO
    无实时协同; 需联网保存 免费 (Apache2.0开源)
    HackMD 所见即所得+预览 Web (可自建私有版) 多人实时编辑; 评论和模板​
    MARKDOWNGUIDE.ORG
    ; 支持 MathJax/图表​
    MARKDOWNGUIDE.ORG
    ; 幻灯片模式 需联网; 界面英文 基本免费/高级订阅或自建
    表:主流 Markdown 编辑器对比概览。【8】【21】【33】【47】【56】等 上述编辑器各有侧重和定位,可根据需求选择:个人离线写作推荐 Typora/MarkText/Obsidian,团队实时协作偏好 HackMD/语雀,学术论文写作 Zettlr 最佳,苹果生态用户钟爱 Bear/Ulysses,而需要跨平台与代码结合则 VS Code、Joplin 不可少。
  3. Markdown 编辑器对比分析
    从解析引擎、功能扩展、交互体验、导入导出等角度,对不同 Markdown 编辑器进行深入对比: 3.1 解析引擎与 Markdown 版本支持: 各编辑器对于 Markdown 语法的支持程度取决于其使用的解析引擎和遵循的标准。
    大部分现代编辑器采用 CommonMark/GFM 作为基础解析库,保证核心语法的一致性。如 Obsidian、VS Code、HackMD 都是基于 CommonMark 实现,再打开 GFM 扩展(表格、任务列表等)​
    EN.WIKIPEDIA.ORG
    。因此它们对基础语法和 GFM元素(如删除线, - [ ] 任务列表)支持良好。
    有些编辑器直接使用 开源解析库:Typora 早期用的是自研解析,后期也切换到了 GitHub 的解析库;Mark Text 明确指出支持 CommonMark 和 GFM 全规范,并兼容 Pandoc 扩展​
    GITHUB.COM
    。Joplin 使用 markdown-it 库,加上自己开发的插件实现了表格、脚注等扩展​
    MARKDOWNGUIDE.ORG
    。Zettlr 编辑器本身高亮 GFM,并在导出时借助 Pandoc 处理额外语法​
    MARKDOWNGUIDE.ORG

    Pandoc 本身不是编辑器,但一些编辑器集成了 Pandoc 作为后端(如 Zettlr)以支持更多 Markdown 扩展。这意味着这些工具几乎可以识别所有 Pandoc Markdown 语法,如定义列表、脚注、LaTeX宏等,即使编辑器前端不高亮,也能正确导出。
    特例是 Ulysses 和 Bear 这样自行实现语法的应用:它们对标准 Markdown 仅支持子集,并引入非标准标记。如 Ulysses 不支持Markdown方式插入图片/链接/代码块,必须用菜单操作​
    MARKDOWNGUIDE.ORG
    ;Bear 支持标准 Markdown 绝大部分语法​
    MARKDOWNGUIDE.ORG

    MARKDOWNGUIDE.ORG
    ,但默认未启用时部分需要手动开启(Bear 需在设置中启用 Markdown compatibility 模式​
    MARKDOWNGUIDE.ORG
    )。
    兼容性差异: 用户在不同编辑器间迁移时常遇到一些格式问题。例如 Ulysses 特有的 ||删除|| 标记在别的编辑器不会自动变删除线,需要替换为标准 ~~。再如 Obsidian 的 ![[image.png]] 内嵌图片链接语法在别处并不识别,要转换为标准 alt 格式。Notion 导出的 Markdown 有些内容(如页面内部的锚点链接)需要手工调整才能在典型 Markdown 编辑器中正确跳转。这就需要在工具切换时注意兼容模式或借助脚本批处理转换。
    总体而言,像 Typora、MarkText、VSCode、Obsidian 这类都遵循通用标准,解析引擎比较统一,写出的 Markdown 文档具有良好的通用性。在意兼容性的用户,可以选择这些通用型编辑器,并尽量使用主流语法,避免依赖某款软件特有的标记。 3.2 插件系统与扩展能力: 编辑器的扩展能力很大程度取决于是否支持插件和自定义主题:
    插件扩展: Obsidian 是插件最丰富的 Markdown 编辑器,上千个社区插件实现了从日历、思维导图到AI助手等各种功能​
    OBSIDIAN.MD
    。只需在设置中启用并安装插件,就能为 Obsidian 增添新功能,形成自己专属的笔记工作流。Joplin 近两年也引入插件系统,如悬浮预览、Todo统计等插件可安装。VS Code 则本身是编辑器平台,有大量 Markdown 相关插件在其 Marketplace,例如 Markdown All in One、Mermaid Preview、Table Formatter 等,选择丰富。​
    SSPAI.COM
    这些插件可以实现自动生成目录、粘贴图片上传、智能排版等特性,极大提升 VS Code 编辑 Markdown 的体验。相反,Typora、Mark Text、Bear、Ulysses 这类不支持第三方插件,功能扩展只能靠官方更新和用户自行脚本处理。这意味着在可玩性上,它们不如有插件生态的工具。例如,有用户想在 Typora 增加大纲折叠功能,因为无插件支持,只能等待官方决定是否实现;而 Obsidian 用户可以装一个 Outline 插件立即获得侧边大纲并支持折叠导航。
    主题与界面定制: 大多数编辑器允许更换主题外观,但实现方式不同。Typora、Obsidian、Zettlr 提供了用自定义 CSS 定制主题的途径​
    TYPORA.IO

    ZETTLR.COM
    ——用户可以完全掌控界面样式(颜色、字体、排版等)。社区也产出了众多第三方主题可直接套用。VS Code、Joplin 则有主题插件或内置多套主题供切换。相比之下,Bear、Ulysses 仅提供官方设计的几款主题(Bear Pro 有 28 款​
    BEAR.APP
    ),无法自行定制,这对于喜好个性界面的用户来说稍显局限。不过封闭环境也确保了这些应用风格的一致性和设计感。
    额外组件集成: 插件机制之外,一些编辑器通过配置调用外部程序。如 Zettlr 调用 Pandoc 来导出多格式,如果用户未安装 Pandoc,则相关导出功能受限,需要按文档说明安装并配置路径。Obsidian 如需导出 Word 文档,也需要安装 Pandoc 和相应插件。再如希望在 Obsidian、Joplin 中实现更漂亮的数学公式或图表,一般借助外链CDN的 MathJax、Mermaid 脚本。因此,不同编辑器在高级功能上有时需要额外组件支持,配置上需注意。例如 Typora 自带 KaTeX 和 Mermaid,无需额外配置即可用公式和流程图;而 VS Code 需要在 Markdown 设置里启用 MathJax 才能渲染公式​
    CODE.VISUALSTUDIO.COM
    。用户在选型时可根据自己技术能力和折腾意愿考虑:想要开箱即用选 Typora/Bear这类集成好的;不介意动手配置则 Obsidian/VSCode 等可通过插件和第三方工具实现更多能力。
    3.3 交互体验(所见即所得 vs 纯文本): 编辑器在人机交互上的差异直接影响使用效率和舒适度:
    格式直观性: 所见即所得 (WYSIWYG) 编辑器让用户无需考虑语法符号,所见即所得型如 Typora、Mark Text,可以在不显示 ** 的情况下就把文字加粗​
    TYPORA.IO
    。这对于不熟悉 Markdown 的用户来说降低了门槛。同时,WYSIWYG 模式在排版复杂内容(如表格、图片)时更直观,用户可直接拖拽调整表格尺寸​
    TYPORA.IO
    或图片大小而不必操作字符。但过度隐藏标记也有风险:某些时候用户想精准控制,比如确保列表缩进正确,而WYSIWYG可能自动处理缩进让人困惑。所以像 Obsidian 的折中方案,即实时预览模式下当前行显示源码符号,其余行渲染格式,提供了一种平衡。纯文本模式的编辑器(VS Code 等)则要求用户懂语法但提供了更明确的控制权。熟练 Markdown 用户常觉得纯文本模式“心中有数”,而 WYSIWYG 有时会暗中更改格式不好掌握。
    窗口大小对排版的影响: 在纯文本编辑器中,编辑窗口宽度可能影响一行显示的字数,但不会改变文件内容本身;而在所见即所得编辑器中,窗口宽度会触发内容的重排。如 Typora/Mark Text 中,窄窗口下表格可能自动折行或出现横向滚动条,这和最终导出宽屏查看时不同​
    TYPORA.IO
    。一些用户在小屏设备上编辑大表格会感到吃力,因为单元格内容换行显示。解决办法是在预览或导出前在大屏检查,或者使用编辑器的表格编辑模式(如 Typora 双击表格可弹出一个自由滚动的表格窗口)。再如代码块在窄窗口中显示的行数可能减少,需要滚动查看。为此 VS Code 等提供了软换行设置,窗口窄时自动折行显示代码而不改变源码。WYSIWYG 编辑器往往默认软折行,但折行后的样式(比如列表项缩进)在不同宽度下看起来会不同,用户需要理解这是视觉效果,不会影响导出的Markdown源。总的来说,窗口大小主要影响编辑体验,不会修改 Markdown 本身,但在调整窗口时要注意检查特殊格式的完整性。
    输入辅助与快捷键: 好的编辑器在用户输入 Markdown 符号时提供辅助,可极大提升效率。例如:自动补全闭合符号(输入 ** 后自动补全 **** 并将光标放中间​
    TYPORA.IO
    )、回车时自动延续列表或引用格式、Tab 键在列表项缩进/反缩进​
    TYPORA.IO
    等。这些细节 Typora、MarkText、Obsidian、VSCode(加插件)等都实现了。如果编辑器对这些支持不好,用户就得手动输入繁琐的格式,效率降低。另一个比较是快捷键:几乎所有编辑器都提供常用格式的键盘快捷键(加粗、标题提升等),但所见即所得编辑器会即时生效,而纯文本编辑器则插入符号。例如在 Typora Ctrl+3 会直接将段落变为三级标题格式(显示为大号文本);在 VSCode 用插件可实现类似行为。用户习惯之后,快捷键可以减少大量格式输入时间。
    大文件处理和性能: 交互体验也体现在当文档很大(几万字以上、含众多图片表格)时,编辑器的流畅程度。一些所见即所得编辑器(如旧版 Typora)在处理包含很多高分辨率图片的笔记时可能变卡,因为需要实时渲染图片;VS Code 则因为惰性加载预览,不会卡编辑但预览可能滞后。Obsidian 针对大文档有折叠功能,可以折起部分内容减轻渲染负担。Zettlr 等可将长文拆分为章节,分别编辑再导出汇总。性能也是体验重要部分:用户应根据自己文档规模选择,比如写小说、论文(长且结构复杂),可考虑 Obsidian/Zettlr 这类支持分片或大纲管理的;做简单记录,各种编辑器都足够胜任。
    3.4 导入导出与外部格式支持: Markdown 的优势在于易于转换为其他格式,不同编辑器在这方面支持程度不同:
    导出为HTML/PDF: 这是最基础需求,绝大多数编辑器都内置或通过插件支持。Typora 一键导出带目录PDF​
    TYPORA.IO
    ;Obsidian 内置 “导出为PDF” 功能;VS Code 可以打印为PDF(调用浏览器打印预览);Joplin/Bear 等也都有导出PDF选项​
    BEAR.APP

    MARKDOWNGUIDE.ORG
    。HTML 导出对编辑器更容易,很多纯文本编辑器没有UI按钮但可以复制预览的HTML或用命令行工具转换。
    导出为 Office 文档 (Word/Excel): 这一点各编辑器差异较大。Typora 提供直接导出为 .docx​
    TYPORA.IO
    (底层用 Pandoc 实现),Zettlr 调用 Pandoc 也能导出 docx,Ulysses 可以导出为 DOCX 且保持格式风格一致。Obsidian/VSCode 则没有内置 docx 导出,但可以通过 Pandoc 或插件实现。如果用户工作需要将 Markdown 转交给不使用Markdown的人(如领导只看Word),那么选一款能方便导出Word的编辑器会省很多事。另一方面,目前几乎没有 Markdown 编辑器支持导出为Excel表格(.xlsx),通常做法是从 Markdown 表格复制为TSV然后在Excel中粘贴,这种需求场景较少。
    导出为 LaTeX 或其他标记: Pandoc 驱动的编辑器(Typora、Zettlr 等)可以导出 LaTeX (.tex) 源文件​
    TYPORA.IO
    ,方便进一步整合进论文模板。某些学术工具(如兼容 MultiMarkdown 的)也能输出 TeX。OPML 是大纲文档格式,一些笔记软件支持导出 OPML 用于心智图等用途,Markdown 编辑器中有支持的并不多——大纲型如 UVue (Logseq) 之类支持OPML,主流编辑器很少涉及。如果需要,可找专用转换工具。
    批量导入导出: 如果用户已有大量笔记在别的格式,比如 Evernote (.enex) 导出包、HTML 文件夹等,一些编辑器提供了批量导入:Joplin 可以导入 Evernote .enex 并转为 Markdown;Obsidian/Notion 可以导入 Markdown 文件包(Notion 支持 Markdown/CSV 打包导入);语雀支持从 Markdown zip 包批量导入知识库等。这对于迁移很重要。相反导出方面,Notion/语雀偏封闭,但也提供一次性把整个空间导出 Markdown 的选项,以免用户数据被锁死。
    协同平台集成: StackEdit、HackMD 之类提供直接发布到博客或云笔记平台的功能​
    STACKEDIT.IO
    ,​
    MARKDOWNGUIDE.ORG
    这也是导出的一种形式,减少手动步骤。VS Code 则有插件可以直接将 Markdown 发布为 Confluence 页面或GitHub Wiki。选择编辑器时可留意有没有适合自己工作流程的集成功能,比如写完一篇Markdown一键就发微信公众号/博客,那相关集成会省时。
    3.5 注意事项(兼容性、Bug 与附加组件): 在使用不同编辑器时,还需留意以下实用经验:
    不同解析差异导致的显示问题: 前文提及Ulysses等特例,对于大部分遵循CommonMark的编辑器,少量实现差异也可能导致显示出入。例如标准Markdown中 hellohello 都表示斜体,但某些老解析器只认 *不认_,因此跨平台分享Markdown时尽量使用星号表示强调以确保最大兼容性​
    EN.WIKIPEDIA.ORG
    。再比如 Obsidian 的 ^footnote 脚注语法 vs GFM 脚注 [^1] 语法,如果在不支持的编辑器打开就只是一串文字。遇到这种跨工具查看乱码的情况,往往需要在源编辑器中转换为通用格式。例如 Obsidian 有导出为标准 GFM Markdown 的插件,可以把 [[链接]] 转换为 链接 以便在别处正确显示。
    常见 Bug 和解决: 许多编辑器在早期版本有过一些 bug,现在大部分已修复。例如 Typora 旧版有时列表嵌套会异常(需要空行隔开才能正确渲染),Mark Text 有报告说大文件时预览不同步。Obsidian 早期版本的实时预览模式曾有光标跳动问题。这些 bug 通常可以通过升级版本解决。如果遇到文本渲染不符合预期,先检查是否本身语法不符合目标标准,其次考虑是否编辑器 bug,可尝试在另一款编辑器打开验证。大多数情况下,不同编辑器之间显示差异源于语法支持差异而非 bug。
    公式渲染与符号冲突: Markdown 与 LaTeX 混用时,符号容易引起解析混乱。如果在不支持公式的编辑器打开包含符号容易引起解析混乱。如果在不支持公式的编辑器打开包含E=mc^2的文档,可能会把的文档,可能会把E 当成行内代码起始,从而错误渲染。解决方式是在公式字符串前后各加反斜杠转义 $ 或使用编辑器提供的“忽略公式”选项。类似地,表格里的管道符 | 在某些实现中要转义 | 才不会截断单元格。注意这些转义问题能提高文档跨环境兼容性。
    大纲/TOC 生成:许多编辑器插件可根据文内标题生成目录(TOC)插入文首,但不同实现语法不统一。Typora 使用 [TOC] 占位符​
    TYPORA.IO
    ;VSCode 插件使用 <!-- TOC --> 注释块。有的需要用户手动刷新,有的是实时更新。因此如果写作需要目录,最好选定一种工具生成后,转换到别的环境时当普通内容对待即可,或者干脆在输出格式里生成目录(如导出PDF时由Pandoc生成)。
    附加组件:Pandoc、TeX、Graphviz 等:为实现格式转换或特殊渲染,可能需要安装额外软件。Pandoc 如前述,在 Zettlr、Typora 中被利用,如果想导出更多格式又没有内置Pandoc,则用户可自行安装Pandoc并用命令行转换。LaTeX 安装在需要高质量 PDF 导出时派上用场,比如 Pandoc 调用 pdfengine=xelatex 会用本地 TeX 环境,未安装则报错。同理渲染流程图如使用 Graphviz (dot) 语法,在一些环境下需要Graphviz软件支持(Mermaid一般不需要,因为前端JS即可)。KaTeX vs MathJax:KaTeX更快但不支持一些高级 TeX宏,MathJax功能全但稍慢,编辑器选择哪种各异,Typora/Obsidian 用 KaTeX,HackMD 用 MathJax​
    MARKDOWNGUIDE.ORG
    。遇到公式渲染不出可检查是否功能开关或对应库加载问题。如果编写包含大量公式或引用文献的Markdown,为保险起见推荐使用 Pandoc 转换为 PDF/LaTeX,因为Pandoc对这些元素处理更成熟(需安装Pandoc和TeX)。
    总之,在使用 Markdown 编辑器的过程中,需对自己写作的 Markdown 文档有“心中有谱”,了解哪些语法是标准的,哪些是特定工具扩展。尽量使用标准语法以减少跨工具问题。当需要使用特定工具高级特性时,可以在完成后用工具自带导出转换成更通用的形式保存一份,避免后期难以脱离该工具环境。遵循这些,将能最大限度发挥 Markdown 平台无关的优势。
  4. 商业模式分析
    Markdown 编辑器在商业模式上主要分为三种:免费开源、一刀买断、订阅收费,各自对个人和企业用户的影响不同。 4.1 一次性买断制: 典型如 Typora(14.99终身)、iAWriter(不同平台各14.99 终身)、iA Writer(不同平台各1929买断),这类模式优点是用户付费后永久使用当前版本,并通常享受较长时间的免费更新。个人用户往往喜欢买断制,因为只需付费一次,无后续压力。开发商则通过不断吸引新用户购买或发布重大版本升级(可能收取升级费)来获取收益。Typora 就是在长期免费测试后转为买断付费,价格相对亲民,一次购买可在多台设备使用​
    TYPORA.IO
    。这使得众多习惯Typora的老用户顺利过渡,也为其带来资金支持持续开发。买断制对企业而言管理简单,购入软件即可离线部署使用,不必维持订阅关系。但买断制的劣势是后续盈利有限,开发者如果用户增长趋缓,维护动力可能下降。从趋势看,不少传统买断软件也在向订阅转型(如 Ulysses 就在2017年从买断转订阅)​
    STORIES.ULYSSES.APP
    。 4.2 订阅制: 许多强调跨平台服务或持续更新的应用选择订阅模式,如 Ulysses (
    5/)Bear(5/月)、Bear (1.49/月或14.99/年后来涨价至14.99/年后来涨价至29.99/年)​
    BEAR.APP
    、Notion 团队版 (8//)BLOG.CSDN.NET。订阅模式能提供持续收入,支持开发者长期改进服务。对用户来说,好处是通常多设备同步、云服务包含在订阅中(如BearPro包含iCloud同步,ObsidianSync单卖订阅),并且软件会持续获得新功能而无需额外付费。缺点是长年累月费用累计会远超买断价。如Ulysses年费约8/人/月)​ BLOG.CSDN.NET 。订阅模式能提供持续收入,支持开发者长期改进服务。对用户来说,好处是通常多设备同步、云服务包含在订阅中(如 Bear Pro 包含iCloud同步,Obsidian Sync单卖订阅),并且软件会持续获得新功能而无需额外付费。缺点是长年累月费用累计会远超买断价。如 Ulysses 年费约40,美区Mac App Store曾有用户评价“五年下来都可以买一台iPad了”表达对订阅的不满。个人用户常对订阅比较敏感,可能在寻找免费替代品;而企业用户对订阅接受度较高,因为可计入年度预算并享受官方支持服务。Notion、语雀等偏团队协作的平台采取 Freemium + 订阅,很大程度上因为团队愿付费以获得高级权限和存储,而个人能用免费版推广口碑。 4.3 免费开源模式: 这在 Markdown 编辑器中也很常见,如 Mark Text、Joplin、Zettlr、HedgeDoc (HackMD社区版) 等完全免费开源,通过开源社区和捐赠赞助维持​
    GITHUB.COM
    。优点显然是用户零成本使用,并且透明可控,没有功能阉割。对于个人用户,这是极大利好,可以不花钱获得强大工具。不过开源项目的开发进度和寿命取决于维护者兴趣和社区活跃度,有时可能更新缓慢或中途停止(也有很多长期繁荣的例子,如 Joplin 一直高频更新)。企业用户使用开源软件需考虑支持和责任问题——没有官方售后,但代码可自控,必要时可内部修改。这方面,企业往往会偏好购买有服务支持的商业产品,除非有能力自维护开源项目。值得关注的是,一些开源项目也探索商业变现方式,比如 Joplin 推出付费的官方云同步服务(Joplin Cloud),Obsidian 本身免费但提供付费的 Publish 和 Sync 服务。这是一种混合模式:核心应用开源/免费,通过周边增值服务盈利。这种模式对个人非常友好(可自选是否花钱享受云服务),对开发团队也提供了可持续收入。Obsidian 就是成功案例:软件免费不限功能,对个人用户形成巨大吸引力,随后部分付费用户订阅同步或购买商业许可证,从而支撑开发​
    BLOG.CSDN.NET
    。 下面是不同编辑器的商业模式对比和价格概览:
    Typora: 买断 14.99TYPORA.IO(不含税),可用3台设备,未来小版本免费升级。Beta期间免费,2021正式版开始收费​SSPAI.COM。价格自发布以来稳定,未来可能根据通胀略调整,但总体保持一次购买模式。对个人而言,一次付费即可长期使用,非常划算;对公司,购买也简单直接(不过Typora协议要求商业使用也需购买,每席价格相同)。Obsidian:个人免费,商业使用需购买一次性商业许可证(14.99​ TYPORA.IO (不含税),可用3台设备,未来小版本免费升级。Beta期间免费,2021正式版开始收费​ SSPAI.COM 。价格自发布以来稳定,未来可能根据通胀略调整,但总体保持一次购买模式。对个人而言,一次付费即可长期使用,非常划算;对公司,购买也简单直接(不过Typora协议要求商业使用也需购买,每席价格相同)。 Obsidian: 个人免费,商业使用需购买一次性商业许可证 (50/人),以及可选的订阅服务:Obsidian Sync (8/)用于加密同步多端,ObsidianPublish(8/月) 用于加密同步多端,Obsidian Publish (16/月) 用于发布笔记为在线知识库​
    BLOG.CSDN.NET
    。此外还有Catalyst 护持者计划(25)算是捐赠获取内测版权限。Obsidian模式相当独特:核心功能免费开源(JS插件API开源但应用本体闭源),靠增值服务盈利,个人完全可以不花钱用得很爽。对于企业,如果不想订阅同步,可以自行用网盘同步免费版,但按规定应购买商业许可证支持开发。Obsidian定价策略被认为很好地平衡了大众用户获取和可持续盈利。MarkText:开源免费,无付费版本,但接受捐赠和赞助​GITHUB.COM。开发者通过Patreon/OpenCollective募集资金​GITHUB.COM。短期看,这样的回报难以和商业模式相比,但MarkText作为Typora免费替代品获得了大量用户。如果未来开发者资源不足,可能会考虑转为募资或商业化。但截至目前完全免费,对所有用户都是福音。Joplin:开源免费,资金来源主要是捐赠和JoplinCloud订阅(个人25起)算是捐赠获取内测版权限。Obsidian 模式相当独特:核心功能免费开源(JS插件API开源但应用本体闭源),靠增值服务盈利,个人完全可以不花钱用得很爽。对于企业,如果不想订阅同步,可以自行用网盘同步免费版,但按规定应购买商业许可证支持开发。Obsidian 定价策略被认为很好地平衡了大众用户获取和可持续盈利。 Mark Text: 开源免费,无付费版本,但接受捐赠和赞助​ GITHUB.COM 。开发者通过 Patreon/OpenCollective 募集资金​ GITHUB.COM 。短期看,这样的回报难以和商业模式相比,但 Mark Text 作为 Typora 免费替代品获得了大量用户。如果未来开发者资源不足,可能会考虑转为募资或商业化。但截至目前完全免费,对所有用户都是福音。 Joplin: 开源免费,资金来源主要是捐赠和 Joplin Cloud 订阅(个人 1.99/月起,有不同存储档位)。Joplin Cloud 针对想要官方一站式同步的用户,不想自搭配云盘的可以付费使用。企业或团队可以购买更高级计划或自行部署Joplin Server开源版本。这个模式让 Joplin 核心保持免费,又解决了开发者收入问题。价格方面,Joplin Cloud相对低廉,远低于 Evernote 等,相当于自愿付费支持项目。
    Notion: 个人版最初有免费和 4/月的高级选项,2020年后改为个人无限页免费(之前免费版限制1000块内容),以吸引大量个人用户​BLOG.CSDN.NET。团队协作版4/月的高级选项,2020年后改为个人无限页免费(之前免费版限制1000块内容),以吸引大量个人用户​ BLOG.CSDN.NET 。团队协作版 8/人/月,企业版另有定制价格。Notion 这一调整让个人用户零成本,用免费版也足够强大,从而在个人和教育市场占领优势;收入则来自企业团队订阅和大客户。历史上 Notion 定价策略随竞争而调整,未来可能进一步开放免费功能或者提高团队价。
    Bear: 免费版功能有限(不含同步和高级导出),订阅 Bear Pro 才能解锁全部特性​
    BEAR.APP
    。Bear Pro 价格早期为 14.99/年,现在已涨至14.99/年,现在已涨至 29.99/年(或 2.99/月)​BEAR.APP。学生可有优惠。涨价反映出维护开发成本和通胀影响,也表明Bear用户黏性较强愿意续订。Bear没有团队版,商业上更多定位个人用户。未来价格可能随软件重大版本(如Bear2.0发布)调整。目前看订阅仍能保证它稳定更新(Bear2.02023的大更新)。Ulysses:完全订阅制,自2017年起取消买断。价格为2.99/月)​ BEAR.APP 。学生可有优惠。涨价反映出维护开发成本和通胀影响,也表明Bear用户黏性较强愿意续订。Bear 没有团队版,商业上更多定位个人用户。未来价格可能随软件重大版本(如 Bear 2.0 发布)调整。目前看订阅仍能保证它稳定更新(Bear 2.0 是2023的大更新)。 Ulysses: 完全订阅制,自2017年起取消买断。价格为 5.99/月或 39.99/年​ULYSSES.APP。相比Bear贵一些,但包含MaciOS所有设备用,并支持苹果家庭共享。Ulysses有学生优惠价每6个月39.99/年​ ULYSSES.APP 。相比Bear贵一些,但包含Mac和iOS所有设备用,并支持苹果家庭共享。Ulysses 有学生优惠价每6个月 10.99​
    ULYSSES.APP
    。订阅制当年引发部分老用户不满,但也带来了稳定收入,Ulysses 这些年一直有更新。未来其价格可能随通货轻微上调(例如之前年价是39.99,现在部分地区已接近39.99,现在部分地区已接近49.99/年​
    TECHRADAR.COM
    )。对于专职作家,这个成本可以接受,相当于工具投资;但轻度用户通常不会为了写几篇文章而一直订阅。
    语雀: 个人版免费(有单用户知识库数量限制但基本够用),团队版按成员订阅收费,基础版每人每月 19 元人民币,专业版 49 元/月(来自语雀官网2023价),还有企业私有部署版等。语雀借鉴的是国内 SaaS 定价模型,对中小企业定价相对低廉以促进普及。历史上语雀个人版一直免费,团队价随着功能增加略有调整。未来可能推出更多增值服务(如与阿里云其他产品bundling)。
    HackMD: 公共版免费(公共笔记无限制),私人团队空间和高级功能收费。Pro 个人版 5/月起,团队版按用户计费(例如10用户团队5/月起,团队版按用户计费(例如10用户团队 45/月)。由于 HackMD 针对企业协作,其订阅价格与一般协作文档类似。Open source 版本 HedgeDoc 则免费自行部署。HackMD 商业策略是一方面吸引开源社区使用 HedgeDoc,另一方面提供托管服务盈利,这样不损口碑又有收入。
    4.4 各模式优劣比较: 对个人来说,免费和买断无疑更省钱,不少人会在Typora收费后转投MarkText等免费方案​
    BLOG.CSDN.NET
    。但也有人愿意为省心体验买单,如喜欢Bear的用户很多订阅多年,因为其打磨的体验确实好。​
    BEAR.APP
    订阅模式可能逼走价格敏感者,但能留下高黏性的核心用户并获取稳定现金流。对企业团队,订阅制由于可以提供发票和服务支持,更容易被接受(预算按年算),而免费开源虽然0成本但遇到问题缺少官方支持,要靠社区和自行解决。买断制对企业也友好(一次采购算CAPEX资本支出),但目前许多软件厂商更倾向订阅(OPEX运营支出)模式。未来趋势看,订阅已成为主流,但Markdown编辑器领域因为开源多,所以免费优秀产品仍大量存在。用户有充分选择空间:愿付费的有精良商业软件,不愿付的有开源社区软件。这种生态繁荣对Markdown本身的推广也有好处。 从历史价格看,Typora 从免费变收费是一个标志事件,说明纯免费的模式难以长期维系高质量更新​
    SSPAI.COM
    。Ulysses 转订阅虽然引发争议但后来用户接受度提高,也带动 Bear 等转为订阅。Notion 则反其道而行,通过免费开放个人版迅速圈占市场,再从企业盈利,这是“先补贴后收割”的模式。可以预见未来很多Markdown笔记类产品会基础功能免费,高级协同或AI功能收费,这是不少新兴笔记应用(如 Logseq、思源笔记等)的思路。对于个人用户,如果基本写作需求,其实完全可以在免费开源工具中满足;对于重度或专业用户,花费一定成本获取更好的服务也是值得的——关键是找到最匹配自己工作流和预算的工具。
  5. Markdown 在 AI 时代的应用
    在人工智能大模型(如 ChatGPT)蓬勃发展的当下,Markdown 悄然成为了 AI 生成内容的“通用格式”。许多 AI 对话和创作工具偏爱以 Markdown 来组织输出。这背后的原因、以及如何充分利用 Markdown 来处理 AI 内容,值得探讨。 5.1 AI 生成内容为何偏爱 Markdown:
    格式灵活且清晰: Markdown 可以通过简单标记表达段落、标题、列表、表格、代码、链接等常用格式,让 AI 模型在输出文本时能够直接嵌入格式指令,提高可读性。与其输出生硬的纯文本,模型用 Markdown 能更好地呈现逻辑结构。例如 ChatGPT 回答编程问题时会用```围住代码块,使得结果在支持 Markdown 的界面上高亮显示代码,这大大提升了阅读体验。
    通用标准易解析: Markdown 比 HTML 简洁很多,用少量符号就能表示丰富格式​
    CREATE.XYZ
    。对于 AI 模型来说,学习 Markdown 语法比 HTML 更容易掌握,并且输出 Markdown 也更不容易出错(HTML tag 未闭合之类错误)。很多AI接口(如OpenAI API)鼓励开发者让模型用 Markdown 格式输出,以便前端渲染。
    广泛支持的渲染环境: 从网页到App,Markdown 渲染支持非常普遍。因此AI给出 Markdown 格式结果,前端几乎可以直接显示,无需复杂转换。像 Github Copilot、ChatGPT Web界面等都内建 Markdown 渲染器。​
    CREATE.XYZ
    这进一步鼓励模型使用 Markdown 提供更好的用户体验。
    对 AI 模型训练有利: AI 在训练时爬取了海量互联网文本,其中包含大量 Markdown 文档(GitHub README、技术博客等)。模型习得了 Markdown 表达能力。在与人交互时,人们常在prompt要求中明确说明“请以 Markdown 格式输出”,模型就能很好地遵循。所以 Markdown 成了人与AI沟通格式的一种“契约”。有作者称Markdown是Prompt Engineering中的“无名英雄”,因为它为AI响应提供了明确的语义结构​
    HARTFORDCREATIVE.COM

    DEVBLOG.JOEYMIDORO.COM

    5.2 高效编辑和转换 AI 生成的 Markdown:
    当我们拿到AI生成的Markdown内容,如何进一步编辑、完善并转换为最终所需格式?
    选择合适的编辑工具: 如果AI输出较长且格式复杂,建议用专业Markdown编辑器打开进行检查和润色。所见即所得的编辑器有助于快速检查表格对齐、链接是否正确。举例来说,让 ChatGPT 生成了一份技术文档 Markdown,可以用 Typora 打开,边看渲染效果边修改错别字或补充内容,然后直接从 Typora 导出 PDF/HTML 以供发布​
    TYPORA.IO
    。又如 AI 生成了笔记内容,我们可用 Obsidian 导入归档,在其中添加wiki链接、标签纳入知识库。
    运用查找替换清理格式: 有时 AI 输出的 Markdown 存在不标准的地方,或我们想统一格式。可以用 VS Code 这类编辑器,利用正则替换批量处理。如把所有 “1.” 开头的有序列表项调整为 “1.” 统一缩进;去除AI常加的多余换行等。也可以借助 markdownlint 等工具检测不规范之处然后手改。这些步骤能让 AI 粗加工的内容变得更干净,更符合标准。
    合理分段和加标题: AI 有时倾向于输出长段落,我们应根据 Markdown 逻辑将内容拆分成段落和标题小节以提高可读性。这在 Markdown 编辑器中很方便,实现方法如在适当位置插入 ## 小节标题、空行等。AI 模型本身也能听从指示生成结构化内容(比如提示它使用 H2/H3 标题列出要点),我们编辑时可重点检查这些结构是否合理,必要时调整标题级别或顺序。
    善用 Markdown 特性丰富内容: Markdown 支持的一些特性可以人工后期添加,使AI内容更完善。例如,加入链接引用:相关论文;插入图像说明(将AI生成的图片链接插入 );使用表格整理数据(AI 可能输出为列表,人工整理成表格形式更直观);添加脚注对AI给出的专业术语做注解。由于 Markdown 语法简明,非技术人员也能很快掌握以上操作,这比直接改HTML容易太多。
    转换发布: 编辑完成的 Markdown 内容,可以用常用工具转换成最终发布格式:一般是 HTML(用于网页)、PDF(用于文档)或复制到富文本编辑器。在个人或内部场景,可以直接在 Obsidian、Notion 等环境查看 Markdown 结果;对外发布如博客,则可能需要转为 HTML 粘贴发布。很多平台(如知乎专栏、GitHub Pages)支持直接导入 Markdown,所以我们甚至无需转换,只要粘贴 Markdown 源即可。这体现了 Markdown 作为 AI 内容载体的优势:转换成本低,一套内容多用途。如有需要,把 Markdown 转为 PPT 也可以用 Pandoc 或 remark.js 等实现。总之,Markdown 格式让 AI 内容具备 “一次生成,多处使用” 的潜力。
    5.3 Markdown 在现代知识管理、协作写作、AI 数据中的作用:
    知识管理: 越来越多个人和团队采用 Markdown 来记录和管理知识(例如使用 Obsidian/Logseq 建立个人知识库,团队用基于 Markdown 的Wiki)。借助 AI 技术,可以对已有 Markdown 笔记进行智能分析、整理。比如有人将上千篇 Obsidian Markdown笔记接入 GPT 模型,实现快速问答和内容生成。这可能成为趋势:Markdown 作为知识的承载格式,AI 作为知识的处理工具。Markdown 笔记易解析,AI 可以轻松提取结构信息(标题、大纲)以理解文本脉络​
    TECHCOMMUNITY.MICROSOFT.COM
    。这使得 AI 辅助知识管理成为可能——例如用 AI 自动为新笔记打标签,或者根据 Markdown 日记生成摘要。
    协作写作: 在多人协作文档中,引入 AI 作为“参与者”已经开始实践。例如一些 HackMD 插件可以让 GPT-3 根据上下文补全文档段落,或检查 Markdown 语法错误。AI 能够以 Markdown 作为中间格式与人类协作:人类写一部分,AI 续写,并保持统一的 Markdown 格式。因为 Markdown 可读性高,团队成员在审阅 AI 产出时比较容易发现格式或内容问题。有项目提出用 AI 来自动整理会议记录:会议实时记录在 HackMD里,AI 模型读取 Markdown 内容后生成决议摘要再写回 Markdown。这展示了 Markdown 在协作+AI场景的灵活性。
    AI 训练数据管理: 在构建训练集或提示库时,Markdown 有时被用作标注格式。比如,在提示工程中,使用 Markdown 的分隔符来区分不同部分,可帮助模型更好理解任务​
    HARTFORDCREATIVE.COM
    。另外,有研究将文档先转换为 Markdown,再输入模型进行信息抽取​
    TECHCOMMUNITY.MICROSOFT.COM
    。因为 Markdown 去除了繁杂样式,只保留文本逻辑结构,这样模型提取关键信息更有效​
    DEVBLOG.JOEYMIDORO.COM
    。因此可以预见,在企业文档数字化、AI客服知识库搭建等应用里,先把资料整理为 Markdown 再让模型学习是一种可行方案。它相当于预处理,将多源数据标准化为统一简洁格式。
    总之,在 AI 时代,Markdown 作为人与机器都容易读写的格式,扮演了沟通桥梁的角色。对于AI生成内容,Markdown让模型输出更有条理,更便于人类后期编辑和发布​
    CREATE.XYZ
    。对于知识与数据,Markdown 提供了一个轻量统一的结构化表示,使 AI 可以更专注于内容语义而非排版噪音​
    TECHCOMMUNITY.MICROSOFT.COM
    。掌握并善用 Markdown,将有助于我们更高效地与 AI 协同创作、管理信息。可以说,Markdown 已成为 AI 时代的“隐形基础设施”,简单却威力无穷,在未来人机协作中扮演着重要的支撑角色。
    上面这是一份调研报告。但是不够具体。
    1.把markdown语法全部介绍清楚,基础语法至少有13个才对。要详细调研。
    2.每个markdown编辑器要介绍更加具体的对比,要细节到包含复制粘贴的区别。例如typora就无法粘贴替换选中的文字,只能把选中的文字都删除才能在原位置粘贴。其他的编辑器有没有这个使用细节呢?要调研对比。还有没有其他的使用细节区别呢?也要调研找。
    3.导入导出文件格式的具体细节也要介绍,甚至要描述清楚每个文件格式具体是干什么的。要对比哪些编辑器中为什么没有另外编辑器的几种格式,要调研说明详细原因。插入图片的格式也要每一个都介绍清楚,也要对比哪些编辑器中为什么没有另外编辑器的几种插入图片的格式,要调研说明详细原因。还有插入图片是不是就是永久保存在.md中了,是不是在路径中被删除了就没了,为什么不能永久保存在.md中,要详细调研介绍并说明原因。
    4.导入有的编辑器还需要安装其他软件。例如markdown如果要导入文件,必须得先安装pandoc。其他所有介绍的编辑器有没有什么需要安装什么插件或软件才能实现的功能?要详细调研,且详细调研说明原因。
    5.主题不同,正文和标题的字体样式和段落间距均不同。有哪些常见常用的主题,详细介绍。如何自定义主题,详细调研。
    6.不删除我提供给你的调研报告的文本,新生成的文本整理补充到原文本之中。
    7.由于内容太多,窗口内一次性展示不完,最好分章节按照最大token量的窗口展示。每完成一个章节,让我输入继续两字再继续展示

回答

你的要求涉及非常详细的 Markdown 语法、编辑器功能细节、导入导出格式、主题以及安装需求等多个方面。我会对每个部分进行深入调研,并将新的补充内容整理到你提供的原始报告中,确保完整性。

在正式开始调研前,我有几个确认点,以确保研究方向完全符合你的需求:

  1. Markdown 语法:你希望补充完整的 Markdown 语法,包括至少 13 种基础语法。我会详细描述其作用、不同标准的支持情况,并附带示例。
  2. 编辑器的细节对比:你特别关注 Typora 粘贴替换选中文本的限制,并希望调查其他编辑器是否有类似问题,或者是否有其他使用细节的区别。请确认你是否还关注其他具体的操作,例如快捷键、文本自动补全、撤销重做行为等。
  3. 导入导出格式:你希望详细介绍所有涉及的文件格式(例如 Markdown、HTML、PDF、DOCX、LaTeX 等),并解释不同编辑器为何支持或不支持某些格式。我还会包括图片插入方式,并探讨 Markdown 是否能永久保存图片,以及不同编辑器如何处理图片路径。
  4. 插件或额外软件依赖:你想知道各编辑器是否需要额外安装 Pandoc 或其他工具才能实现特定功能。请确认你是否也希望包括插件扩展能力,例如 VS Code 的 Markdown 插件、Obsidian 的社区插件等。
  5. 主题和自定义:你希望详细介绍常见主题、每种主题的字体样式、段落间距等,并调查如何在不同编辑器中自定义主题。
  6. 分章节输出:由于内容较多,我会按照最大窗口量分章节输出,每完成一个部分后,让你输入“继续”来继续查看下一个部分。

请确认以上调研方向是否符合你的预期,或者有无需要调整或补充的地方?

问题

符合我的预期

回答

好的,我将对 Markdown 语法、编辑器功能细节、导入导出格式、主题以及插件依赖等方面进行深度调研,并将所有补充内容整合到你的原始报告中。由于内容较多,我会按章节分批展示,每部分完成后等待你的“继续”指令再继续下一部分。

我会重点关注以下内容:

  • Markdown 语法:补充完整的基础语法(至少 13 种)及扩展语法,说明各标准的支持情况。
  • 编辑器使用细节:深入对比 Typora、Obsidian、VS Code 等编辑器,包括复制粘贴行为、快捷键、文本自动补全、撤销重做等。
  • 导入导出格式:详细介绍 Markdown 相关格式(如 HTML、PDF、DOCX、LaTeX),并解释不同编辑器支持与否的原因,分析图片插入方式及存储机制。
  • 插件及额外软件:分析 Markdown 编辑器是否需要额外安装 Pandoc、插件等才能实现某些功能。
  • 主题与自定义:研究不同 Markdown 主题的字体、间距等,并探讨如何自定义主题。

我会开始调研,整理完成后将章节化输出供你查看。

研究

✨ I’m noting that the user asks for a detailed Markdown syntax and editor analysis, covering syntax parsing, editor comparison, file formats, plugins, and customization, all segmented into chapters for clarity.

I’m comparing Typora and other Markdown editors, focusing on copy-paste behavior, shortcuts, autocomplete, undo/redo, and image handling methods, such as embedding or linking images.

🔍 Searched for Typora paste text issue

✨ I'm starting to see there's a problem with pasting text and another issue involving replacing selection text.

🌐 Read github.com

✨ Typora might have a bug where pasting text doesn't always replace selected text, especially if the selection spans a list. Other editors might not face this problem.

🌐 Read more from github.com

✨ I’m identifying differences between WYSIWYG and plain text editors, focusing on copy/paste replacement, text autocompletion, undo/redo, list indent logic, and shortcuts.

🔍 Searched for Typora mark text comparison

✨ Lists the unique Markdown syntax support of various editors like Typora, MarkText, Obsidian, and Joplin, noting their compatibility with GitHub Flavored Markdown (GFM) and other extensions.

Pixie is exploring the inclusion of example code blocks and images to illustrate Markdown syntax differences, ensuring a structured, formal, and easy-to-read format in Chinese.

🔍 Searched for Markdown standards comparison

✨ I’m thinking about the accuracy and relevance of the "Markdown 教程 - how to handle differences between editors (javatiku.cn)". It seems potentially very relevant, possibly in Chinese.

🌐 Read javatiku.cn

✨ I'm listing essentials like headings, paragraphs, line breaks, emphasis, lists, code, blockquotes, links, tables, task lists, strikethrough, footnotes, and math formulas for a cheat sheet.

🌐 Read linux.cn

✨ It's interesting to see that Markdown has various forms like GFM, CommonMark, and Markdown Extra, each adding features such as tables and footnotes.

🔍 Searched for GitHub Flavored Markdown footnotes support

✨ I'm covering the development of markdown standards, from original to GitHub Flavored, outlining features like footnotes, tables, and task lists, and noting differences among CommonMark, Markdown Extra, and Pandoc.

🔍 Searched for Markdown Extra footnotes tables

🌐 Read michelf.ca

✨ OK, let’s see. I’m piecing together how GFM 2021 Markdown Extra handles footnotes and tables differently from plain Markdown. This leads me to a thorough comparison.

Noting that Markdown's outline format is tricky, but Pandoc might simplify it with scripting. This approach should streamline the conversion process more efficiently.

🔍 Searched for Pandoc OPML

✨ I’m detailing how different markdown editors handle images, such as embedding as base64, keeping them as relative paths, or exporting them as separate files with links.

I’m noting that many markdown editors rely on Pandoc for conversion tasks, especially for exporting to PDFs and other formats.

I’m mapping out how editors like Typora, Obsidian, and VS Code allow users to adjust markdown themes, focusing on CSS customization and different typographic styles.

✨ Considering the maximum window limit, I’m addressing the importance of breaking down the response into manageable, interactive parts. This approach ensures a comprehensive and engaging format, avoiding large, overwhelming replies.

🌐 Read markdownguide.org

✨ I’m looking into the Markdown Guide to see if it compares flavors and supports extended elements like footnotes. It might not explicitly list these differences, though.

🌐 Read more from markdownguide.org

✨ I'm breaking down Markdown syntax features, including headings, paragraphs, line breaks, emphasis, lists, code, blockquotes, links, images, tables, task lists, strikethrough, footnotes, and math formulas.

Showcasing Markdown variants
I'm detailing differences in Markdown parsing, like how tables are treated in various flavors, footnotes, task lists, strikethrough, and math. Progress is steady as I compare parsing nuances.

🔍 Searched for Markdown flavors footnotes tables comparison

✨ I see the value in exploring syntax extensions in Markdown flavors. It aligns with understanding the landscape of Markdown's capabilities.

🌐 Read gist.github.com

✨ I'm analyzing Markdown variations, focusing on GFM and Pandoc. GFM includes tables and task lists, while Pandoc supports footnotes and inline math. Progress is being made!

🌐 Read tiiny.host

✨ I'm working through Typora's copy-paste issue, noting it might stem from its WYSIWYG nature. Comparisons to Mark Text, Obsidian, and VS Code are interesting, especially regarding list indentation and undo functionality.

I'm examining autocompletion in markdown editors, noting Obsidian and Notion for internal links, VS Code for local file paths, Typora for previous folders, and Joplin for note linking.

🔍 Searched for Markdown editors paste image support

✨ The results seem odd, possibly due to a search in user files. A mix-up with the source selection might be causing this.

🔍 Searched for Typora Mark Text image paste handling

✨ I’m looking at a Chinese source, "Use Images in Typora - Jianshu," to see if it covers YAML front matter config for images and possibly highlights differences.

🌐 Read gustaavv.github.io

✨ Considering Typora's image handling, such as copying images to folders and downloading remote images. Also, looking into VS Code's markdown.copyFiles.destination feature and potential Mark Text's similar capabilities.

🔍 Searched for Mark Text paste image folder

🌐 Read github.com

✨ OK, let me see. Joplin uses internal IDs for images, while Obsidian defaults to vault or subfolder storage, aligning with Typora's method.

🔍 Searched for Zettlr paste image

✨ Zettlr offers a choice of storing images either relative to the Markdown file or in an assets folder.

🔍 Searched for Bear export markdown images

✨ Bear's support for TextBundle, Pandoc's influence on export formats like docx and PDF, and online editors' limited export options. bijdrvousio

🔍 Searched for Typora export using Pandoc

✨ Typora incorporates Pandoc for importing and possibly exporting formats like docx or ePub, with some conversions likely built-in and others needing external Pandoc.

🌐 Read support.typora.io

✨ Typora offers PDF and DOCX options, while Obsidian excels with plugin extensibility, and VS Code shines with Markdown All in One for enhanced Markdown support.

🌐 Read thelinuxcode.com

✨ I’m thinking through various Markdown editors' support for footnotes and key plugins enhancing Markdown experience, such as VS Code's Markdown All in One and Obsidian's Advanced Tables. Noting the need for TeX for Pandoc in Zettlr.

🔍 Searched for Zettlr Pandoc installation

✨ I’m gathering info on common themes like GitHub Light/Dark and Dracula, and how editors like Typora and Obsidian allow tweaking fonts and spacing.

🔍 Searched for Typora custom theme CSS

✨ I'm noting that Typora, Mark Text, and Obsidian offer various methods for customizing themes, with Obsidian allowing easy theme application and CSS editing.

🔍 Searched for Obsidian custom CSS theme

🔍 Searched for VS Code markdown preview custom CSS

✨ I’m piecing together the Markdown syntax, focusing on 13+ features with examples and highlighting differences in GFM, Markdown Extra, Pandoc, and original CommonMark. Progressing through tables, code blocks, footnotes, and math formulas.

Research completed in 7m

回答

1. Markdown 基础语法解析
Markdown 提供了一套轻量级的标记语法,用于格式化纯文本。在这一节,我们将介绍至少 13 种常用的 Markdown 基础语法,包括:标题、段落、换行、强调(斜体/粗体等)、列表、代码、引用、链接、图片、表格、任务列表、删除线、脚注和数学公式。并说明不同 Markdown 标准(原始 Markdown、GFM、CommonMark、Markdown Extra、Pandoc 等)对这些语法的支持情况,辅以示例代码和渲染差异说明。

1.1 标题 (Headings)

Markdown 使用符号 # 标识标题层级:一个 # 表示一级标题,两个 # 表示二级标题,依此类推,最多支持六级标题。例如:

markdown
# 一级标题 ## 二级标题 ###### 六级标题

渲染结果:上述内容将分别转换为 <h1><h6> HTML 标签的标题文本。原始 Markdown 规范(John Gruber 的版本)和所有后续标准(如 CommonMark、GFM 等)均支持这种 ATX 风格的标题语法。此外,原始 Markdown 还支持另一种 Setext 风格的标题语法:使用下划线形式表示一级或二级标题。例如,一行文本下方紧跟一行 === 表示一级标题,--- 表示二级标题 linux.cn linux.cn 。CommonMark 和 GFM 也兼容这种语法。不过,需要注意 Setext 风格的下划线可能与表格语法产生歧义(见后文表格部分)。

标准支持差异: 标题语法是所有 Markdown 方言的核心功能,在原始 Markdown、CommonMark、GFM (GitHub Flavored Markdown) linux.cn 、Markdown Extra 等各版本中均受支持且行为一致。

1.2 段落与换行 (Paragraphs & Line Breaks)

段落: Markdown 中通过一个或多个空行来分隔段落。连续的文本行在渲染时会合并为一个段落。如果希望在 Markdown 中另起一段,需要在前一段末尾插入一个空行,然后开始新段落。

换行: 在段落内部强制换行有两种方式:

  • 硬换行 (Hard Break): 在行尾添加两个或更多空格,然后换行,Markdown 渲染时会在该处插入换行标记 <br>。例如:第一行结尾 ␣␣(两个空格)然后回车,下一行将另起一行。
  • 软换行 (Soft Break): 直接换行但不加空格。在大多数 Markdown 实现中,这种换行在渲染时会被视为空白并合并到同一段落。也就是说,软换行不会产生实际的换行效果,只相当于在输出中插入一个空格。CommonMark 规范明确区分软换行和硬换行 linux.cn

原始 Markdown 的设计中,一个换行符通常不会产生新的 <br>,需要使用硬换行(两个空格)来明确指示 linux.cn 。GitHub Flavored Markdown (GFM) 在早期曾放宽换行规则(将单个换行也渲染为 <br>),但在正式规范化后,GFM 基于 CommonMark,实现上仍要求明确的硬换行标记 linux.cn

标准支持差异: 所有 Markdown 方言均支持上述换行规则,但对于是否将单个换行视为 <br> 存在差异。一些平台(如早期的 GitHub 评论渲染)会将单一换行也渲染为换行,但CommonMark/GFM 规范要求严格遵循两个空格规则 linux.cn 。在兼容性考虑上,建议使用两个空格或显式的 <br> 标签来确保换行在各平台渲染一致。

1.3 强调 (Emphasis)

强调主要包括斜体和粗体,还有粗斜体等组合形式:

  • 斜体:将文本包裹在单个 *_ 中。例如 *斜体*_斜体_ 渲染为斜体。
  • 粗体:将文本包裹在两个 **__ 中。例如 **粗体**__粗体__ 渲染为粗体。
  • 粗斜体:将文本包裹在三个强调符号(例如 ***文本***)渲染为同时粗体和斜体。

以上语法在原始 Markdown 就已定义,所有标准变体对此支持一致。需要注意避免符号与单词直接相连的歧义情况,一般来说,在符号外围加空格可以避免解析错误。CommonMark 规范详细规定了这些符号的识别规则,使解析行为统一 linux.cn

标准支持差异: 斜体和粗体属于 Markdown 基础语法,各版本(原始、CommonMark、GFM、Extra、Pandoc 等)均支持。不存在不支持粗斜体的主要实现。但不同实现对一些边界情况(如下划线强调与强调符号嵌套等)的处理有轻微差异,CommonMark 通过明确规则解决了这些歧义 linux.cn

1.4 列表 (Lists)

Markdown 支持无序列表和有序列表,以及嵌套列表:

  • 无序列表: 使用 -*+ 作为项目符号。例如:
    markdown
    - 项目 1 - 项目 2 - 子项目 2.1 * 项目 3
    三种符号效果相同,渲染为 HTML 的无序列表 <ul><li>…</li></ul>。缩进两个或四个空格可以创建嵌套的子列表。
  • 有序列表: 使用数字后跟英文句点和空格。例如:
    markdown
    1. 第一项 2. 第二项 1. 第二项的子项 3. 第三项
    渲染为有序列表 <ol><li>…</li></ol>。列表项编号在输出时不一定按输入保留序号,通常各实现会自动按顺序编号。

原始 Markdown 对列表的支持比较基础,但规则略有歧义(如列表项和段落之间空行的要求等)。CommonMark 对列表的解析更严格一致。GFM、Markdown Extra 等基本沿袭 CommonMark 列表规则。此外,一些扩展支持任务列表(Task List,下述第 1.9 节详述)。

标准支持差异: 无序/有序列表作为基本特性,各标准均支持。不过 Markdown Extra 针对列表增加了一些扩展,如定义列表(Definition List,下文1.8节脚注提及)等 tiiny.host 。任务列表则并非原始 Markdown 所有,实现差异见后。总体而言,普通列表在主流实现间无差异。

1.5 代码 (Code)

Markdown 中可以表示行内代码和代码块:

  • 行内代码 (Inline Code): 使用反引号 ` 包裹代码片段。例如:这是 `inline code` 示例。渲染结果是在行内以等宽字体显示代码片段,并转义特殊字符。

  • 代码块 (Code Block): 有两种方式:缩进式和围栏式。

    • 缩进式代码块: 在每行代码前缩进 4 个空格或1个制表符。原始 Markdown 就支持这种方式,将缩进的文本整体渲染为 <pre><code> 中的代码块。需要在前一段落之后有一个空行以区分。
    • 围栏式代码块: 使用一组连续的反引号 ````` 或波浪号 ~~~ 将代码包裹起来。例如:
      markdown
      \`\`\` 多行代码内容 \`\`\`
      围栏代码块无需缩进,能够直观地包含多行代码。通常还可在开头反引号后指定语言标识实现语法高亮,例如 ```python markdownguide.org 。围栏语法并非原始 Markdown 的一部分,它是在后来的 Markdown Extra 和 GFM 等扩展中引入的 michelf.ca 。CommonMark 和 GFM 现已正式支持围栏代码块 michelf.ca 。Markdown Extra 也支持使用波浪号或反引号围栏代码,并允许在围栏行末添加类名用于指定语言或添加自定义属性 michelf.ca

例如,以下 Markdown 将创建一个语法高亮的代码块:

markdown
```js function greet() { console.log("Hello Markdown"); }
text
在支持语言标记的渲染器上,将以 JavaScript 代码高亮显示。 **标准支持差异:** 行内代码和缩进代码块为原始 Markdown 基础功能,所有实现均支持。围栏代码块在 CommonMark、GFM、Markdown Extra、Pandoc Markdown 等**扩展 Markdown**中受支持 [michelf.ca](https://michelf.ca/projects/php-markdown/extra/#:~:text=Markdown%20Extra%20introduced%20a%20syntax,For%20instance) 。Pandoc 等实现还允许围栏代码块指定更多属性(如 `{.html #id}`) [michelf.ca](https://michelf.ca/projects/php-markdown/extra/#:~:text=The%20class%20name%20is%20placed,use%20a%20special%20attribute%20block) 。原始 Markdown (以及未扩展的实现) 若遇到围栏语法,会将反引号视为普通字符,从而在输出中保留原文或产生不期望的结果。如今主流编辑器几乎都支持围栏代码块,但如果目标环境是老旧或简化的解析器,应当回退使用缩进代码块保证兼容。 #### 1.6 引用 (Blockquote) 段落前加 `>` 符号表示引用一段文字。单个 `>` 应用于一个段落,可跨越多行;在每行或每段前添加 `>` 实现包含多段的引用。引用可以嵌套,通过在 `>` 后继续添加 `>`(或缩进)表示更深层的引用层级。 示例: ```markdown > 这是一个引用的段落。 > > 引用可以跨多个段落,并且可以嵌套引用: >> 嵌套的引用内容。

渲染效果:上述将生成一个 <blockquote> 区块,包含所引用的内容。嵌套的 >> 则会产生嵌套的 <blockquote>。引用内部也可以包含其他 Markdown 元素,比如标题、列表等,只需在每行前都保持 > 前缀。

标准支持差异: 引用语法在所有 Markdown 实现中都支持,表现基本一致。CommonMark 明确了引用可以不必每行都带 >,只要段首有 > 即可包含整个段落 linux.cn 。少数解析器对于引用内换行的处理有细微差异,但整体兼容性问题不大。

1.7 链接与图片 (Links & Images)

Markdown 使用类似的语法插入超链接和图片:

  • 链接: 格式为 [链接文本](目标URL "可选标题")。例如:[Markdown指南](https://www.markdownguide.org "Markdown Guide") 会将“Markdown指南”四个字链接到指定网址,并在鼠标悬停时显示标题“Markdown Guide”。还支持引用式链接:先在正文定义 [文本][标签],然后在文档其他地方写 [标签]: 目标URL "标题",多次重复使用该标签引用同一链接。 markdownguide.org

  • 图片: 格式与链接类似,只是在前面加一个感叹号 !。如:![替代文本](image.png "图片标题") 会插入一张图片。替代文本用于图片无法显示时替换内容或屏幕阅读器。标题可选。 markdownguide.org 图片的路径可以是相对路径、本地文件系统路径或网络URL。

示例:

markdown
这是一个链接:[点击这里](https://example.com "示例链接")这是一个图片:![示例图片](./images/pic01.png "图片说明")

渲染结果:将显示一个可点击的“点击这里”超链接,以及加载指定路径的图片。

标准支持差异: 链接和图片语法是原始 Markdown 核心特性,各版本支持一致。值得注意的是,一些实现(如 GFM)对自动链接有所扩展——在文本中直接出现裸露的 URL 或邮箱会自动转为链接,这在原始 Markdown 需通过尖括号 <http://example.com> 才能实现。GFM 和 CommonMark 都支持自动将 http://... 转换为链接 linux.cn 。图片语法方面,各实现的差异主要在于渲染环境(本地应用是否支持相对路径、本地文件显示等),语法本身无异议。Markdown Extra 与 Pandoc 允许为图片和链接添加额外的属性,例如通过在链接后用大括号写入 {#id .class} 来设置 HTML 属性 michelf.ca (这些属于扩展功能)。总体而言,链接/图片基本语法在各标准下表现相同。

1.8 表格 (Tables)

表格语法并非原始 Markdown 的内建功能,但在 GFM、Markdown Extra 等扩展标准中非常常见 linux.cn tiiny.host 。典型的表格语法使用管道符号 | 分隔列,使用一行由-和可选的:组成的分隔线来区分表头和表体,并可通过冒号控制对齐:

markdown
| 姓名 | 分数 | | :------- | ---: | | 张三 | 85 | | 李四 | ninety |

上例表示一个两列的表格。第一行是表头(“姓名”、“分数”),第二行的 :------- 表示第一列左对齐,---: 表示第二列右对齐 markdownguide.org 。接下来的每一行为一行数据。渲染结果为:

姓名分数
张三85
李四ninety

(“李四”的分数由于拼写错误ninety无法右对齐为数字,但这里仅作示例)

原始 Markdown: 对上述表格语法不会进行特殊处理,可能会将|视作普通字符。例如,一些解析器会将第二行的------识别为二级标题的下划线,把第一行当作一级标题文本,从而渲染出意外的结果(例如 <h2>姓名 | 分数</h2>)而不是表格。这正是当初增加表格扩展的原因:原始 Markdown 无法直接表达表格。

GFM: GitHub 风格 Markdown 正式将“管道表格”纳入规范扩展。从 2017 年发布的 GFM 规范开始,表格成为 GFM 对 CommonMark 的一个严格可选超集扩展 linux.cn 。因此在 GitHub、Typora、Mark Text、Obsidian 等采用 GFM/CommonMark 的工具中,上述语法渲染为表格。GFM 还支持表格中内容的左右/居中对齐(通过在分隔线两侧加冒号) markdownguide.org

Markdown Extra: 由 Michel Fortin 提出的 Markdown Extra 早在 GFM 之前就支持表格语法,语法基本类似(表头下的分隔线是必需的) michelf.ca 。Pandoc Markdown 也支持相同的管道表格语法,并且扩展支持更复杂的表格(如跨行/跨列或所谓“网格表格”),但一般的管道表格已足够使用。

标准支持差异总结:

  • 原始 Markdown & CommonMark (基础): 不支持表格语法。如果在此环境下使用表格标记,会被当普通文本处理,往往不会得到表格输出 linux.cn
  • GFM: 支持管道表格语法,包括对齐设置 linux.cn
  • Markdown Extra / MultiMarkdown: 支持表格 tiiny.host ,但要求严格的格式(例如表头和分隔线必需)。
  • Pandoc Markdown: 支持管道表格和更高级的表格语法。

示例差异:
下面是一段表格标记,在不同标准下的渲染对比:

markdown
| Feature | Support in GFM | Support in Original MD | |-----------|:--------------:|:----------------------| | Tables | &#10003; (支持) | &#10007; (不支持) | | Footnotes | &#10003; (部分支持) | &#10007; (不支持) |
  • GFM/Markdown Extra: 渲染为包含两行两列的表格,其中“✓”和“✗”表示支持与否。
  • 原始 Markdown(不支持表格): 可能将第一行当作标题文本、第二行当作分隔线变成标题样式,从而渲染出错误的结果(例如把 “Feature | Support in GFM | Support in Original MD” 变为一个二级标题)。

总之,若需要在所有平台兼容,需确保所用平台支持表格语法,否则可以用纯文本格式表达表格或使用 HTML <table>。不过目前大多数流行编辑器均已支持表格扩展语法 linux.cn

1.9 任务列表 (Task Lists)

任务列表是一种特殊的列表扩展,在列表项前使用形如 [ ][x] 标记项目前的复选框状态。例如:

markdown
- [x] 已完成的任务 - [ ] 未完成的任务

渲染结果会显示复选框(已勾选或未勾选)和任务描述。这一语法并非原始 Markdown 所有,但在 GitHub 等平台非常常用。GitHub Flavored Markdown正式将任务列表纳入扩展规范 linux.cn 。在 GFM 实现(如 GitHub 仓库的 README、Issues 评论等)中,上述语法会渲染为带复选框的列表项。许多现代 Markdown 编辑器如 Typora、Obsidian 也支持任务列表渲染。Markdown Extra 则不支持任务列表,因为其产生较晚且 Extra 未涵盖此特性。Pandoc 在其 Markdown 中提供任务列表扩展选项(需启用 task_lists 扩展)。

标准支持差异:

  • 原始 Markdown/CommonMark: 不支持,[ ] 会被视为普通字符。
  • GFM: 支持 linux.cn ,渲染为复选框列表。
  • Markdown Extra: 不支持任务列表(Extra 规范未定义此)。
  • Pandoc Markdown: 通过扩展支持(Pandoc 2.0+ 默认支持 GFM 风格任务列表)。
  • 其他编辑器: 普遍跟进 GFM 的实现,大多支持。例如 Joplin 也支持 - [ ] 语法将复选框集成到笔记中。

操作上的差异: 一些专用笔记工具(如 Obsidian、Typora)在预览或所见即所得模式下,会将任务列表渲染为实际可勾选的复选框 UI,用户点击可以更改 [ ][x] 等,这在纯渲染环境(如 GitHub 页面)通常是不交互的(只是静态显示复选框符号)。

1.10 删除线 (Strikethrough)

删除线通过将文本包裹在双波浪线 ~~ 中实现。例如:~~删除线文本~~ 渲染为加删除线的文本。这个语法扩展不属于原始 Markdown 核心。GitHub Flavored Markdown~~ 删除线纳入其扩展集合 linux.cn 。CommonMark 本身未包含删除线,但作为 GFM 扩展,它在多数实现中可用。Markdown Extra 传统上不支持删除线(Michel Fortin 的 Extra 并未定义该语法)。Pandoc Markdown 支持删除线(Pandoc 把它视为一个常见扩展)。

举例:~~已完成~~ 将显示为“已完成”。在不支持删除线的渲染器上,会原样输出“已完成”的波浪线符号。

标准支持差异:

  • 原始 Markdown/CommonMark: 不支持(CommonMark 扩展之外不解析 ~~)。
  • GFM: 支持 linux.cn
  • Markdown Extra: 不支持。
  • Pandoc: 支持(Pandoc 将 ~~ 解析为<del>标签)。
  • MultiMarkdown: 一些实现支持(如 MultiMarkdown 6+ 支持 ~~)。

目前,几乎所有流行的编辑器(Typora、VS Code 插件等)都支持删除线,要确保渲染兼容性,只需确认目标平台是否基于GFM或类似扩展。如果需要在不支持的环境(如某些旧论坛)的Markdown中表达删除线,可以退而求其次使用 HTML 标签 <del>文本</del>。但大多数情况下 ~~ 是安全的扩展标记。

1.11 脚注 (Footnotes)

脚注允许在文档中加入附加说明而不破坏主文本流。典型语法由两个部分构成:脚注引用脚注定义。在正文中使用[^标签]插入脚注引用标记,在文档的某处(通常是文末)添加对应的 [^标签]: 脚注内容 定义 michelf.ca michelf.ca 。渲染后,正文中的引用会变成上标编号链接,指向页面底部的脚注列表。

示例:

markdown
这是一个带脚注的句子[^1],可以有多个脚注[^note]。 [^1]: 第一个脚注的内容。 [^note]: 第二个脚注的内容,可以包含**格式**和[链接](https://example.com)等。

渲染效果:正文“这是一个带脚注的句子^1,可以有多个脚注^2。” ^1^2分别为可点击的上标,链接到底部列出的脚注内容 markdownguide.org markdownguide.org 。脚注内容本身可以包含段落、格式、甚至代码块等(需要在脚注内容换行处缩进以包含多段) markdownguide.org

支持情况: 原始 Markdown 并未包含脚注语法。脚注由 Markdown Extra 首创支持 michelf.ca ,Pandoc Markdown 和 MultiMarkdown 也长期支持此语法 tiiny.host 。CommonMark 尚未将脚注纳入核心规范,但很多 CommonMark 实现提供可选扩展;GitHub Flavored Markdown 起初不支持脚注,不过 2021 年 9 月 GitHub 宣布开始支持 Markdown 脚注语法 github.blog github.com (尽管 GFM 正式文档尚未更新,该功能已在 GitHub 平台实现)。

标准支持差异:

  • 原始 Markdown: 不支持,[^1] 会被当做普通文本显示。
  • Markdown Extra: 支持,以它为代表的许多实现采用相同脚注语法 michelf.ca
  • Pandoc Markdown: 支持脚注,并扩展支持行内脚注(直接使用 ^[脚注内容] 在正文中插入脚注,无需定义段落)。Pandoc 的脚注功能很强大,输出可以转换为 LaTeX 等格式的脚注。
  • GitHub Flavored Markdown: 过去不支持,但现在已支持基本脚注语法 github.blog 。这意味着在 GitHub 仓库 README、评论等处也可以使用上述 [^] 语法,点击脚注编号会跳转到底部显示参考内容。
  • CommonMark: 默认未包含,但有脚注扩展提案,实际许多CommonMark解析器已经实现。Obsidian、VS Code 插件、Typora 等都支持脚注 thelinuxcode.com

根据一份对流行编辑器的对比:VS Code 需要安装 “Markdown All in One” 插件才支持脚注渲染,Obsidian 和 Typora 原生支持,Zettlr 需在设置中开启,部分不支持(如 Leanote 当前不支持脚注) thelinuxcode.com 。总之,脚注虽非所有 Markdown 方言原生具备,但在支持 Markdown Extra 或 GFM 新扩展的环境中越来越常见。如果需要兼容不支持脚注的平台,可采取降级措施(例如在正文直接用括号注明参考内容)。

1.12 数学公式 (Mathematics)

Markdown 本身并未定义数学公式的语法,但在学术写作领域,许多 Markdown 变体引入了 TeX/LaTeX 数学公式的支持:

  • 使用美元符号 $...$ 包围的内容作为行内数学公式,渲染为类似 LaTeX 的数学模式。如:Euler’s formula: $e^{i\pi} + 1 = 0$ 将在渲染后显示为 eiπ+1=0e^{i\pi} + 1 = 0
  • 使用成对的美元符号 $$...$$ 包围的内容作为显示数学公式(独立成行、居中显示)。例如:
    markdown
    $$ E = mc^2 $$
    渲染为块级的数学公式。

需要注意,这里的数学语法实际上不是 Markdown 标准的一部分,而是由特定解析器或渲染器(通常借助 MathJax 或 KaTeX 库)添加的扩展。如:

  • Pandoc Markdown: 内建对 $...$ 行内和 $$...$$ 块级公式的支持 gist.github.com (Pandoc 甚至支持复杂的数学环境)。Pandoc 将这些公式转为适当格式(例如 LaTeX 或 HTML+MathML)。
  • GitHub: 原生不支持数学公式渲染。在 GitHub README 中写 $E=mc^2$ 只会原样显示而不会渲染为公式(因为安全及实现原因)。一些静态站点生成器会通过插件支持,或建议使用嵌入的数学图片。
  • MathJax/KaTeX: 很多编辑器(Typora、Obsidian、VS Code 扩展等)集成了 MathJax 或 KaTeX 来实时渲染 $...$ 中的数学内容。例如 Typora 可在偏好中开启“内联数学”和“块数学”解析;Obsidian 默认支持 LaTeX 公式渲染(使用 $ 语法,需确保笔记以 Markdown+MathJax 模式预览)。

标准支持差异:

  • 原始 Markdown/GFM/CommonMark: 未包含数学语法。如果没有额外支持,$ 会被当作普通字符。例如在标准 CommonMark 渲染器下,$E=mc^2$ 输出仍是“E=mc2E=mc^2”。
  • Pandoc Markdown: 支持,Pandoc 将 $ 符号识别为数学公式环境 gist.github.com
  • R Markdown:(基于 Pandoc)天然支持数学,用于科研文档非常方便。
  • Typora/Mark Text: 这类所见即所得编辑器内置 KaTeX,输入 $ 会自动触发公式模式渲染。
  • Obsidian: 默认启用(可在设置中关闭),使用 MathJax。在预览或阅读模式下渲染公式。
  • Joplin: 支持,通过集成 Katex 渲染数学。

示例: 在 Typora 或 Obsidian 中输入:狄拉克 delta 函数:$$\int_{-\infty}^{\infty} \delta(x)\,dx = 1$$,会立即看到渲染的数学公式。而在不支持数学的纯 Markdown 查看器中,则会看到原始的 $$…$$ 字符。

因此,如果目标平台不支持数学扩展,需要借助其他方案(如插入公式图片,或转换为 PDF 时由 Pandoc 处理公式)。但在需要公式的技术文档场景,Pandoc Markdown 是非常有力的选择,它支持公式、引用、书目等众多扩展 tiiny.host 。例如 Pandoc Markdown 可以很方便地将上述含公式的 Markdown 转为 LaTeX 或 PDF,同时正确排版数学符号。

1.13 其他扩展语法

除了上面列举的 13 种,Markdown 生态中还有一些扩展和改进:

  • HTML 支持: Markdown 原生允许嵌入 HTML 标签。例如 <kbd>Ctrl+C</kbd> 可直接在 Markdown 中使用,渲染时不被转义。大多数实现遵循这一约定,除非明确出于安全过滤。
  • 定义列表 (Definition List): Markdown Extra 支持定义列表语法:前一行为术语,下一行以冒号开头紧跟空格给出定义 markdownguide.org 。例如:
    markdown
    专有名词 : 其定义内容
    渲染为 <dl><dt>专有名词</dt><dd>其定义内容</dd></dl>。此语法在 GFM 中不支持,但 Pandoc 等实现支持。
  • 强调高亮 (Highlight): 一些实现(如 Pandoc、Typora)支持用双等号标记高亮:==文本== 渲染为带背景色高亮的文本。这并非通用标准。Typora 支持此语法,但 Mark Text 在早期版本不支持 linuxjournal.com 。这个高亮功能主要在 Pandoc 和部分编辑器中流行。
  • 下划线 (<u>): 普通 Markdown 将下划线用于斜体,不支持加下划线格式。但 HTML <u> 可直接嵌入,某些插件也提供类似 [u]文本[/u] 的扩展。
  • 表情符号 (Emoji): GFM 支持以 :smile: 这样的短代码插入表情符号,会转为相应的 Unicode emoji。许多编辑器也内置该功能,但原始 Markdown 无此特性。
  • YAML Front Matter: 在文档开头使用三条短划线包围的 YAML 区块可作为元数据(标题、作者等),这源于 Markdown 在博客平台的应用(如 Jekyll)。多数渲染器会将其视为元数据而非正文。Pandoc、Hexo、Jekyll 等支持 front matter。

综上,Markdown 经过多年的演化,有诸多变体和扩展功能。各标准对语法支持汇总: 原始 Markdown 仅涵盖基本的标题、段落、列表、代码、链接、图片、引用、水平分隔线等有限元素;GitHub Flavored Markdown (GFM) 基于 CommonMark 增加了表格、删除线、任务列表、自动链接等 linux.cnMarkdown Extra 扩展了表格、脚注、定义列表、缩写等 tiiny.hostMultiMarkdown 针对学术需求增加了脚注、表格、引用和元数据 tiiny.hostPandoc Markdown 几乎囊括以上所有扩展并加入数学公式、文献引用等功能 tiiny.host 。在实际使用中,必须了解所使用的平台或工具采用哪种 Markdown 方言,才能正确使用对应的语法特性 tiiny.host 。下一节将讨论主流 Markdown 编辑器对这些语法的支持和操作差异。


(第1部分完,请回复“继续”以查看第2部分:Markdown 编辑器对比分析 tiiny.host linux.cn

分享这个问答