
Markdown 这个东西我最早接触时以为它只是一个“给程序员用的记事本高级版”后来真正用它写了两年技术文档、项目 README、课程笔记之后才发现它其实是内容创作者和高强度文字工作者的效率底座。它不是软件而是一种轻量级标记语言用纯文本加少量符号来控制标题、列表、引用、代码块和表格的排版最终可以渲染成网页、PDF、Word 等通用格式。跟着狂神的节奏把 Markdown 从零到进阶完整过一遍你会发现它最大的价值不是“能排版”而是让你彻底告别用鼠标反复调格式的动作把精力完全还给内容本身。这篇文章适合刚接触 Markdown 的新手也适合已经会基础语法、但总被图片路径、表格转换、公式显示折磨的老用户。我尽量按照实战顺序来讲每个知识点都给出可直接照抄的写法。1. 为什么要用 Markdown它解决的不只是排版问题1.1 写作与排版分离专注内容本身先想一个问题你用 Word 写一篇十万字的方案最多的时间花在哪大概率不是想内容而是在调格式标题字号、行距、段落缩进、目录更新。Markdown 的思路反过来了它强制你先用纯文本把结构写完然后通过#号标记标题、*号标记强调、-号标记列表排版交给渲染器去处理。我常用一个类比Word 是边砌墙边刷漆Markdown 是先把砖码好最后统一交给装修队。这种方式最大的好处是写作的时候你不会频繁被打断。注意力一旦从“内容”切到“样式”再切回来至少需要几分钟进入状态。长期写文档的人应该都有这种体会格式操作越少产出越高。这种“分离”还带来了一个附加价值同一份 Markdown 内容可以在博客、GitHub、公众号、知识库、Word 文档之间无缝迁移而不需要每次都复制粘贴再重新排版。你只需要改一下发布端的样式模板内容一个字都不用动。这就是为什么技术圈里 README、接口文档、博客文章几乎都是 Markdown 格式的原因。狂神当时讲 Markdown 时反复强调过一个观点语法是死的习惯是活的。与其追求花哨插件不如先把“纯文本写结构”这个习惯刻进肌肉记忆里。1.2 纯文本带来的可迁移性与协作优势Markdown 的底层是纯文本这看起来“简陋”但恰恰是它最大的优势。拿笔记软件举例很多主流笔记应用都有自己的私有格式你如果用了五年想换软件导出、清洗、迁移会让人崩溃。但 Markdown 格式的笔记文件就是一个个.md文本文件换任何工具都能打开甚至用系统自带的记事本都行不存在被某个厂商锁死的风险。对于团队协作纯文本还有一个隐藏属性可以被 Git 这类版本管理工具逐行对比。谁改了哪句话、某个标题什么时候被删掉都能清清楚楚看到这在文档维护里非常实用。我见过很多团队把需求文档、技术方案直接用 Markdown 放在代码仓库里和代码一起走评审流程效果比在聊天工具里传 Word 文件高太多。当然这种方案的代价是团队需要有一点“极客”习惯但对技术团队来说几乎零成本。2. Markdown 基础语法速查从零写出第一篇文档2.1 标题、段落、换行与强调最常用的四个动作标题在 Markdown 里用#表示数量对应层级一个#是一级标题六个######是六级标题。这里要特别提醒#和标题文字之间必须有空格写成#标题在大部分渲染器里不会生效。一级标题通常留给文档名不要轻易用否则目录结构会乱。标题之后要空一行再接正文否则某些渲染器会把标题和下一段当成一个整体视觉层级会丢失。段落之间要用空行分隔。同一个段落内如果直接回车换行在大多数平台里并不会产生新段落只会在部分渲染器里显示成空格。这是 Markdown 新手最容易踩的坑之一。想要真正的换行有三种常见做法一是段尾加两个空格再回车这是 Markdown 原始规范二是用br标签三是干脆空一行分成两个段落。我个人的建议是优先用空行分段如果必须在同一段落里换行比如表格里的多行内容再考虑末尾两个空格或br。写博客、README 时切莫只按一次回车就当换行GitHub 上经常出现“明明写了多行渲染后挤成一段”的尴尬。强调语法也很简单**加粗**表示粗体*斜体*表示斜体~~删除线~~表示带删除线的文字高亮在部分平台表示高亮。注意这些符号都是成对出现并且推荐写成两个星号包粗体而不是下划线因为下划线在英文单词里容易误触发。如果你在写技术教程行内代码要用反引号包起来比如git commit -m init这样渲染后会有代码样式与普通文字区分明显。还有一个小技巧某些平台支持用反斜杠转义 Markdown 符号本身想直接展示#或*时前面加一个\即可比如\# 不是标题。2.2 列表、引用、链接与图片让内容更有结构无序列表用-、*或开头有序列表直接用1.2.开头。这里有个细节有序列表的数字其实不要求连续渲染器会自动按顺序排列但为了可读性我仍然建议写成 1、2、3。列表嵌套时子列表要缩进两到四个空格不同编辑器要求的缩进不太一样最稳妥的是用四个空格。如果你在列表项里写多行文字注意保持首行后的行与列表符号对齐否则缩进一乱渲染结果可能直接断开。引用块用开头可以嵌套比如加一个就是二级引用。在写博客或 README 时引用块常用来放“注意”“提示”这类信息视觉上非常清晰。我写文档的习惯是普通说明用正文需要单独强调的注意事项用引用块这样读者扫一眼就能抓住重点。链接的写法是[链接文字](https://example.com)图片的写法只比链接多一个感叹号。替代文字一定要写一方面是在图片加载失败时给读者一个说明另一方面方便屏幕阅读器朗读。如果在链接或图片地址里包含了空格、括号等特殊字符整段地址最好用尖括号包起来比如https://example.com/a b否则部分渲染器会截断链接。2.3 代码、表格、任务清单效率控最常用的三件套行内代码用单个反引号代码块用三个反引号包裹并且可以在起始反引号后写语言名称比如def hello(): print(hello markdown)这样渲染时就会有对应的语法高亮。代码块内部保留原始空格和换行非常适合贴配置文件和命令。我还习惯在较长文档里给每个代码块加上语言标注即使内容是纯命令也是如此因为高亮能大幅提升可读性。要插入一个真正的反引号字符可以用双反引号作为代码块的起始标记这种技巧在写 Markdown 教程时尤其好用。表格语法以管道符|划分列第二行用---控制对齐方式:---左对齐:---:居中---:右对齐。示例语法效果说明**加粗**加粗强调|竖线表格内容转义这里有个常见的坑表格内容里如果包含管道符|必须写成\|否则会把当前单元格截断。表格中的换行也不能直接用回车需要用br。另外表格前后最好各空一行特别是表格紧跟在标题或列表后面时否则部分平台会解析异常。任务清单是 GitHub 扩展语法写法是- [ ] 未完成和- [x] 已完成。它特别适合用来写进度追踪类文档比如上线检查表、学习计划。我试过把一周的工作计划全部写成任务清单放在项目仓库里每天更新勾选框团队其他人一眼就知道哪些事还没做完。基础语法加起来就是这些如果你能熟练运用日常笔记和博客已经完全够用了。3. 编辑器、阅读器与工具链Markdown 文件要怎么打开才舒服3.1 明确一件事下载的不是“Markdown”而是编辑器网上经常有人搜“Markdown 下载”“Markdown 安装教程”这里必须澄清一下Markdown 是一种语法规范不是一个可执行软件所以你真正要找的是支持 Markdown 的编辑器。把.md文件用系统记事本打开当然也能看到内容但那是纯文本没有渲染效果阅读体验很差。新手最舒服的路径是装一个所见即所得编辑器边写边看到最终样式。我推荐过的工具很多目前的常用组合是这样日常笔记用 Typora 或 Obsidian写代码相关文档用 VS Code需要最终输出 Word 或 PDF 时用 Pandoc 转换。Typora 的优点是界面干净输入即预览数学公式支持非常好Obsidian 的优势是本地文件管理和双链笔记适合做个人知识库VS Code 本质是代码编辑器但配合 Markdown Preview Enhanced 插件后预览效果和自定义模板能力都很强适合资深玩家。此外还有 MarkText、Zettlr 等开源选择丰俭由人。不论选哪个安装之后先新建一个.md文件把基础语法点一遍确认预览正常再开始用。3.2 各平台快速预览方案Windows、macOS、Linux、SublimeWindows 和 macOS 上最省事就是装 Typora双击.md文件就能直接打开不需要任何配置。如果你不想装独立软件也可以用浏览器插件或者在线编辑器。Linux 用户则更适合命令行方案glow是一个终端里的 Markdown 阅读器输入glow 文件名.md就能看到带样式的渲染结果mdcat类似但输出风格不同如果想要更通用的方案可以用 Pandoc 把 Markdown 转成 HTML然后浏览器打开命令是pandoc -s input.md -o output.html。这些工具在 Linux 包管理器里都能直接装不需要额外配置。再说一个很多人问过的场景Sublime Text 怎么看 MarkdownSublime 默认只是把.md当纯文本处理需要先装 Package Control然后搜索安装 Markdown Preview 插件装好后用快捷键Ctrl Shift P输入Markdown Preview选择在浏览器中预览即可。配套的 MarkdownEditing 插件可以提供语法高亮让编辑体验更接近专业 IDE。如果你是直接用 VS Code装一个 Markdown Preview Enhanced 插件后按Ctrl Shift V就能预览非常顺滑。如果用的是 Vim也有 vim-markdown 这类插件但新手没必要在编辑器折腾上花太多时间先有一个能用的预览环境就够了。3.3 按使用场景选型的建议工具不在多够用就行。我的建议是如果只是写个人笔记选 Typora 或 Obsidian打开文件即写即看如果是程序员写 README、接口文档VS Code 是底线如果要做成团队知识库考虑语雀、Notion 这类带云端协作的平台它们同样支持 Markdown 语法如果要把文档放 Git 仓库走评审那就直接用任意编辑器但提交前用 VS Code 或 GitHub 预览一遍。记住一点不管选哪个工具语法本身是通用的换工具不换语法这比任何花哨功能都重要。4. 进阶实战公式、图片路径、表格转换、网页转存的高频操作4.1 数学公式支持原理与常用写法很多朋友最初学 Markdown 就是为了写数学笔记和论文初稿。Markdown 本身不支持公式但主流编辑器都会集成 LaTeX 公式渲染引擎一般分为行内公式和块级公式。行内公式用两个美元符号包起来比如$a^2 b^2 c^2$块级公式用两对美元符号独占一段$$ \frac{-b \pm \sqrt{b^2 - 4ac}}{2a} $$这里能渲染的关键是编辑器内置了 MathJax 或 KaTeX。Typora 默认支持不需要额外装插件VS Code 的 Markdown Preview Enhanced 也支持原生预览可能需要安装“MarkdownMath”扩展。常见的公式语法包括上下标用x^2和x_i分数用\frac{分子}{分母}根号用\sqrt{}求和用\sum_{i1}^{n}希腊字母用\alpha、\beta。如果你在某个平台发现公式显示为原始代码先检查两边是不是有多余空格再检查反斜杠是否被转义。渲染引擎对$和\比较敏感这是最高频的问题尤其是写完$$后一定要另起一行写公式最后再单独起一行收尾否则很容易不渲染。4.2 图片路径的三种写法与踩坑记录Markdown 图片路径有三种常见写法网络 URL、相对路径、绝对路径。网络 URL 只要不失效就永远有效但不适合离线文档绝对路径从盘符根目录开始比如C:\Users\...只在你自己电脑上有用一旦换机器或分享给别人就废了相对路径是以当前文档所在目录为起点比如./assets/photo.png这是我强烈推荐的一种配合规范的 resources 或 images 目录整个文档目录可以随意整体搬移。实操层面Typora 在偏好设置里可以配置“复制图片到 ./assets”和“优先使用相对路径”每次粘贴截图后它会自动把图片存进当前目录的子文件夹并自动生成相对路径这能解决 90% 的图片显示问题。VS Code 里可以装 Paste Image 插件Ctrl Alt V直接粘贴剪贴板截图默认存入当前目录的 images 文件夹。踩坑方面最常见的是路径里带中文或空格导致渲染失败尽量把文件名改成英文加数字其次是在 Windows 上反斜杠\会被部分渲染器当成转义字符路径分隔符尽量用正斜杠/。如果你处理的是大批量笔记还可以考虑把图片转成 base64 内嵌但这样会让文件体积剧增只适合少量关键图。4.3 表格转 Excel、Markdown 转 Word 的完整思路表格处理是很多人实际工作里的刚需。从 Markdown 表格复制到 Excel 时直接粘贴往往会把每一行当成一行文本列对不上。正确姿势有三种第一种是用 Pandoc 命令把 Markdown 表格转成 CSV再用 Excel 打开第二种是复制后粘贴到文本文件然后在 Excel 里用“数据”菜单自文本/CSV 导入并指定分隔符为管道符第三种是干脆用 Python 的 pandas 读取pd.read_csv(file.md, sep|)后处理但我很少这么干因为大部分个人场景用前两种就够了。Markdown 转 Word 也是一样不要指望复制粘贴能保留样式。最可靠的是 Pandoc 命令pandoc -s input.md -o output.docx这条命令会把标题层级映射成 Word 的内置标题样式表格也会转成 Word 表格代码块变成带底纹的段落。如果你没有接触过 Pandoc可以把 Typora 的“导出 Word”选项当作替代方案它底层调用的其实就是 Pandoc 或自定义转换逻辑。如果你想把整条链路自动化现在不少低代码工作流平台也能处理这个需求接收 Markdown 文本调用 Pandoc 工具节点生成 docx 后自动归档到云盘。核心注意点是生成 Word 的节点必须真的调用文档转换引擎否则只是把文本命名成.docx打开就报错。至于有道云笔记里把 Markdown 转流程图这是编辑器自带功能入口在工具栏的流程图或画图菜单插入后填写节点和连线即可但流程图生成后在不同平台之间兼容性差建议在文档里同时保留备用的文字说明。4.4 把网页保存成 Markdown从浏览器插件到 Agent Skill遇到一篇好文章想存进笔记但又不想复制乱糟糟的网页源码于是“网页转 Markdown”成了高频需求。最简单的是浏览器插件推荐 Markdown Web Clipper、简悦和印象笔记的剪藏功能。它们的思路类似读取网页正文区域过滤广告和导航输出成干净的 Markdown然后手动或自动存到本地或云端笔记。简悦还支持自定义解析规则对结构复杂的页面更友好。再进一步这个动作也可以封装成一个 Agent Skill。我试过的流程是给智能体一个指令“把当前页面存成 Markdown 并写入 Obsidian 目录”它内部先读取网页正文清洗标签然后按照项目约定的模板输出标题、正文、链接、图片位置最后写入.md文件。实现重点在于给智能体约定一套稳定的输出协议比如标题使用#正文段落之间空行所有图片使用相对路径并下载到同目录 assets遇到表格必须用 Markdown 表格语法。这种做法适合平时收集资料量大、需要固定格式的人稍微配置一次之后就是一句话的事。需要提醒的是无论用什么方案保存的都应是你有权访问和保存的内容同时注意版权和合理引用。4.5 GitHub 上的 Callout 提示块语法如果你经常在 GitHub 上写 README 或项目文档肯定见过那些带颜色的提示块。这其实是 GitHub 扩展的 Callout 语法写法是在引用块的基础上加一个标签 [!NOTE] 这是普通提示。 [!WARNING] 这是警告需要注意高风险内容。 [!CAUTION] 这是严重警告可能带来不可逆影响。GitHub 目前支持的标签包括NOTE、TIP、IMPORTANT、WARNING、CAUTION分别对应信息、贴士、重要、警告、严重警告。渲染后在页面上会显示不同颜色的框非常醒目。这个语法的优点是纯文本可读不依赖图片缺点是只有 GitHub 等少数平台支持在 Typora、语雀等编辑器里可能只会显示成普通引用块所以不要把关键信息只放在 Callout 里正文里的说明仍是必需的。5. 常见问题与排查我把自己踩过的坑都列出来了5.1 换行不生效这是新手问得最多的一个问题。原因通常是你直接按了一次回车Markdown 认为这还不够形成新段落。排查思路是先看渲染结果是否只是多了一个空格如果是就在段尾加两个空格或br或者干脆把两段之间加一个空行。记住不同平台的换行规则略有差异在 Typora 里用一个回车会被当成分段在 GitHub 上单回车不会换行必须空一行或者用br。所以写文档的时候我默认遵循“段间空行”规则这样在任何平台都不会出错。5.2 图片不显示图片不显示九成是路径问题。先确认图片文件是否真的存在于你写的路径里再确认是相对路径还是绝对路径最后检查文件名里是否有中文、空格或括号。Windows 用户还有一个常见坑路径里用了反斜杠\在 Markdown 里\是转义符号建议全部改成/。如果你用的是 Obsidian还要注意附件路径设置是否和编辑器一致不然本地看得到、换了设备就失效。实在排查不出来把图片地址放到浏览器地址栏打开看能否访问能访问就是语法问题不能访问就是路径问题。5.3 表格复制到 Excel 乱、公式显示成源码表格复制到 Excel 乱的原因是 Excel 没有识别管道符作为分隔符。解决办法前面已经说了最稳的是用 Pandoc 转 CSV 或使用“自文本/CSV 导入”。公式显示成源码基本是渲染引擎没开启或语法被转义。检查美元符号前后是否有空格检查是否在代码块里写公式检查编辑器是否支持 LaTeX。如果是公众号等平台很多编辑器并不支持公式渲染这时候可以把公式用图片代替或者截图贴进去虽然不优雅但能解决问题。5.4 不同平台渲染差异可能造成“标准答案”不通用Markdown 的底子虽然统一但扩展语法和默认行为并不完全一致。GitHub 支持 CalloutTypora 有自己的一套目录和引用处理语雀、有道云笔记又各有差异。所以我给团队和个人的建议是核心文档只使用最基础的语法也就是标题、段落、列表、引用、链接、图片、代码块、表格这些在任何平台上都是最稳定的花哨的扩展语法只在明确知道目标平台支持时才使用。这样写出来的文档才真正具备可迁移性。我个人在实际操作中的体会是Markdown 的上手曲线非常平缓真正的分水岭在于你是否愿意在日常文档里坚持用它。我现在写任何长文档都会先在 Markdown 里只写文字大纲不碰任何样式标题统一用##等内容全部定稿后再回头调整层级和补充图片最后用 Pandoc 导出 Word 或 PDF。这套流程看起来没什么技术含量但真的帮我省了大量时间。如果你刚开始学别急着把各种插件全部装上先用系统自带的记事本写一个礼拜基础语法再到编辑器里渲染你会对 Markdown 的“纯文本”本质理解得更深。这大概就是跟狂神学的最大收获不是背语法而是建立一套高效率、可复用的写作习惯。