2.2 删除线与任务列表

2.2 删除线与任务列表

双波浪线包裹文字得到删除线，方括号加空格或 x 构成任务项。这两个语法都来自 GFM 扩展，体量小、出场率高，合在一节正好练完。

删除线：保留痕迹地划掉

旧方案 ~~每周手动备份~~ 已改为每日自动备份。
​

渲染后"每周手动备份"带横线划掉。它的价值不在"删"，而在"让你看见删"——变更记录、价格更新、勘误，都适合保留原文加删除线再补新文。直接删掉旧内容当然干净，但读者就失去了"改了什么"的信息。

两个边界要知道：

1. 删除线是 GFM 扩展，个别严格 CommonMark 环境不渲染（第 4 章细说方言差异）。
2. 波浪线要成对紧贴文字，~~ 文字 ~~ 带空格可能失效。

任务列表：会打勾的清单

## 发布前检查
- [x] 代码评审通过
- [x] 文档更新
- [ ] 回归测试
- [ ] 灰度放量
​

渲染成带复选框的清单，已勾选项显示对勾。注意结构：方括号内必须是单个空格或小写 x，[X] 大写在多数实现里也能识别，但统一小写最稳；方括号前的 - 或 1. 不能省。

任务列表的巧妙之处在于渲染产物是真正可交互的复选框——在支持的平台（如代码托管仓库的 issue 列表、笔记应用）里，点击即改写源码里的空格为 x。写作时它是进度展示，协作时它是轻量看板。

任务列表 vs 普通列表的选择

模糊的"考虑一下、调研下"型条目我建议别进任务列表——没有完成判据的待办只会永远躺着，勾不动的复选框是负面激励。

⚠️ 常见坑：任务列表嵌套在普通列表项下时，缩进同样要对齐父项文字列，规则与 1.3 节完全一致。

组合练习：一份变更纪要

> 变更纪要 v1.2

- ~~关闭注册入口~~（v1.1 的临时措施）
- ~~限制每日发帖数~~（v1.1 的临时措施）
- [x] 上线验证码服务
- [x] 解除注册限制
- [ ] 观察一周垃圾账号数据
​

删除线记录"曾存在、已结束"，任务列表记录"正在做、未做完"，普通文字记录事实——三种状态一次分层，这就是结构化表达的手感。

状态语法的时效责任

删除线与任务列表都是"带状态"的语法，而状态天然会过期，这带来一类普通列表没有的维护责任。任务列表最典型的腐烂形态是"僵尸勾"：文档里一排全勾的清单躺在那里数月，读者无从判断它还有没有参考价值。治理办法是给清单标注快照日期（"截至某日的发布检查单"），过期的整段移入带日期标题的历史章节，而不是原地更新让新旧状态混在一起。会议纪要里的任务列表则要写责任人——- [ ] 补齐监控面板 @张三，无主的任务等于没分配，这条纪律让纪要从"记录"升级为"跟踪"。

删除线的时效责任更微妙：它的语义是"此内容已废弃但留档"，但读者每次路过都要重新处理一遍"划掉的信息"这个认知负担。变更频繁的段落，删除线累积三四层后几乎不可读，此时应把过期的多轮修订收进文末"修订记录"小节，正文只保留最新表述加一条指向修订记录的说明。一句话概括两者的分界：近期的、需要被看见的变更用删除线；久远的、只需备查的变更归档。任务列表同理——活跃项目的看板留在正文，完结项目的清单归档。状态语法的价值全在"新鲜"二字，保鲜失效就该退场。

任务列表在团队流程中的真实位置

任务列表最出彩的场景不是个人待办，而是仓库内嵌的协作清单。GitHub 的 issue 与 PR 描述里写任务列表，完成一项提交一次代码，页面上的勾选状态随提交信息自动回写（配合"fix #12"一类关键字还能联动关闭 issue），项目面板随之刷新进度——这时任务列表是流程组件而不只是排版记号。用法纪律有三条：一，每项写动宾结构的完成判据（"补齐 redis 超时配置"而非"redis 的事"），勾与不勾才有客观界线；二，任务粒度对齐到"半天以内可完成"，粗了进度失真、细了维护负担；三，过期任务及时删除而不是留着打勾，满屏已完成项的清单和没有清单一样，都传递不了当前状态。

删除线与任务列表还有一个交叉用法值得知道：变更日志里"~~旧字段名~~ → 新字段名"的写法把删除线当 diff 视图用，评审者一眼看出改动前后。但这个用法只适合一行以内的短改动，大段删除内容划删除线留在正文里，读起来像满页伤疤，正确归宿是版本控制系统的 diff——文档里只保留结果态，历史交给 git。这也是一条更普遍的分界：Markdown 记录"现在是什么"，版本历史记录"曾经是什么"，两者混用会让文档以肉眼可见的速度腐化。

本节要点回顾

• 删除线 ~~文字~~：保留修改痕迹，适合变更与勘误。
• 任务项 - [ ] / - [x]：空格或小写 x，别丢列表标记符。
• 任务列表是交互组件，在支持的平台点击即回写源码。
• 有完成判据才进任务列表，否则用普通列表。

用一段源码固化本章上半场的写法

把删除线与任务列表放进同一段周报源码，对照渲染效果：

## 本周收尾
- [x] 下线旧版导出接口（`~~/export/v1~~` 已摘除流量）
- [x] 补齐缓存压力测试报告
- [ ] 与安全组确认新域名备案（责任人：李雷，截止周四）

## 变更预告
- 配置项 `max_retry` 将于下版改为 `~~3~~ 5`，理由见变更记录 A-112
​

这段源码里三个细节值得注意：勾选态用的字母是小写 x（大写 X 在 GFM 里也认，但部分渲染器不认，小写最稳）；删除线包住的旧值紧邻新值，形成"旧 → 新"的可读对照；未完成项后紧跟责任人与截止时间，任务列表因此具备了看板的全部要素。周报场景里这套写法的回报很高：上级扫勾选框即知进度，翻源码即知细节。

任务列表的勾选状态与数据流转

任务列表被平台回写源码这件事还有一层工程含义：文档即状态存储。勾选状态存在 Markdown 源码里而不是数据库里，意味着它随仓库版本化、可 diff、可 blame——谁在哪个提交勾掉了哪一项，历史一清二楚。团队利用这个特性可以做轻量流程：周会纪要的任务列表勾完即归档，下周新建，配合目录按日期命名，季度回顾时"哪几周完成了多少"直接数文件里的勾。代价是并发编辑会冲突，两人同时勾不同项尚可合并，同时勾同一项就是一次小冲突——高并发状态同步本来就不该用文档做，这是工具边界而非缺陷，认清边界才能用对工具。