题目重点：题目公开 add/delete/get_todo/get_all 和 check_todo(id) 假设；先定 ID、生命周期、输出顺序与外部完成判定。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版每条 Todo 有唯一 ID、text、createdAt 和 deleted 标志；get_todo(id) 返回未删除项，get_all 按添加顺序。
- check_todo 是题面允许的外部依赖，不臆造它如何记录完成状态；若需要完成项筛选，可在读取时调用它。
解题路线
- 先签接口：add(id,text) 对重复 ID 返回错误，delete(id) 对未知/已删除返回 false，get_todo(id) 返回值或不存在，get_all 返回有序快照。
- 内部可用 ID→Todo 哈希索引配有序 ID 列表；删除用 tombstone 支持审计，若只需内存短生命周期可直接删除并另定义顺序。
- 完成状态与存在性分离：check_todo(id) 判断 done，但删除不等于完成；读路径要定义外部服务失败时返回 unknown 还是错误。
- 多线程更新时让 add/delete/get_all 的快照语义明确；若外部 check_todo 与本地状态不在同一事务，展示时间戳或版本。
手动走一遍
训练操作 add(7,‘report’)，check_todo(7)=false，get_todo(7) 返回 active；完成后 check_todo(7)=true 但 Todo 仍存在；delete(7) 后 get_todo(7) 不存在。完成和删除是两个不同维度。
规模与取舍
哈希索引 add/get/delete 期望 O(1)；get_all 至少 O(n) 输出，若含远程 check_todo 则还有 n 次调用或批量接口成本；题目未明确规模。
易错点与追问
容易失分的边界
- 把 check_todo 当 delete。
- 没问重复 ID、get_all 排序和删除后可见性。
- 每次 get_todo 全表扫描。
- 对外部完成状态失败没有策略。
继续深挖
- 如何获取 only incomplete？
- Todo 更新文本/优先级怎么办？
- 完成状态服务暂时不可用怎么办？
- 需要持久化/审计如何设计？
