企业官网建设流程全解析

写Markdown编辑器相关的内容，说实话能在网上搜到一堆教程，但绝大多数都在讲语法，很少有人讲"用起来会踩哪些坑"“换电脑之后图片怎么全裂了”“表格复制到Excel怎么全乱了”这类实操问题。这篇我尽量把编辑器的选择、语法里容易翻车的细节、图片路径、格式转换、高级玩法串起来写，都是这几年实际用出来的经验。

1. 编辑器选型：本地、云端、免费还是付费，别被热度带着跑

很多人入坑Markdown的第一件事是搜"md文件编辑器""markdown编辑器哪个好"，结果被各种推荐列表搞得更晕。我的建议很直接：先想清楚你的主要使用场景是纯本地写作、多设备同步，还是团队协作，再决定工具，而不是看哪款编辑器下载量高。

1.1 本地派：Typora、Obsidian、VS Code，各有各的气场

本地编辑器里，目前讨论度最高的是这三款，但它们的定位差异其实非常大。

Typora走的是"所见即所得"路线，左边写右边直接渲染，特别适合写博客、记笔记、写文档这类以"写"为核心诉求的人。它的优点就是干净，没有多余的侧边栏和按钮，专注度很高。当前版本是收费的，买断制，一台机器一个授权，个人用下来的感受是值这个价。如果不想付费，也可以考虑开源的MarkText，界面和交互风格很接近，不过它的表格编辑、图片粘贴的稳定性稍弱一些，复杂文档偶尔会卡。

Obsidian的定位是"本地知识库"，它把Markdown文件组织成一个库，支持双链、标签、关系图谱。如果你记笔记的量很大，需要经常回看、关联、汇总，Obsidian比Typora合适得多。但有个容易被忽略的点：它默认使用自己的wiki链接语法（[[链接]]），如果打算把笔记导出成标准的Markdown发布，需要谨慎处理链接格式，否则换到别的编辑器里链接很容易失效。

VS Code严格来说不是Markdown编辑器，而是代码编辑器，但装上合适的Markdown插件后，它反而是很多开发者最顺手的写作工具。我用的是Markdown All in One加Markdown Preview Enhanced的组合，前者管语法辅助，比如自动生成目录、表格格式化，后者管预览渲染，支持流程图、数学公式、导出PDF。它的优势是写技术文档时可以同时看代码上下文，劣势是需要稍微配置一下，对纯写作用户来说门槛偏高。

1.2 在线协作派：语雀、Notion、飞书文档

如果你的文档需要多人同时编辑，或者要分享给别人看，本地编辑器会非常难受——文件发来发去，版本对不上。这个场景下，在线编辑器更合适。

语雀对Markdown的支持比较完整，支持公式、流程图、代码块高亮，团队的文档归档和目录组织做得很好，适合公司内部知识库。Notion的块编辑器和数据库功能很强，但严格来说它不是纯Markdown编辑器，导出时的兼容性有时会出问题。飞书文档的Markdown输入支持也很顺滑，适合已经在用飞书办公的团队。

个人经验是：如果内容属于自己的长期资产，比如技术笔记、个人博客草稿，我会放在本地编辑器里，用Git或者网盘做同步；如果是团队协作、需要评论和审批的文档，直接在线编辑，不要来回发文件。

1.3 我实际的选型组合

我现在的工作流是：博客文章和长文写作用Typora，个人知识库用Obsidian，技术方案文档也用Obsidian写完了定期归档，代码仓库里的README、开发文档直接用VS Code，同事协作文档走飞书。四个工具各干各的活，互不干扰。不要指望一款工具通吃所有场景，那只会让你在每个场景里都别扭。

2. 语法细节里的高频坑：换行、表格与数学公式

Markdown语法本身非常简单，一小时就能上手。但"会语法"和"用得顺"之间隔着很多细节，下面这几个是我看到身边朋友摔过跟头、也是搜索热度居高不下的点。

2.1 换行的两种规则：为什么我按了回车，渲染出来还是连在一起

