markdown语法vs日常语法

判断一段文字应当采用 Markdown 还是日常语法，只看最终载体是否需要被工具解析。需要发布到 GitHub、技术文档平台、笔记软件并渲染为格式化内容时，用 Markdown；只在聊天、邮件、便签或自然段落中供人阅读时，用日常语法。二者不是修辞风格的差别，而是“是否包含机器可识别的标记”。

目标差异：机器解析与自然沟通

Markdown 的最小单位是“标记 + 内容”，例如 `# 标题` 中的 `#` 是语法标记，渲染后不显示。日常语法的最小单位是句子、标点、语气，服务于人的直接理解，不依赖渲染步骤。判断标准很简单：

• 文字最终要变成网页、README、issue、笔记正文，就按 Markdown 规则书写。
• 文字只在微信、邮件、便签、正式信函中直接阅读，就不应加入 `#`、`**` 等标记；原文应保持自然可读。

不要在同一段文字中混用两套规则：日常聊天里写 `重点` 不会自动加粗，只会留下星号。

标题与层级：`#` 不是重点装饰

Markdown 中 `#` 到 `######` 表示标题层级，层级应当连续，不跳级。一个文档通常只用一个一级标题，主要分节从二级标题开始。例如：

项目说明

安装

使用

日常写作里，标题靠“一、二、三”、居中、加粗或字号体现，不需要行首 `#`。如果一段文字最终可能进入 Markdown 环境，行首写 `# 注意` 会被渲染成标题；如果只是日常表达，应改为“注意：”或自然句。写技术文档时，先列标题大纲再填段落，可避免层级混乱。

列表与段落：项目符号不是自然断句

Markdown 列表用于结构化条目，渲染后自动加符号或编号。无序列表统一用 `-`，有序列表用 `1.`、`2.`。嵌套列表缩进 2 至 4 个空格。日常语法中列举常用“第一、第二”“首先、其次”或逗号分句，不必行首加 `-`。 可执行建议：

• 需要渲染为清单、步骤、任务时，使用 Markdown 列表。
• 日常邮件或聊天中列举，优先用自然句；行首 `-` 在纯文本环境中看起来像分隔符，但不具备格式意义。
• 任务列表 `- [ ] 待办`、`- [x] 完成` 属于 GFM 扩展，CommonMark 不原生支持；跨平台前需确认目标环境。

同一份文档中，不要把列表当作“每行加一个短横线”的排版手法，而应考虑条目是否真的并列、是否适合被解析为列表。

强调与引用：标记符号不能替代语气

Markdown 用 `粗体`、`斜体` 表示强调，用 `>` 表示引用块。日常语法则通过“值得注意的是”“所谓”“引号”“破折号”等修辞和标点传达语气。两者不能直接互换。 使用规则：

• 最终需要渲染出加粗、引用样式时，使用 Markdown 标记。
• 纯文本交流中不要堆叠 `**` 或 `>`，因为读者看到的是原始符号，不是渲染效果。
• 中文正文中的引号、书名号不会被 Markdown 解析为标记，但行首 `>` 会变成引用块；在支持 Markdown 的评论或文档中引用他人内容时，要意识到这一差异。

空格与换行：分段规则更严格

日常写作中，换行往往表示语气停顿或视觉分段；但在多数 Markdown 实现中，单个换行不会被渲染为新段落。CommonMark 规定段落之间用空行分隔；若要在同一段落内强制换行，需在行尾加两个空格或反斜杠。 例如： 第一行 第二行 渲染后可得到同一段落内的换行。不同平台可能略有差异，但“空行分段”是通用规则。写 Markdown 时，不要靠单个换行分段，也不要连续使用空格或 Tab 模拟缩进；需要缩进用列表或代码块。

特殊字符与转义：显示原义需要额外处理

Markdown 中 `#`、``、`_`、`>`、`-`、`[`、`]`、`(`、`)`、`|` 等符号可能触发语法解析。如果要显示这些符号本身，应使用反斜杠转义，例如 `\#`、`\`，或用行内代码包裹。表格单元格中的 `|` 应写成 `\|`。 日常写作中这些符号没有解析风险，但如果文本可能被粘贴进 Markdown 编辑器、GitHub issue 或技术文档，应提前处理。一个可行步骤：写完自然段后，检查行首是否出现 `#`、`>`、`-` 或数字加点，再决定是否转义、改为全角符号或调整措辞。

小结

选择 Markdown 还是日常语法，不取决于内容长短或正式程度，而取决于最终载体是否经过渲染。技术文档、README、笔记导出场景使用 Markdown；人际沟通、纯文本消息使用日常语法。混用时先确认目标平台：支持 GFM 的环境可扩展任务列表、表格，普通 CommonMark 环境则保持基础语法。最稳妥的做法是：让机器读到的文字包含标记，让直接读到的文字保持自然。