删除线与下划线
删除线常被用来标注「这段内容已经过时」或「这个方案已被否决」，但它在 Markdown 里并不是基础语法，而是 GitHub 扩展语法的一部分。这一页会说明它的准确写法、哪些平台认得它，以及「下划线」这种想当然的写法为什么行不通。
~~这段文字显示为删除线~~某些渲染器可能不支持删除线（CommonMark 标准外扩展），在 GFM 场景下通常可用。
两段波浪号包住一段文字，就得到一条删除线，渲染出来是 <del> 标签：
这个功能~~已经废弃~~了。<p>这个功能<del>已经废弃</del>了。</p>删除线可以和其他行内语法叠加使用：
~~包含 **粗体** 的删除线~~<p><del>包含 <strong>粗体</strong> 的删除线</del></p>Markdown 语法里没有下划线。想表达下划线，只能借道内联 HTML 标签 <u>：
这是 <u>下划线文本</u>。<p>这是 <u>下划线文本</u>。</p>需要留意的是，不同渲染器对内联 HTML 的处理差别很大：不少平台出于安全考虑会过滤 <u>、<span> 这类标签，只保留少数几个「安全标签」，这时下划线就会凭空消失。文档若要跨平台发布，用删除线表达「作废」，而不是依赖下划线。
| 想要的效果 | 写法 | 渲染结果 |
|---|---|---|
| 删除线 | ~~文字~~ | <del>文字</del> |
| 下划线 | <u>文字</u> | <u>文字</u>，可能被过滤 |
| 粗体 | **文字** | <strong>文字</strong> |
删除线最典型的场景是标注已经废弃的功能、被否决的方案，以及修订记录里保留下来的旧描述。它属于「批注性」表达，读者扫一眼就知道这段内容不该照做。但要注意：删除线只说明「作废」，不说明「改用什么」。一份需要长期维护的文档，最好在删除线旁边补一句替代方案或废弃原因，否则读者只知道它没了，却不知道下一步该怎么做。
反过来，凡是仍然有效、读者需要照做的内容，就不要用删除线——把它留给真正作废的部分，整篇文档的可信度会更高。
| 写法 | 实际渲染 | 原因 |
|---|---|---|
~~文字~~ | 删除线 | GFM 扩展语法 |
~文字~ | 删除线（部分平台不支持） | 规范允许单个波浪号，但支持度差 |
~~ 文字 ~~ | 原样文字 | 波浪号与文字之间不能有空格 |
~~~~文字~~~~ | 代码块 | 四个波浪号是围栏代码块 |
~~文字（缺少闭合） | 原样文字 | 没有配对的结束波浪号 |
删除线是扩展语法，不是基础语法。 在只实现 CommonMark 的渲染器里，~~文字~~ 会原样显示出来，读者看到的是一串波浪号而不是删除线。跨平台发布时，要么确认目标平台支持 GFM，要么改用「已废弃」这样的文字说明。
把下面这句话改写成 Markdown，要求旧接口用删除线标出，新接口名保持正常。
旧接口 /v1 已于 2024 年废弃，请改用 /v2。解题思路：
删除线在 GitHub Flavored Markdown 中用两对波浪号 ~~文字~~ 表示。只用一对波浪号在部分平台不被识别，兼容性较差；新接口名是正常文字，不要加任何标记。
详细步骤：
- 旧接口
/v1用~~/v1~~标出，表示已废弃。 - 「已于 2024 年废弃」是普通说明文字，保持原样。
- 新接口
/v2是正常文字，直接写/v2，不加删除线也不加强调。 - 检验：渲染后旧接口带横线删除效果，新接口保持正常。
最终答案：
~~旧接口 /v1~~ 已于 2024 年废弃，请改用 /v2。读完这一页，你应当能写出删除线、知道它对应 <del> 标签，能解释为什么下划线必须借道内联 HTML 以及其中的风险，也能在删除线没有生效时立刻排查空格、波浪号个数和平台支持情况。接下来给文档标注作废内容时，你会优先选择兼容性和语义都最清楚的写法。