Markdown语法怎么学才高效，排版技巧有哪些？
Markdown的价值不在语法本身，而在于它能把内容和排版分开处理，让你专注于写，格式交给渲染器。多数人学Markdown只停留在加粗和标题，真正影响阅读体验的，是列表嵌套、代码块、表格对齐和跨平台兼容这些细节。
## Markdown语法学到什么程度才够用
这个问题没有标准答案，但有一个分水岭：能不能不看文档写出结构清晰的嵌套列表和代码块。
### 日常写作的核心语法
个人技术博客最常用的语法其实就那么几个，但每个都有容易踩的坑：
– 标题层级：`#`到`######`共六级，但博客正文建议从`##`起步。原因很简单，文章主标题（`#`）通常由博客主题模板自动渲染，正文再从一级标题开始会和页面标题打架。Hugo、Hexo、Typecho的默认主题基本都是这个逻辑。
– 有序与无序列表：`-`和`1.`是基础，嵌套时用两个或四个空格缩进。这里有个高频错误——列表项之间夹了空行，渲染器会把它当成“松散列表”，行间距突然变大。想紧凑就删掉空行，想宽松就保留，取决于你用的渲染器。
– 代码块：反引号围栏（三个反引号）加上语言标识，比如` “`python `。语言标识写对了，Prism.js或highlight.js才能正确高亮。写`c++`要写成`cpp`，写`c#`要写成`csharp`，否则高亮失效。
– 行内代码：一个反引号包住。注意，行内代码里如果出现反引号本身，需要用两个反引号包裹，比如“` “ ` “ “`。
– 链接与图片：`[文字](URL)`和``。图片的alt文字不仅是无障碍要求，也是SEO信号——搜索引擎会读取alt属性。写“截图”不如写“Typora实时预览界面”，后者有信息量。
### 容易被忽略的扩展语法
标准Markdown（CommonMark）没有表格、脚注、任务列表，这些是GitHub Flavored Markdown（GFM）和其他方言的扩展。个人博客如果用静态站点生成器，几乎都支持GFM，但发布到某些CMS平台时会被过滤。
– 表格：冒号控制对齐。`|:—|:—:|—:|`分别对应左对齐、居中、右对齐。表头分隔行里的短横线至少三个，少了不生效。
– 任务列表：`- [ ]`和`- [x]`。写教程时列检查清单很实用，但注意部分渲染器不支持，发布前先预览。
– 删除线：`~~文字~~`。GFM支持，CommonMark不支持。
## 个人技术博客用哪款Markdown编辑器合适
这是被问得最多的问题之一，直接说结论：Typora适合写作，VS Code适合代码和文档混排，Obsidian适合知识库管理。
### 三款主流工具的实际差异
| 维度 | Typora | VS Code | Obsidian |
|---|---|---|---|
| 定位 | 所见即所得写作 | 代码编辑器+插件 | 本地知识库 |
| 实时预览 | 无缝（输入即渲染） | 分屏或侧边预览 | 分屏预览 |
| 代码块体验 | 一般 | 最好，支持语言服务 | 较好 |
| 图片管理 | 可自动复制到指定目录 | 需插件或手动 | 内链式管理 |
| 价格 | 买断制，约89元人民币 | 免费 | 个人免费，商用收费 |
| 适合场景 | 纯写作、博客草稿 | 技术文档、含代码的文章 | 笔记串联、长期积累 |
Typora的买断制价格在近年来经历过调整，具体以官网为准。VS Code免费且插件生态完整，Markdown All in One和Paste Image两个插件装好，写含代码的技术文章效率很高。Obsidian的双链和画布功能对写系列教程有帮助，但导出博客时要注意图片路径和链接格式的兼容性。
### 平台兼容性怎么验证
写完的文章发布到不同平台，渲染结果可能不一致。验证方法很直接：把同一份`.md`文件分别粘贴到目标平台（掘金、CSDN、知乎、个人博客后台）的编辑器里，看三点——表格是否塌陷、代码块是否高亮、列表嵌套是否正确。
据GitHub官方文档说明，GFM是GitHub上的标准方言，但其他平台未必完整支持。业内专家指出，跨平台发布前用CommonMark在线预览工具（如spec.commonmark.org的dingus）跑一遍，能过滤掉大部分兼容性问题。
## Markdown排版怎么做出专业感
语法只是骨架，排版才是阅读体验的关键。个人博客最容易犯的毛病是“写完了就发”，段落密度、留白和视觉节奏全不管。
### 段落与留白的控制
一个可操作的经验：每段不超过四行。手机屏幕上超过四行的段落会形成视觉压迫，读者容易跳读。段落之间空一行是Markdown的基本规则，但很多人写列表和代码块前后忘记空行，导致渲染器把相邻元素合并。
标题上下也要留空行。`##`标题上方空一行、下方空一行，这是大多数渲染器的推荐写法，能避免标题被误识别为上一段的延续。
### 代码块的可读性优化
技术博客里代码块出现的频率最高，三个细节决定专业度：
1. 语言标识必须写。不写语言标识的代码块底色统一，没有语法高亮，读者扫一眼就想跳过。
2. 代码行长度控制在80字符以内。超过后移动端会出现横向滚动条，体验很差。长命令用“换行。
3. 代码块前后加一句说明。不要扔一个代码块就完事，前面用一句话交代“这段代码解决什么问题”，后面用一句话说明“输出结果是什么”。
### 表格的适用边界
表格适合展示对比信息，但超过五列在移动端就会挤压。个人博客的表格建议控制在三到四列，行数不超过十行。数据量大的话，拆成多个小表格或者改用列表。
另外，表格里不要塞长句子。单元格宽度有限，长文本会换行错位。需要解释的内容放在表格下方的正文里。
## 写博客时Markdown有哪些容易踩的坑
### 图片路径与链接失效
静态博客最常见的翻车现场：本地预览正常，部署后图片全部裂开。原因通常是用了绝对路径或本地文件路径。正确做法是用相对路径，并且把图片统一放在`static/images/`或`assets/`目录下，Markdown里写``。
Hexo用户注意：`source/images/`和`themes/xxx/source/images/`是两个位置，前者经过渲染后路径会变，后者直接复制。选一种坚持用，别混着来。
### 特殊字符转义
写C++教程时，`<`和`>`会被当成HTML标签解析。需要转义成`<`和`>`，或者用行内代码包起来。反斜杠“可以转义Markdown语法字符，比如`*`显示为星号而不是斜体。
列表符号和标题符号在行首也有类似问题，行首的`#`如果不想变成标题，前面加反斜杠或空格。
## Q&A：Markdown语法常见疑问解答
Markdown和Word排版有什么本质区别？
Word是所见即所得，格式和内容存在同一个文件里，复制粘贴到网页编辑器经常带一堆样式垃圾。Markdown是纯文本，格式用符号标记，内容和样式分离，同一份文件可以渲染成网页、PDF、幻灯片。代价是精细排版（比如复杂分栏、艺术字）做不了，需要CSS配合。
免费Markdown编辑器够用吗，和付费的差距在哪？
日常写博客，VS Code加插件完全够用，功能不比付费工具少。付费工具（如Typora）的差异主要在写作体验——实时渲染没有分屏割裂感，专注模式更沉浸。如果每天写几千字，这个体验差异值那个钱；如果一周写一篇，免费方案足够。
Markdown表格能不能合并单元格？
标准语法和GFM都不支持`rowspan`和`colspan`。需要合并单元格时，只能内嵌HTML的`