从大学第一次写技术博客开始我就一直在找一种能让我专注于内容本身的写作方式。试过Word排版折腾半天换个电脑样式就乱试过网页版富文本编辑器复制粘贴时格式满天飞直到某天看到同事的README文件纯文本却渲染得整整齐齐我当时第一反应是这玩意儿到底是怎么做到的后来才知道那个看起来平平无奇的文本格式叫Markdown。这篇Markdown浅析不是教科书式的语法大全而是我这些年把Markdown当成日常写作主力之后沉淀下来的一整套真实经验。从语法细节到编辑器选型从渲染原理到各种诡异报错的排查过程再到Mermaid这类扩展语法怎么融入工作流我都会聊。如果你正在用Markdown但总被各种小问题卡住或者刚接触它想建立一套高效写法这篇文章应该能帮你少走不少弯路。1. 写文档这件事为什么绕不开Markdown很多人第一次接触Markdown都会产生一个疑惑用Word或者富文本编辑器直接排版不好吗为什么非要学一种带符号的写法这个问题我认真想过答案其实藏在一次真实的团队协作事故里。1.1 从一次团队文档事故说起几年前我在一个项目组里负责整理一份接口文档。当时用的是公司内部的在线文档平台界面和Word很像可以加粗、变色、调字号。我花了一下午把文档排版得漂漂亮亮结果第二天需求变了需要批量修改所有接口的请求参数。我复制粘贴了十几处却发现有几个地方的格式完全乱了粗体变成了普通文本列表缩进乱七八糟。团队成员接手修改时更是头疼每个人打开看到的样式都不一样有人用Windows有人用Mac渲染差异直接导致文档没法看。这件事让我意识到一个核心问题富文本格式看着方便但它的所见即所得是建立在编辑器帮你维护一堆隐藏样式之上的。这些样式一旦跨平台、跨软件、跨版本迁移就非常容易出问题。而Markdown的思路完全不同它把格式这件事用纯文本约定来表达你写**加粗**不管在哪里打开看到的都是同样的字符渲染器再把它变成加粗。格式的源代码和显示效果是分离的这天然就具备极强的可移植性和稳定性。也是从那次之后我开始认真把所有文档往Markdown上迁。README、接口文档、会议纪要、个人笔记、博客文章几乎全是.md文件。现在哪怕过去三五年打开当年的Markdown文件样式仍然稳定内容仍然清晰这种不过时的体验是富文本很难给的。1.2 Markdown的核心语法到底有多简单Markdown能流行除了稳定还有一大原因是它真的简单到几乎没有学习成本。我记得自己大概花了十几分钟就记住了所有常用语法之后基本不再查文档。功能语法渲染效果标题# 一级标题、## 二级标题各级标题加粗**加粗**加粗斜体*斜体*斜体行内代码codecode代码块独立代码块链接[文字](https://example.com)链接图片图片无序列表- 项目项目符号列表有序列表1. 项目编号列表引用 引用引用块表格列1这套语法覆盖了日常写作九成以上的需求而且约定极其符合直觉#越多标题越小-代表列表代表引用。用生活类比的话Markdown就像写作界的乐高用少数基础零件就能拼出各种结构而富文本编辑器像精装玩具拿到手很漂亮但想改装或者跨场地搬运就非常费劲。正因为简单Markdown才具备了比标记语言更高的身份——它成了一种写作习惯甚至是一种数据交换格式。所以我在后面谈各种编辑器、渲染器、插件时都建议你先想清楚一件事你的核心需求是写还是看。Markdown的优势永远在写这一端它把写作的门槛降到最低而看的效果则由不同的渲染环境决定。理解了这一点你就知道为什么同一个.md文件在不同工具里可能长得不一样这不是bug是生态的固有特性。2. 语法细节里那些不起眼的坑换行、表格、图片与目录语法本身很简单但真正用起来很多卡住你的问题都出在细节上。这一节我把这几年高频踩到的坑挨个列出来每一个都是热搜关键词的常客。2.1 换行一个回车在GitHub、Typora、VSCode里三种命运如果你曾经在GitHub上写README遇到过明明换行了显示出来却是一行的问题那么恭喜你踩中了Markdown最经典的换行坑。Markdown的换行规则和普通文本编辑器不一样。它把两个回车即一个空行视为分段而单个回车只代表行内空格。换句话说你写完一行后直接按一次回车在很多渲染器尤其是GitHub的GFM规范里下一行文本会接在上一行后面而不是另起一行。想要真正换行而不另起段落有两个办法在行尾加两个空格再按回车这是Markdown官方标准做法直接空一行让两段文字成为两个独立的段落。但坑就坑在不同编辑器的处理方式不一样。Typora属于比较宠用户的那种你在它里面单按一次回车视觉上就会换行导出时也会帮你处理好VSCode的预览插件两者都认而GitHub的渲染器更严格如果行尾没有两个空格又没有空行它就会把两段连成一段。我的实操建议很简单如果稿件将来要发布到多个平台比如GitHub、个人博客、公众号、知识库统一采用敲空行分段的写法不要依赖行尾加空格。因为两个空格在有些编辑器里看不见、容易误删而空行是任何渲染器都能正确识别的。2.2 表格与复制的血泪史Markdown表格语法在GFM里才被正式支持所以早期的Markdown根本不能画表格。现在大家用的都是竖线加横线的方式| 姓名 | 岗位 | 城市 | | --- | --- | --- | | 张三 | 后端工程师 | 北京 | | 李四 | 前端工程师 | 上海 |语法本身不复杂但在实际使用中最让人抓狂的是表格复制。你从Excel或者在线表格里复制一段数据直接粘到Markdown编辑器往往得到的是Tab分隔的纯文本而不是一个规范表格。反过来从Markdown渲染好的表格复制到Excel或Word也经常乱掉。我自己的做法是分场景处理从Excel到Markdown先在Excel里选中区域复制再到支持粘贴为表格的编辑器比如Typora里粘贴Typora会自动把Tab分隔的文本转成Markdown表格。如果用的是VSCode可以装一个Markdown Table Prettifier插件配合Paste操作也能快速整理。从Markdown到Excel不要直接复制渲染后的表格内容而是复制源码再转换。最省事的办法是用VSCode插件Excel to Markdown Table反过来也支持。表格内容过多时不建议手写太重。我一般先用在线工具比如Table Convert把CSV或Excel转成Markdown再粘贴进编辑器。表格复制的本质问题是Markdown表格是一种文本表现而Excel是一种结构化数据表现两者之间的转换需要经过解析和重组任何工具都只能做到尽可能智能。所以遇到复制乱掉时先检查原始数据是不是纯文本、有没有合并单元格、有没有特殊符号排除了这些转换成功率会高很多。2.3 图片引入与路径问题Markdown里插入图片用的是。听起来简单但图片地址怎么填这里面的门道非常多。本地相对路径这种写法适合项目文档放在Git仓库里图片和文档一起提交。优点是可移植、离线可看缺点是如果目录层级调整相对路径就失效了而且一旦图片丢失文档就缺图。本地绝对路径这种写法只适合本地个人笔记不推荐用于任何需要分享的文档。换台电脑路径就废了。在线URL适合博客、文章、官方文档图片托管在图床或对象存储上。需要注意如果图床域名失效图片就挂了。还有一个高频痛点是粘贴图片。Typora和很多编辑器支持直接截图粘贴并自动保存到指定文件夹。我一般会在文档根目录建一个assets文件夹编辑器设置里把图片保存路径指过去。这样整体结构是docs/ ├── 文章.md └── assets/ └── 文章-2025-01-01.png这个习惯让我在写长文、迁移Note库时省了很多事。另外如果你是写博客或者公共文档强烈建议图片统一走图床或对象存储并且图片命名不要用中文和空格比如架构图 v2最终.png这种命名在URL解析时很容易出问题。2.4 目录到底怎么生成还有一个被反复搜索的问题VSCode里怎么把Markdown文件的目录显示出来。这里要区分两个概念一是文件结构的大纲Outline二是文档内的TOC目录。VSCode大纲VSCode自带资源管理器下方的大纲面板默认会把Markdown的标题层级按大纲展示。如果你没看到可以在资源管理器面板的上方工具栏点击...勾选大纲。这里显示的是当前文档的标题树点击即可跳转但它只是编辑器辅助功能不会出现在导出文档里。文档内TOC目录如果你希望文章开头能有一个可点击的目录列表最方便的做法是安装插件Markdown All in One。它提供了Markdown All in One: Create Table of Contents命令可以按当前文档标题自动生成目录格式大致像- [1. 写文档这件事为什么绕不开Markdown](#1-写文档这件事为什么绕不开markdown) - [1.1 从一次团队文档事故说起](#11-从一次团队文档事故说起)这个目录本质上是Markdown链接列表在GitHub、VSCode预览、Typora里都能正常跳转。我用下来唯一的建议是文档写完后再生成一次TOC不要边写边生成否则标题一改目录就失效还得重新跑命令。3. 编辑器选型Typora、VSCode、Obsidian和他们都解决什么问题Markdown的编辑器数以百计每一款都在写和看之间做了不同的取舍。我先后用过多款这里聊聊它们的差异和适用场景。3.1 Typora极简的实时预览为什么让人上头Typora是我用了最久的一款桌面编辑器。它的核心理念是所见即所得但和传统的富文本编辑器不同它不是在一个Rich Text控件里改样式而是把Markdown源码隐藏起来直接渲染成最终效果。比如你在Typora里输入一个#加空格再输入文字界面会立即显示为一级标题而不是显示# 标题这种源码。当你把光标挪到那段文字上Typora又会临时显示出Markdown源码结构方便编辑。这种源码和渲染无缝切换的设计非常舒服写作沉浸感很强。Typora的适用场景是纯写作、博客排版、笔记整理。它的主题丰富导出PDF、HTML的效果很漂亮而且支持自定义CSS。不过它的编辑能力和程序员常用的代码编辑器相比弱一些如果你想在同一个界面里既写Markdown又跑终端或者看Git提交记录它就不合适了。3.2 VSCode 插件程序员手里的万能Markdown环境VSCode是程序员群体里最常见的Markdown编辑环境。它本身的Markdown预览已经很能用配合插件之后功能可以逼近甚至超过很多专业Markdown编辑器。我平时在VSCode里必装的几款插件Markdown All in One自动生成目录、快捷键、自动格式化表格是最值得装的一款我上面提到的目录生成就靠它。markdownlint检查Markdown语法规范比如标题层级是否跳跃、行尾空格是否符合规范。写公共文档时非常有用能提前发现很多潜在的渲染问题。Paste Image截图后直接粘贴成图片文件并自动插入Markdown图片语法。我配合assets文件夹使用工作流非常顺。Markdown Preview Enhanced增强预览效果支持导出HTML、PDF还能渲染Mermaid图、数学公式、PlantUML功能很全面。Excel to Markdown Table把Excel表格转换为Markdown表格解决我上面提到的表格复制问题。VSCode里还有一个很多人不知道的实用功能CtrlShiftV可以打开预览面板CtrlK V可以打开侧边实时预览。写文档时一边编辑一边看效果效率比单纯盲写高很多。同时VSCode的Outline大纲面板支持按标题索引和Markdown All in One的TOC生成互补。如果非要挑VSCode的缺点那就是初始配置成本比Typora高默认字体、主题、缩进都需要自己调一版。3.3 笔记场景的Obsidian和其他候选Obsidian是笔记场景的神兵利器。它的核心创新是双链Backlink可以在不同笔记之间建立关联形成一个个人知识网络。Markdown在这里不仅是格式更是知识库的基础单位。你可以用[[笔记名]]的方式引用其他笔记Obsidian会生成一个图谱视图所有笔记之间的引用关系可视化展示。我刚开始觉得这功能是花架子后来真用起来才发现当笔记量超过几百篇时双链能让知识检索从文件夹归类升级为内容关联这完全是两种使用体验。Obsidian的本体也是Markdown编辑器支持实时预览、表格、Mermaid配合社区插件几乎可以定制成任何你想要的样子。如果你愿意把大量个人笔记管理起来我建议优先考虑Obsidian。其他候选编辑器特点适用场景Notion数据库、页面嵌套块编辑器团队协作、知识库管理语雀结构化文档、小记团队知识沉淀Joplin开源、跨平台、端到端加密隐私敏感的个人笔记StackEdit在线编辑器支持同步临时写作、浏览器环境其实没有绝对最好的Markdown编辑器只有更适合你当前工作流的编辑器。我自己是Typora配Obsidian配VSCode三件套Typora写博客初稿Obsidian管理长期笔记库VSCode做代码和文档混合开发。三者之间的.md文件可以无缝互换这也是Markdown赋予我的最大自由。4. 渲染与转换Markdown如何变成HTML、Word和其他一切Markdown本身只是文本规范它真正发挥作用靠的是渲染器。这一节我会从底层逻辑出发讲清楚Markdown是怎么变成HTML、Word的以及近年来特别火的流式渲染到底在解决什么问题。4.1 Markdown渲染成HTML的底层逻辑Markdown渲染成HTML的过程可以拆成三步解析Parsing把Markdown文本按语法规则拆解成一棵抽象语法树AST标记出哪些是标题、哪些是段落、哪些是列表。转换Rendering把AST转成HTML结构比如# 标题变成h1标题/h1。样式StylingHTML结合CSS进行最终渲染。市面上的渲染器五花八门但核心都是这三步。前端领域常用的解析库有marked轻量、速度快适合简单场景。markdown-it插件生态好支持自定义规则适合需要扩展的场景。remark基于统一语法树unified生态适合做复杂的文档处理流水线。如果你用的是Vue要在页面上解析并显示Markdown最常见的方案是引入markdown-it然后通过Vue组件把编译后的HTML渲染出来。template div v-htmlrenderedContent/div /template script setup import { computed } from vue; import MarkdownIt from markdown-it; const md new MarkdownIt({ html: true, linkify: true }); const props defineProps({ content: String }); const renderedContent computed(() md.render(props.content)); /script这里有个安全提醒如果Markdown内容来自用户输入直接使用v-html或innerHTML渲染有XSS风险。一定要先用DOMPurify等库对HTML做清理或者使用默认禁用HTML标签的渲染配置。4.2 转Word的实用路线虽然Markdown在纯文本场景很强大但现实中总是有要交Word文档的需求比如技术方案要发给不接触Markdown的同事或者论文、报告需要按固定模板提交。最标准、最可靠的方案是Pandoc。这是一款命令行文档转换瑞士军刀支持Markdown与Word、HTML、PDF、LaTeX等几十种格式互转。基本用法很简单pandoc input.md -o output.docxPandoc转Word时会生成一个docx文件里面的标题样式基于Word的标题1标题2等预设样式好处是适合二次排版。如果你想要自定义模板可以先导出一份参考docx再修改样式pandoc input.md -o reference.docx --print-default-data-file reference.docx custom-reference.docx pandoc input.md -o output.docx --reference-doccustom-reference.docx如果你不想碰命令行还有图形化的路线Typora直接支持文件 - 导出 - Word内部其实也是调用Pandoc。所以装好Pandoc并配置到Typora里就能在菜单栏直接输出docx。至于markdown转word工作流coze这个方向我理解大家想要的是把转换流程自动化。Coze这类工作流平台可以编排一个自动化流程收到Markdown文本 - 调用转换接口或脚本 - 生成Word并输出。实际落地时最简单的做法是写一个接收.md文件、调用Pandoc、输出docx的脚本再用工作流平台去调度比如在Coze中配置一个节点接收文件输入调用本机或服务器的Pandoc脚本完成转换返回生成的Word文件给用户。核心还是要有一个能执行Pandoc的环境。工作流真正解决的只是把多个步骤串起来而不是替代Pandoc本身。4.3 SSE流式输出中的Markdown渲染AI对话场景的实战近几年大模型对话系统爆发SSE流式输出Markdown渲染器成了一个被高频搜索的词。这个词听起来高大上实际场景其实很常见你在对话框里问AI一个问题AI逐字输出回答文本这些文本通常包含Markdown格式的代码块、列表、标题前端需要实时把正在生成的内容渲染成网页样式而不是等全部输出完再一次性渲染。SSEServer-Sent Events是一种服务器向客户端单向推送数据的技术非常适合这种逐字输出场景。但流式渲染Markdown有一个经典难题半截语法问题。假设AI正在输出一个代码块它先流出了python三个反引号然后是代码内容最后才是结尾的三个反引号。如果每收到一小段文本就用完整Markdown渲染一次那么中间状态比如只有开头反引号、没有结尾反引号会被解析成一个未闭合的代码块界面就可能显示成普通文本或者一个巨大的代码块把页面撑爆导致闪烁和跳动。我踩过这个坑之后总结了几条解决思路缓冲区累积渲染不要把每一小段都单独渲染而是把已收到的文本累积起来在渲染前做节流比如每100ms渲染一次。这样即使语法不完整由于整体内容增量渲染结果也会比逐字渲染稳定得多。容错解析使用markdown-it时可以配置breaks和linkify选项并允许HTML对未闭合的代码块这类情况在流式过程末尾追加临时闭合内容确保解析器不会进入异常状态。延迟加载代码高亮对代码块高亮不要在流式过程中就立即对半截代码做高亮等代码块完结后再触发高亮避免高亮状态错乱。平滑滚动流式渲染后内容高度变化剧烈需要将页面滚动锚点稳定在用户正在阅读的位置不然文本会跳来跳去。具体到代码模型一个简化版思路let buffer ; const md new MarkdownIt(); function onChunk(chunk) { buffer chunk; const safeContent buffer \n\n; // 临时闭合可能未闭合的代码块 preview.innerHTML md.render(safeContent); }最终输出前用完整内容重新渲染一次去掉临时闭合内容。这个思路我实测下来效果稳定能大幅减少AI对话界面里常见的代码块闪烁问题。5. 踩坑实录Typora多开、JCEF报错与小程序显示每个用Markdown的人都会遇到几个奇奇怪怪的报错或者反直觉的操作下面这三个是热搜词里出现频率最高的我挨个说清楚当时的排查过程。5.1 Typora为什么只能打开一个窗口我当时在Windows和Mac上都遇到过这个问题双击第二个.md文件Typora没有新开窗口而是闪了一下然后回到了已经打开的那个窗口第二个文件的内容没显示出来或者得手动去菜单切换。排查过程一开始我以为是文件关联的问题重新设置了.md文件的默认打开方式无效。后来怀疑是软件装了两个版本冲突卸载重装还是无效。翻官方文档后才发现Typora目前是单窗口设计。它的定位是所有文件都在一个窗口里管理默认情况下双击文件只是让已有窗口获得焦点并把文件打开为窗口里的一个标签页而不是新开一个窗口。如果你就是想在多窗口里同时编辑多份文档我的解决办法是打开Typora后用文件 - 打开选择文件它会在同一个窗口的新标签页中打开。如果你确实需要两个独立窗口可以再打开一个Typora进程跨平台用户可使用启动器多开但这个操作不优雅容易在一个窗口里产生文件锁问题。更推荐的习惯是把Typora当作单文档聚焦写作工具一个窗口专注于当前文章需要多文档对比、批量管理时切换到VSCode或Obsidian。总之Typora多开报错不是bug而是产品设计取舍。理解了它的定位就理解了为什么官方一直没加多窗口这个功能。5.2 Your environment does not support JCEF 是什么鬼这条报错我在JetBrains系IDE比如IntelliJ IDEA、PyCharm里装Markdown插件时见到过。完整报错大概长这样Your environment does not support JCEF, cannot use Markdown Editor人话解释一下JCEFJava Chromium Embedded Framework是JetBrains IDE中用来在Java应用里嵌一个Chromium内核的组件很多富文本预览、网页渲染功能都依赖它。你的IDE检测到当前环境不支持JCEF所以Markdown编辑器的富文本预览功能就被禁用了。出现这个报错常见原因有几种JDK版本太老或者太新JCEF版本不匹配IDE跑在无图形界面的远程环境、某些服务器环境、或者受限的云桌面环境系统缺少Chromium运行所需的图形库IDE的内存配置不满足JCEF加载要求。我这边的排查记录是当时在一台远程开发服务器上用IDEA本地Windows打开同样的项目没问题但在远程桌面环境里就报了这个错。仔细排查后发现是远程环境缺少了Graphics相关的Linux库导致JCEF初始化失败。如果你是本地环境遇到这个错可以按以下顺序排查确认IDE已经更新到最新版JCEF通常随IDE版本一起升级检查JDK版本IDE自带的JBRJetBrains Runtime一般带JCEF尽量避免手动覆盖尝试在IDE设置里开启或关闭ide.browser.jcef.debug等JCEF相关开关如果是远程/容器环境检查图形库、X11转发或改用无头模式实在不行可以把Markdown插件降级为纯文本编辑模式或者改用VSCode。关键建议不要一上来就重装IDE。先判断你的使用环境里JCEF是否被系统级因素拦截再决定下一步。5.3 小程序到底能不能显示Markdown这个问题的答案是小程序本身不内置Markdown解析和渲染能力但可以通过引入第三方组件库来实现。很多人把Markdown粘贴到小程序里发现它不会自动变成格式化内容因为小程序的text组件只能显示纯文本rich-text可以显示HTML但也不会解析Markdown语法。实际可落地的方法有两类方案一引入towxml开源库towxml是一个专门用于在小程序中渲染Markdown和HTML的库支持表格、代码高亮、LaTeX、Mermaid等是社区里比较成熟的小程序Markdown方案。使用方式大致是把towxml库拷贝到小程序项目中在页面json配置里注册towxml组件用一个自定义组件包裹Markdown内容towxml会把Markdown解析成WXML结构。这种方式的好处是纯前端解析无需额外服务端缺点是库本身有体积首次加载会略慢。方案二服务端把Markdown转成HTML小程序用rich-text渲染如果你有服务端可以让后端在返回内容时用markdown-it/marked把Markdown转成HTML字符串小程序前端用rich-text组件直接渲染。rich-text nodes{{htmlContent}}/rich-text这种方式实现成本最低而且样式可控制。缺点是需要处理XSS风险以及rich-text对部分HTML标签和行内样式的支持有坑某些CSS属性不生效。我做小程序项目时更推荐方案二因为前端代码量少、渲染性能可控而且内容清洗可以在服务端统一做。不过要提醒一点小程序端如果对内容有敏感词审查、链接跳转、图片点击预览等需求纯rich-text的交互能力有限需要在解析层做更多定制。6. 让Markdown变得强大的扩展语法Mermaid与更多Markdown如果只有基础语法撑死算个美化版纯文本。它真正能成为一种通用内容格式靠的是丰富的扩展语法。这几年对我帮助最大的就是Mermaid。6.1 用Mermaid在Markdown里画流程图Mermaid是一种基于文本的图表描述语言它允许你通过简单的代码在Markdown文档里画流程图、时序图、类图、甘特图等。这意味着图表不再是图片附件而是和文字一样可以进行版本管理、Diff追踪的纯文本。一个最简单的流程图写法graph TD A[开始] -- B{判断条件} B -- 是 -- C[执行操作] B -- 否 -- D[结束]在支持的编辑器里它会渲染成一张完整的流程图在不支持的普通文本编辑器里它至少也是一段可读的文本。我实际感受最深的场景是写技术方案时。以前画架构图得用Visio或draw.io画完导出png再贴到Word里现在直接在文档里写Mermaid改起来也方便一行代码就能改一个节点名称不用重画整张图。不同环境怎么渲染MermaidTypora内置Mermaid支持代码块语言选择mermaid即可实时预览。VSCodeMarkdown Preview Enhanced插件支持Mermaid渲染。GitHubGitHub的Markdown原生支持Mermaid代码块。Obsidian默认支持Mermaid也可以安装插件增强。飞书文档很多人问飞书要装什么插件才能解析Markdown里的Mermaid其实飞书云文档原生支持粘贴Mermaid代码块后渲染成图的。你新建一个代码块把语言选为Mermaid或者直接粘贴mermaid代码块的文本内容飞书往往能识别并渲染。但要注意飞书的Markdown是一种简化版不保证所有GFM语法都支持所以最稳妥的方式是把Mermaid代码块放进飞书文档的代码块里看它是否自动渲染如果不行就在代码块内右击查看有没有预览图表选项。不同版本功能可能差异最终还是要以你手头版本为准。如果你自己开发一个Markdown编辑页面想支持Mermaid可以引入mermaid的JavaScript库在渲染完HTML后扫描代码块并调用mermaid.run()初始化。这里我唯一的经验提醒Mermaid渲染动画比较重如果文档里有大量图表建议设置securityLevel并延迟初始化避免页面卡顿。6.2 其他值得关注的扩展Mermaid只是Markdown扩展生态的一角还有几个高频用到的扩展语法Front Matter在文档开头用---包裹一段YAML元数据常用于静态博客或笔记工具。比如--- title: Markdown浅析 date: 2025-01-01 tags: [Markdown, 写作] ---数学公式通过$符号包裹LaTeX公式Typora、Obsidian、GitHub的Markdown都支持。行内公式用$...$块级公式用$$...$$。任务列表GFM支持的任务列表语法- [x] 已完成 - [ ] 待完成脚注在Typora、Pandoc等场景下支持这是一个句子[^1]。 [^1]: 脚注内容。删除线用~~文本~~实现删除线效果在协作审阅场景下很好用。这些扩展都是建立在Markdown约定规范之上的。使用时要记住一点扩展语法不一定被所有渲染器支持如果你的文档要跨平台发布建议先用兼容性最好的基础语法扩展语法只在确定目标平台支持的情况下使用。我自己写博文时几乎只用基础语法加代码块写技术方案时才会用Mermaid和表格写个人知识库时会用Front Matter和双链。怎么组合完全取决于你要发布到哪、给谁看、维护成本多大。最后再分享一个小经验不管你用哪个编辑器记得养成定期把Markdown文件纳入版本管理的习惯。用Git管理.md文件比任何富文本格式的自动保存都可靠。遇到改坏了、想回退、想比较前后差异的时候Git配合Markdown纯文本的特性能给你带来一种难以言喻的安全感。这也是我用Markdown几年下来最值得的一个决定。