这是新手最容易懵的地方。在绝大多数Markdown编辑器里，你在段落中间按一次回车，渲染出来的效果是"换行但不分段"——两行文字会紧挨着，中间没有空行。想要真正分段，有两种做法：

• 在上一行结尾连续敲两个空格，再回车，会在同一段落内强制换行；
• 在两个段落之间空一行，才能产生段落分隔。

Typora默认是"回车即分段"，它把回车直接映射成了两个空格加换行，所以新手用Typora习惯了之后，换到其他严格遵循CommonMark规范的编辑器（比如GitHub、语雀、很多在线编辑器）时会发现：以前写的文档，贴过去之后段落全挤在一起了。这是一个非常典型的"编辑器救了你，但让你失去了兼容性"的案例。

我的建议是写文档时尽量用空行分段，不要依赖行尾两个空格，这样文档在任何平台、任何编辑器里打开，排版都不会乱。尤其准备发布到博客或GitHub的文档，一定要养成空行分段的习惯。

2.2 表格：写起来不难，复制出去才是真麻烦

Markdown表格的语法很直观：

| 列1 | 列2 | 列3 | | --- | --- | --- | | A | B | C |

分隔行中的---控制对齐方式：默认左对齐，:---:居中，---:右对齐。实际使用中，表格的坑不在"怎么写"，而在"写完之后怎么把数据弄出去"。

举个例子，你辛辛苦苦写了一张10列20行的Markdown表格，想复制到Excel里继续处理。直接全选复制粘贴，大概率会得到一坨乱掉的数据，列错位、表头丢失、多出空格都有。原因在于Markdown表格本身没有真正的单元格语义，渲染出来之后复制的是纯文本，制表符和分隔线的解析规则在每个软件里不一样。

解决思路后面第4章单独展开，这里先记住一个结论：不要直接复制粘贴，用工具做转换，保住数据结构。

2.3 数学公式：论文党和笔记党的刚需

如果你的文档里有数学符号需求，需要在编辑器的设置里开启"行内公式"或"数学公式"支持。

• 行内公式用单个美元符号包裹：$a^2 + b^2 = c^2$；
• 独立成行的公式用双美元符号包裹：$$E = mc^2$$。

这里有一个隐蔽的问题：在严格Markdown规范里，$符号本身并没有特殊含义。所以如果你在纯CommonMark环境里写$100和$50，它不会当作公式，但如果编辑器开启了数学扩展，某些情况下$100会被误判为公式开始，导致渲染异常。这种情况在语雀、Obsidian这类对公式支持激进的编辑器里偶尔会出现。规避办法是涉及货币符号时，用反引号包一层行内代码，明确告诉渲染器"这不是公式"。

3. 图片路径问题：从"本机能看别人看不到"到"换机裂图"

图片问题是我看到提问频率最高、也最让人头疼的一类。典型症状有两个：一是文档发给别人之后对方看不到图片，二是自己把文件夹挪了个位置再打开，图片全裂了。

3.1 相对路径 vs 绝对路径：一张图能否跟随文档移动

Markdown引用图片的语法是![](图片路径)，关键在于路径的写法。

绝对路径写的是电脑上的完整地址，比如C:/Users/Name/Pictures/图1.png。这种写法在当前电脑上没问题，但文档一旦换台电脑、发给别人、上传到博客，路径就失效了，因为对方的电脑上不存在这个路径。

相对路径则是相对于当前文档所在目录的地址，比如在docs文件夹下有一个img子文件夹，文档里写![](img/图1.png)，那么只要整个docs文件夹整体搬迁或打包，图片路径就不会失效。这也是为什么所有严谨的Markdown最佳实践都推荐"文档和图片放在同一个项目目录里，用相对路径引用"。

3.2 Typora的图片配置：一次设置，省掉后面所有麻烦

Typora在这方面做了很好的支持。打开偏好设置，在"图像"一栏里可以进行全局配置。我的建议是：

• 插入图片时选择"复制图片到 ./img 文件夹"；
• 首选相对路径；
• 如果文档需要发布或被别人打开，勾选"对本地图片应用相对路径"。

