1.1 从一次复制两小时、排版一整天的经历说起先说我个人的真实经历。早几年我在技术团队做文档维护最崩溃的一件事是把一份写好的方案从Word复制到公司内部Wiki。复制过去之后标题字号全乱了项目符号缩进错位图片挤到页面外表格宽度像被拉伸过一样。最要命的是在线编辑器里调整排版特别别扭一个简单的居中对齐鼠标要点五六下。那天我花了将近两个小时反复删除重贴、手动调格式最后还是在其它同事的帮助下才勉强收场。后来我认真反思了一下文档的内容我一共只花了四十分钟就写完了剩下的两个小时全部浪费在格式搬家上。这个体验让我下定决心换一种写作方式然后就接触到了Markdown。Markdown是一种轻量级标记语言核心思路是用纯文本的符号来表达格式比如用#表示标题用**表示加粗用-表示列表项。它本质上是让你在写作时就完成格式标注等文档到了任何一个平台只要这个平台支持Markdown解析就能自动渲染成漂亮、统一的样式。如果要用一句话总结Markdown对我最大的价值它让写作和排版两件事彻底解耦了。我只需要关心内容结构格式问题交给解析器处理。这篇文章我准备把Markdown的语法讲明白同时把我这些年踩过的坑、摸索出来的工作流一并分享出来不管你是刚开始接触Markdown的新手还是已经被换行不生效图片路径错误表格显示不全折磨过的老用户应该都能从中找到有用的东西。1.2 Markdown的原理一份源码任意渲染Markdown之所以能做到一处写作、到处渲染根本原因在于它的底层逻辑和HTML非常相似都是内容 标记的结构。你可以把Markdown源文件想象成一份带有注释符号的纯文本比如## 标题就是告诉解析器这行文字是一级子标题请用子标题样式展示。不同平台、不同编辑器都有自己的Markdown解析器但它们最终做的事情是一样的把标记符号转换成对应的HTML标签再套用平台各自的CSS样式显示出来。这就是为什么同一个.md文件放到GitHub、放到语雀、放到Typora、放到Obsidian里结构都不会乱——因为标记的逻辑是通用的。这和Word有个本质区别。Word文档保存的是当前状态的完整快照格式信息直接嵌在文件里而Markdown保存的是原始标记源码格式是在渲染时动态生成的。生活化地类比Word像是一张已经画好颜色、贴好贴纸的实体贺卡换个桌面就可能有折痕、贴纸脱落Markdown则像一份制作说明书不管在哪家作坊按说明书制作出来的贺卡结构都一样。想明白这一点你就能理解后面很多怪现象——为什么同一个Markdown文件在不同平台显示效果略有差异因为各家解析器对边缘语法的支持程度不同但核心语法一定是一致的。1.3 哪些人适合学习Markdown简单来说只要你有写文档的需求就有理由学Markdown。程序员自不用说README、接口文档、项目笔记都是它的标配场景。但实际使用下来我发现受益更大的其实是编辑、产品经理、运营、学生这些非技术岗位。运营同学写公众号用Markdown排版可以省去反复复制到编辑器里调格式的麻烦产品经理写需求文档用Markdown一份.md文件丢到研发的Git仓库里就能直接评审甚至还能自动生成目录和修订记录学生党用Markdown记笔记配合双链笔记工具比传统Word文档更适合知识积累和回顾。可以这么说凡是文字内容需要长期维护、经常跨平台流转的场景Markdown都比传统富文本编辑器更省心。当然如果是复杂图文混排、需要精确控制版式的正式出版物Markdown就不太合适了这种场景还是交给专业排版工具。但日常工作中90%的文档需求Markdown完全够用。2. 段落、标题、强调与列表每天用得最多的四类基础语法2.1 段落与换行为什么你写的换行不生效很多初学者遇到的第一个Markdown灵异事件就是我在源码里明明按了回车换行为什么渲染出来还是连在一起这其实涉及Markdown对换行的定义。在Markdown里凡是连续的文字行只要中间没有空行就会被视为同一个段落渲染时这些行会合并成一段连续的文本行与行之间的单个换行通常被忽略或者被当成一个空格处理。举例说明。你在源码里写这是第一行 这是第二行 这是第三行渲染结果大概率是这是第一行 这是第二行 这是第三行而不是三行独立显示。想让第二行真的换行显示有三种做法在上一行末尾加两个空格再回车这被称为软换行渲染后显示为换行但不会开启新段落在上一行和下一行之间插入一个空行这被称为硬换行渲染后不仅是换行而且是新段落段落之间会有间距使用HTML标签br强制换行。从实际写作体验来说最推荐的是第二种空一行分段。它最直观也不容易出错。第一种写法有好处也有麻烦——好处是段落内的行间距更紧凑麻烦是很多人在源码里看不见行尾空格保存后怎么调都不生效。老手们写Markdown时养成的一个习惯是不要在行尾留不确定的空格分段就用空行这个习惯能省下大量排错时间。2.2 标题与层级文档结构感的来源标题是文档结构的骨架。Markdown用#号表示标题层级从#到######一共六级。写法如下# 一级标题 ## 二级标题 ### 三级标题 #### 四级标题 ##### 五级标题 ###### 六级标题需要注意#后面一定要跟一个空格再写标题文字否则有些解析器不识别会把整行当成普通文本。另一个容易被忽略的细节是一份文档里#一级标题最好只用一次通常用于文章总标题正文章节从##二级标题开始。这样做的好处是目录结构清晰也方便后续用工具自动提取标题生成导航。我在实际使用中还有一个心得不要为了好看频繁使用四级、五级标题。标题层级一旦超过三级读者在屏幕上看到的其实是一片密密麻麻的标题目录反而失去了重点。如果感觉内容需要四级标题才能说清楚更合理的做法是拆分文章而不是继续加深层级。这个习惯在写长文档时尤其重要——好文档的标题层级应该像人的骨架有且只有主干和分支不能每一根毛细血管都单独占一个层级。2.3 粗体、斜体、删除线与列表嵌套强调语法是Markdown里门槛最低、使用频率最高的部分。先看一组最常用的标记*斜体* 或 _斜体_ **粗体** 或 __粗体__ ***粗斜体*** 或 ___粗斜体___ ~~删除线~~从实际排版效果来看中文环境下斜体用得很少因为中文字体没有明显的倾斜形态视觉上容易和普通文字混淆。粗体则是使用最多的强调方式但我建议每篇文档里粗体不要出现得太密集否则处处强调等于没有强调。删除线主要用于标注已废弃该方案不做考虑之类的信息比如你列任务清单时想表明某项已经取消又不想直接删掉记录就可以用删除线。列表分为无序列表和有序列表。无序列表用-、*或加空格开头有序列表用1.、2.加空格开头。一个实用的知识点是有序列表的数字编号会自动重排。你即使在源码里把所有项目都写成1.渲染时也会自动变成1. 2. 3. ...这一特性在后期增删列表项时特别好用完全不需要手动改序号。列表嵌套是稍微进阶一点的用法。嵌套的方法是在子列表项前加两个空格或一个Tab缩进。示例如下1. 环境准备 - 安装Node.js - 配置npm镜像 2. 项目初始化 - 执行脚手架命令 - 验证目录结构嵌套列表在渲染后会形成清晰的层级关系非常适合写操作步骤、需求拆解、知识点大纲等场景。这里要注意的是不同解析器对缩进用空格还是Tab的容忍度不完全一样为了避免莫名其妙的错位我统一推荐使用两个空格缩进并且整个文档保持一致。3. 引用、代码、链接与图片让文章真正成文的关键3.1 引用块不是花哨是文档里的引用区引用块用开头用来标记一段引用的文字或重要的注意事项。用法如下 这是一段引用内容。 可以换行继续写。渲染后会得到一段带左侧竖线的引用区域视觉上和其他正文明显区分开。这个语法在实际文档中非常实用常见的用法有三类第一类是引用外部资料原文比如写技术调研报告时把官方文档的说明摘进来第二类是提示/警告信息比如注意执行该命令前请先备份数据库用引用块展示会比放在正文里醒目得多第三类是对话、访谈、案例的记录。引用块还支持嵌套也就是在里再用可以形成多级引用。但我的建议是除非是层级感很强的文献综述否则日常文档中一级引用就够了。引用块的根本作用是从视觉上区隔内容使用过度反而会破坏正文的连贯性让整篇文档看起来像是在到处贴便签纸。3.2 行内代码与代码块技术写作的生命线Markdown对代码的展示支持非常完善这也是它被称为程序员友好的关键原因。行内代码用反引号包裹用来标记一段简短的代码片段或命令名称比如执行npm install安装依赖。渲染后这行命令会以等宽字体和浅色背景显示和正文明显区分。代码块则用三个反引号包裹支持多行代码。更关键的是在开头三个反引号后面可以指定语言名称如python这样编辑器就能自动做语法高亮。以下几个例子javascript const greeting Hello, World!; console.log(greeting);markdown python def hello(): print(Hello, World!)不加语言名称的代码块也能正常渲染但不会有语法高亮。对于技术文档语法高亮对读者理解代码的帮助极大所以我强烈建议写代码块时养成标注语言的好习惯。另有一个小技巧如果要在代码块里展示一组反引号可以把包裹用的反引号数量增加到四个比如 这样内层的三个反引号就不会被误判为代码块的结束标记。 ### 3.3 链接的两种写法 Markdown链接主要有两种写法行内式和引用式。行内式是最常见、最直观的 markdown [百度](https://www.baidu.com 点击访问百度)方括号里写链接文字圆括号里写URLURL后面的引号内容是可选的提示文字鼠标悬停时会显示。这种写法简单直接适合链接数量较少的文档。引用式的写法则稍微复杂一点但特别适合长文档你可以查看[官网文档][docs]获取更多信息。 [docs]: https://developer.example.com/docs 官方文档引用式写法的核心是把链接地址集中管理。文档中只写[文字][标识]然后在文末通常是文档末尾统一定义每个标识对应的真实URL。这样做的好处显而易见如果某一个链接地址失效或需要更新你只需要改末尾那一行定义而不需要满篇去找所有出现这个链接的地方。我在写博客和技术文档时只要链接超过三四个一律用引用式。维护成本低源码可读性也好。还有一个特殊语法叫自动链接直接用尖括号包裹URL或邮箱地址https://example.com contactexample.com渲染后链接文字和地址是相同的适合在文档里直接给出网址的场景。3.4 图片路径我用惨痛教训换来的经验图片语法和链接非常相似只是在最前面多了一个英文感叹号替代文字的作用很重要当图片加载失败时用户看到的不是一张破碎的图而是这段替代文字同时屏幕阅读器也会朗读这段文字方便视障用户理解图片内容。这个细节很多新手会忽略但在正式文档里很有价值。真正让很多人困扰的是图片路径怎么写。这里要分清三种情况网络地址直接填以https://开头的完整URL适合引用网上已经存在的图片。相对路径以图源文件所在位置为基准写相对路径如。这种写法在本地写作时最灵活文件夹一起拷贝或上传到Git仓库时只要相对目录结构不变图片就能正常显示。绝对路径如/Users/username/project/images/architecture.png这种写法在本地可以显示但换电脑或部署到服务器后经常失效强烈不建议在通用文档中使用。我个人的实践是文档和图片按相对路径组织图片统一放进同级的images或assets文件夹。举个例子如果你的文档目录结构是articles/ ├── markdown-guide.md └── images/ └── markdown-logo.png那在markdown-guide.md里就应该写。这样无论整个articles文件夹搬到哪台电脑、传到哪个Git仓库只要结构没变图片就不会丢。还有一个非常实用的补充如果图片路径包含空格或中文部分解析器可能会解析失败。我在Windows上遇到过不少次这种情况。稳妥的做法是给路径加上尖括号或双引号例如但最简单的还是文件名和路径尽量用英文连字符从源头上杜绝问题。4. 表格、任务列表与HTML扩展进阶写作的常见需求4.1 表格的写法与兼容性真相Markdown表格的语法并不复杂核心就是管道符 短横线 冒号。一个标准表格的源码如下| 功能 | 是否支持 | 优先级 | | ---- | :-----: | -----: | | 登录 | 是 | 高 | | 注册 | 否 | 中 | | 导出 | 是 | 低 |说明一下第一行是表头第二行是分隔行其中短横线代表列存在冒号的位置控制对齐方式——:-----表示左对齐:-----:表示居中对齐-----:表示右对齐。从第三行开始是表格内容。渲染后的效果会是规规矩矩的表格。这里我要特别说一个兼容性真相表格对齐方式在不同平台上表现并不完全一致。GitHub、Typora等主流解析器对冒号对齐支持得很好但有些轻量级解析器或老旧系统会无视冒号一律左对齐。所以如果你依赖表格的居中/右对齐来表达信息建议在工具链不固定的情况下别太依赖对齐效果更重要的是把数据本身填对。另外表格单元格内要显示管道符|时需要转义\|否则解析器会把它当成下一列的边界。还有一件事是表格的换行标准Markdown表格的单元格是不支持直接换行的如果内容太长要么精简文字要么用br标签但后者在部分平台也不支持。我的经验是表格适合放简短、结构化的信息一段话以上的内容应放到表格后面的正文里展开。4.2 任务列表和删除线文档里的状态管理任务列表Task List在GitHub、Typora、Obsidian等平台中是原生支持的语法是在列表项前加[ ]或[x]- [ ] 调研方案 - [ ] 编写原型图 - [x] 确认需求渲染后未完成项显示为空心方框已完成项显示为带勾的方框。任务列表非常灵活常用于写需求清单、排期计划、团队分工、发布检查表等。配合有序列表或嵌套列表还能做出带子任务的状态管理面板。从我个人经验来看任务列表最典型的应用场景是评审检查单和上线发布单这两类场景的共同特点是步骤多、漏掉一个就可能出事故。用任务列表写每完成一步就勾一个团队协作时大家看一眼文档就知道当前进度比在群里反复刷消息可靠得多。需要注意的是- [ ]之间必须有空格[x]大小写均可但保持小写最通用。如果你用的平台不支持任务列表它通常会退化成普通列表项文字还在只是方框标记可能显示不出来这个降级行为还算友好。4.3 什么时候该用HTML扩展Markdown本身就是从HTML简化而来的因此它允许在文档中嵌入部分HTML标签解析器会原样保留并渲染。这意味着Markdown留了一扇逃生门当标准语法满足不了需求时你可以用HTML来补充。几个常用的例子换行br在表格单元格内尤其常用按键样式kbdCtrl/kbd kbdS/kbd渲染成键盘按键样式折叠块detailssummary点击展开/summary隐藏内容/details适合放补充说明、答案等次要信息图片尺寸控制标准图片语法没法设置宽高但可以用img src图片路径 width400实现上标与下标Hsub2/subO、Xsup2/sup。这里我想提醒一句HTML标签是逃生门不是正门。能用标准Markdown语法解决的尽量别动用HTML。原因有二一是跨平台兼容性没那么好部分平台出于安全考虑会过滤掉所有HTML二是写起来啰嗦违反了Markdown源码可读的核心优势。我自己的判断标准是如果这个HTML标签只是为了让少数几个平台显示更漂亮我宁可放弃这个效果用标准语法重新组织内容。5. 数学公式与图表扩展从笔记走向正式文档5.1 LaTeX数学公式的行内与块级用法如果你需要写技术博客、论文笔记、算法说明数学公式几乎是绕不开的需求。Markdown本身不支持公式但主流的编辑器Typora、Obsidian、VS Code配合插件都通过MathJax或KaTeX扩展支持LaTeX语法公式。用法分为两种行内公式和块级公式。行内公式用单个美元符号包裹写作$公式$比如勾股定理可以表示为$a^2 b^2 c^2$。块级公式用双美元符号包裹独占一行比如$$\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}$$渲染后是一个独立的公式区域并且居中显示。常见的LaTeX语法只需要记住几个最常用的符号就能覆盖大部分场景分数\frac{分子}{分母}根号\sqrt{表达式}上下标x^2和x_i求和\sum_{i1}^{n}希腊字母\alpha、\beta、\theta向量箭头\vec{a}我刚开始接触时最大的感受是不用记太多遇到不认识的符号再查用多了自然就记住了。比较关键的实践细节是行内公式和中文文字之间最好加一个空格避免拥挤也避免部分解析器的边界识别错误美元符号里不要有意外空格如$ a $有些解析器能容忍但严格模式下会解析失败。5.2 依赖扩展的图表能用但要想清楚除了数学公式很多编辑器还支持流程图、时序图、甘特图等扩展语法其中比较有名的是Mermaid这类图表工具以及各类画图代码块扩展。它们的好处是图表以纯文本方式写在文档里随文档一起版本管理修改方便不需要额外截图。但我想给一个冷静的建议在通用Markdown文档里谨慎使用扩展图表。原因很简单——兼容性。一个在Typora里渲染得很漂亮的流程图发到GitHub上可能因为仓库未启用对应渲染支持而变成一堆源码发到某些博客平台甚至可能直接显示为乱码。扩展语法毕竟不是标准Markdown的一部分它好用但前提是渲染环境支持。我的处理策略是如果文档的目标平台是本地笔记工具或自己完全可控的博客系统可以放心使用图表扩展因为它确实提升效率如果文档要发给外部协作方、放进通用文档管理系统我会选择把图表导出为图片再插入Markdown牺牲一点可维护性换来的是无差别的显示效果。这个取舍不绝对但秉持一个原则选图片还是选扩展语法取决于文档最终会在哪些平台上被阅读。6. 编辑器选型与我的Markdown写作工作流6.1 主流编辑器对比Typora、VS Code、Obsidian写Markdown的编辑器非常多我挑三个最有代表性的放在一起对比Typora、VS Code、Obsidian。它们的定位和体验完全不同适合的人群也不一样。特性TyporaVS CodeObsidian上手难度极低中等中等偏低写作体验所见即所得源码 预览分屏所见即所得生态插件中等极强强适合场景日常写作、博客开发相关文档知识管理、笔记批量处理弱强中公式/图表支持需装插件支持Typora最大的优势是所见即所得写出来的效果即时可见对新手非常友好。它是付费软件但买断制我用下来觉得物有所值。VS Code本身是代码编辑器装几个Markdown插件之后却意外地强大尤其是它的源码编辑、批量查找替换、Git集成能力写大型技术文档时优势明显。Obsidian则是一个双链笔记工具非常适合做个人知识库它的Markdown支持完善还内置了图谱视图长期记笔记的人用起来会很顺手。我的建议是不需要纠结哪个最好而是看哪个最适合你当前的场景。写博客文章用Typora最舒服写项目文档并且日常本来就用VS Code那就用VS Code少装一个工具如果是做读书笔记、知识积累选Obsidian它的链接体系能帮你把零散知识串起来。6.2 我常用的VS Code扩展如果你选择VS Code写Markdown有几个扩展我非常推荐。第一个是Markdown All in One集成了自动目录、快捷键快速插入标题、加粗等、自动格式化表格、自动更新目录编号等功能日常写作效率提升明显。第二个是Markdown Preview Enhanced比VS Code自带的预览功能强大很多支持滚动同步、导出PDF/HTML、自定义预览样式还支持用图表扩展画流程图。第三个是Paste Image这个插件解决的是贴图痛点截图后直接CtrlAltV图片会自动保存到指定目录并把Markdown图片语法插入到光标处不用再手动去截图、保存、写路径。这三个插件组合起来基本可以满足我在VS Code里写技术文档的全部需求。另外提醒一下VS Code的Markdown预览默认不跟随光标滚动记得在预览窗口的右上角菜单里开启跟随光标同步滚动否则长文档上下翻页时眼睛容易花。6.3 Markdown转Word、PDF、Excel的实战经验Markdown写得再顺手终归有需要交付成Word或PDF的时候。这里分享一下我试过最稳的转换链路。PDF转换我推荐两条路如果用的是Typora直接用自带的导出PDF功能效果稳定支持主题样式如果用的VS Code用Markdown Preview Enhanced的导出功能可以基于Puppeteer把预览渲染成PDF。需要强调的是导出PDF时代码块是否换行经常出问题长代码会被截断这时候只有在源码里手动换行或用更宽的页面配置才能解决。转Word相对麻烦一些标准的做法是使用Pandoc工具命令大致是pandoc input.md -o output.docxPandoc对标准Markdown的兼容性很好生成的Word文档结构干净标题自动映射到Word内置样式。但要注意如果你在Markdown里使用了大量扩展语法如Mermaid图表、数学公式Pandoc默认不一定处理需要额外的过滤器和插件普通用户会觉得很折腾。对于大多数场景我建议转Word前先检查文档是否只用了标准语法若有复杂图表最好把图表先导出成图片再插入这样转换过程的意外会少很多。还有一个热门的诉求是Markdown表格转Excel。我实测最靠谱的方式不是先转再复制而是在支持渲染的编辑器如Typora里复制渲染后的表格然后直接粘贴到Excel或WPS表格表格结构通常能完整保留。如果你只有一个.md源文件也可以先在浏览器里打开GitHub预览再复制表格粘贴效果比手动整理快得多。批量转换场景则可以结合在线转换工具或自动化工作流处理原理都是先解析出表格数据再生成xlsx文件。7. 高频踩坑清单换行、表格、图片、标点的血泪教训7.1 换行与段落的坑我把最常踩的坑按现象 - 原因 - 解决列成一个表方便对照坑点现象原因与解决换行不生效源码里回车了渲染后还是连在一起单个回车在Markdown里是段落内软换行被渲染成空格。段落间空一行分段行尾空格清不掉软换行时加的空格删了之后换行也失效想真正换行就用空行不要依赖行尾空格行首缩进怪段落首行加Tab或空格渲染后可能变成代码块行首四个空格会被识别为代码块。中文正文不建议用缩进要缩进用引用块或列表尤其是行首缩进这个坑很多从Word转过来的人第一反应是空两格写正文结果整段变成灰色代码块还找不到原因。记住Markdown没有首行缩进语法段落之间用空行自然分隔即可。如果非要视觉上的缩进效果那就接受工具的默认样式别硬调。7.2 表格的坑表格的坑集中在三个方面。一是中文标点与管道符冲突。如果你在表格里写了一个中文全角管道符它不会影响结构但如果你不小心用了英文半角|就会被当成列分隔符导致表格列数变多。必要时用\|转义。二是单元格内容换行不生效。标准表格单元格内不肯换行如果硬要换用br但部分平台不支持。我的解决方案内容太长就拆行写多条记录而不是硬塞在一个单元格里。三是表头分隔行格式错误导致整表不渲染。第二行至少要有三个短横线每个列之间用管道符分隔。如果你漏了分隔行整个表格会被当成普通文本段落看起来像几行乱掉的纯文本。检查时先看源码结构这是定位表格问题最快的方法。7.3 图片路径的坑图片路径问题在热词里出现频繁说明大家都被折腾过。除了一开始讲的相对路径建议外还有几个容易被忽略的细节中文路径和空格。即便用相对路径如果文件夹或文件名包含中文/空格Windows上一些编辑器和平台依然会识别失败。最省心的方案是路径和文件名统一用英文小写加连字符。Git仓库里图片大小写不一致。在Mac或Windows本地可能正常但Linux服务器上的文件系统区分大小写Images和images会被视为两个不同目录。如果你把Images改名为images务必确认引用也同步改了。图床选择。如果你希望在多个设备间共享笔记本地图片路径会失效可以考虑把图片上传到对象存储或图床服务然后在Markdown里填网络URL。代价是依赖网络离线时图片显示不了所以我更推荐本地相对路径为主图床URL为辅按使用场景灵活选择。7.4 长期实践下来我觉得最值得坚持的几条写作习惯最后分享几个不涉及具体语法、但长期收益很高的写作习惯。第一英文、数字与中文之间留一个空格。使用Markdown语法1小时比使用Markdown语法1小时读起来舒服得多这也符合中文排版的基本惯例。如果你嫌每次手动加空格麻烦可以用编辑器里的查找替换或专门的格式化工具辅助处理。第二一篇文档只聚焦一个主题。Markdown很适合写长文但适合长文不等于应该写长文。我见过太多人把几十个零散知识点塞进一个README最后目录比正文还长读者根本找不到重点。合理的做法是一个仓库或一个笔记结构下用多篇Markdown文件分别承载不同主题再通过目录或双链把它们关联起来。第三在文档开头写清楚适用范围和读者对象。这虽然不是语法问题但一份良好的Markdown文档应该在开头用几句话告诉读者这份文档写给谁、覆盖什么范围、不涉及什么内容。这个习惯会显著提升文档的可用性署名和更新日期也建议一并写上方便后续维护。我自己现在写任何文档都默认以Markdown为第一格式从工作周报到项目方案再到个人博客几乎全程脱离了对Word的依赖。偶尔需要把文档交付给客户时再走一遍转换流程效果稳定可控。这套工作流跑顺之后我可以很负责任地说写作的效率提升不是一星半点而是从排版地狱里解放出来的那种轻松。如果你还在被格式问题反复折磨不妨给自己一周时间试着把下一份文档用Markdown写出来。大概率你会和我一样再也回不去了。