这样每次粘贴截图时，Typora会自动把图片存到当前文档目录下的img目录里，并且在文档中写入相对路径。这个习惯养成之后，把整个文件夹压缩发给别人，对方解压打开，图片一张都不会少。

3.3 如果已经用了绝对路径，怎么批量补救

很多人是写了很多文档之后才发现问题，这时候一张一张改路径会崩溃。这里分享一个实际可用的补救方案：

用VS Code打开文档目录，搜索正则表达式，把!\[\]\(C:/Users/xxx/Pictures/之类的绝对路径前缀批量替换成![](img/，替换前先备份。更稳妥的做法是先把所有图片集中拷贝到文档目录下的img文件夹里，再执行批量替换。这条我踩过坑，血的教训是：编译之前一定要先复制图片，别替换完才发现文件根本没拷过来。

Obsidian用户还经常遇到另一个问题：笔记里插入图片后，路径变成![](attachments/未命名.png)这种库内路径，导出成单文件时图片路径又失效了。Obsidian社区里有一堆导出插件专门处理这个事情，核心原理就是把附件复制到导出目录并重写路径。遇到这种情况，说明你要做的不是改路径，而是选对导出工具。

4. 格式转换与发布：从Markdown到Word、Excel和公众号

Markdown写起来舒服，但最终交付的时候，别人可能要Word，要Excel表格，要公众号推文。这一章讲三大高频转换场景。

4.1 转Word：为什么Pandoc是绕不过去的工具

Markdown转Word，绕不开Pandoc。它是目前最稳定的文档格式转换工具，一条命令就能搞定：

pandoc input.md -o output.docx

这条命令执行之后，你的Markdown文档就会变成一个还不错的Word文档，标题、列表、代码块、粗体斜体都会被正确映射为Word样式。

但直接这样生成的Word有一个明显毛病：中文字体丑、表格样式简陋、标题颜色发蓝。解决办法是用一个自定义的Word参考模板。先让Pandoc生成一份默认的最大的参考文档：

pandoc -o custom-reference.docx --print-default-data-file reference.docx

然后你把这个reference.docx打开，在Word里调整标题的字体（比如改成"微软雅黑"）、正文的行距、表格的边框样式，保存后，以后每次转换都带上这个模板：

pandoc input.md -o output.docx --reference-doc=custom-reference.docx

这样一来，生成的Word文档样式就和你调整过的一样了，不用每次手工微调。

4.2 表格转Excel：别指望复制粘贴

关于表格，搜索热词里常年挂着"markdown表格转换excel"和"markdown表格复制"。前面说过，直接复制粘贴会乱，正确的姿势有三种：

第一种，用Pandoc转成带表格的docx，再在Word里全选表格复制到Excel，格式基本能保留。

第二种，把Markdown表格转成CSV格式。很多在线工具支持直接输入Markdown表格输出TSV/CSV，TSV是制表符分隔的，复制到Excel里通常能正确分列。

第三种，如果你只是偶尔处理一张表，可以用Typora打开文档，选中表格后右键，看是否有"复制为"的选项，不同版本位置不一样。总体而言，涉及表格的结构化数据流转，走"Markdown转CSV再导入Excel"这条路是最稳的。

4.3 公众号文章排版：Markdown到富文本的最后一公里

公众号编辑器对Markdown的原生支持几乎为零，写公众号还得用富文本。但Markdown写稿效率高、代码块和引用格式统一，所以很多人会先在本地用Markdown写，再做格式化后粘贴到公众号编辑器。

正经的做法是使用在线排版工具，原理是：你粘贴Markdown文本进去，它渲染成带样式的HTML，再把渲染后的内容复制到公众号编辑器里，样式基本能保住，代码块会有专门的背景色和等宽字体。这类工具搜索"markdown公众号排版"就能找到，选一款顺手的即可。用这类工具记得把标题颜色和强调色调整成和公众号定位一致的风格，排版出来会更统一。

5. Mermaid、思维导图与自动化：Markdown的高级玩法

基础语法用熟之后，可以解锁一批进阶玩法。这一章讲几个我实际用下来觉得值得尝试的方向。

5.1 Mermaid离线编辑器：让流程图沉淀进文档

Mermaid是一种用文本描述流程图、时序图、甘特图的语法，可以直接嵌在Markdown代码块里：

```mermaid graph LR A[开始] --> B{处理数据} B -->|是| C[输出结果] B -->|否| D[报错退出]

支持Mermaid的Markdown编辑器会自动渲染成漂亮的图，这样流程图就不再是一张无法修改的截图，而是可以随文档版本一起维护的文本。这个特性对写技术方案、做故障复盘特别有用。 搜"mermaid离线编辑器"的人，多半是遇到了在线渲染依赖外网或内网受限的问题。离线场景下我建议装mermaid-cli，它能通过命令行把Mermaid代码渲染成图片或PDF，命令大致是：

mmdc -i diagram.mmd -o diagram.png

这样在完全不联网的环境里也能生成流程图图片，适合内网文档或离线工作环境。 ### 5.2 思维导图：用markmap把大纲变成导图 Markdown本身就有天然的层级结构（多级标题、列表），所以很适合生成思维导图。markmap这个工具可以直接读取Markdown文件，按标题和列表层级生成一张可交互的思维导图。安装方式一般是：

npm install -g markmap-cli

然后执行：

markmap input.md -o output.html

生成的HTML用浏览器打开就是一张可以折叠展开的思维导图。我的习惯是先拿Markdown写会议纪要或读书笔记的大纲，然后一键生成导图用于汇报展示，比在绘图软件里手动画结构快很多。 ### 5.3 自动化工作流：把Markdown接进文档管道 现在很多自动化平台和低代码工作流都支持直接接收和输出Markdown。比如把Markdown内容接入一个处理流程，让程序自动帮你做结构化整理、翻译、摘要，再生成一份新的文档输出，整个链路都是文本流转，非常顺滑。 具体到"markdown转word工作流coze"这类需求，思路也很简单：先写一篇Markdown格式的草稿，把草稿作为一个输入块，交给自动化流程去做格式化或补充润色，最后让流程输出一个标准文档文件。关键点在于：Markdown是纯文本，结构化程度高，非常适合作为自动化管线的中间格式。搞清楚这个逻辑，你就能举一反三，把Markdown接入各种自己需要的管道里。 ## 6. 我用了五年Markdown之后的一些心里话 写到这里，把几个容易忽略但影响体验的细节再集中补充一下。 第一个是关于Markdown文件的"生命周期"。既然选择了Markdown，就要接受它是纯文本、可长期保存的。但它不像Word那样自带样式资产，你的排版风格、图片管理、引用关系都分散在辅助工具里。所以建议从一开始就做好目录规划：每个项目一个文件夹，文档放根目录，图片放`img`子目录，这是成本最低也最可靠的长期方案。 第二个是别忘了解析器不一致的问题。同一个md文件在Typora里显示正常，放到GitHub上可能表格渲染就怪了，放到某些在线编辑器里可能公式不显示。原因在于Markdown有不少方言扩展。如果你要发布到多个平台，写的时候尽量只用通用语法，扩展语法在最终发布前检查一次渲染效果，能做到少返工。 第三个是养成定期备份的习惯。Markdown是本地文件，没有自动云同步，一旦硬盘坏了什么都没了。我用的是Git仓库归档加网盘同步双保险，Git负责版本历史，网盘负责异地容灾，两个都不复杂，但缺一个都可能在某一天让你欲哭无泪。 最后分享一个小技巧：如果你经常写包含大量外部链接的文档，可以考虑在标题处用脚注代替直接在正文里堆链接，正文看着干净，链接统一收在文末。这个习惯我是在写技术周报时养成的，读起来体验好了不少。 Markdown是一款"越用越爽"的工具，前提是你把前面的这些细节理顺。选对编辑器、搞清换行和表格的规则、管好图片路径、用对转换工具，这些基本功到位了，写作这件事会轻松一大截。