解读

面试官问“CouchDB 如何支持 GDPR 删除”，并不是想听“把文档删掉就行”这种表面答案，而是考察候选人能否把欧盟通用数据保护条例（GDPR）第17条“被遗忘权”的合规要求，映射到 CouchDB 的分布式、多版本、离线同步架构上，并给出可落地、可审计、可验证的技术方案。国内出海业务、跨境电商、SaaS 服务同样面临 GDPR 合规审计，答不出“彻底擦除+不可恢复+审计链”三点，基本会被判不及格。

知识点

1. GDPR 删除三要素：数据主体身份识别、数据彻底擦除（Right to Erasure）、可审计证明（Accountability）。
2. CouchDB 核心机制：_id 唯一键、MVCC（_rev 版本链）、B+Tree 文件追加写、compaction 清理、_deleted 墓碑标记、多主复制、本地/远程 _changes 订阅。
3. 国内合规落地要点：数据跨境传输评估、个人信息保护法（PIPL）对标 GDPR、删除操作日志留存≥3 年、加密密钥同步销毁。
4. 技术风险点：离线副本、历史备份、PouchDB 同步端、对象存储快照都可能成为“复活”来源，必须纳入删除范围。

答案

要在 CouchDB 体系里真正满足 GDPR 删除，需分五步实施，每一步都留下可审计日志：

1. 身份定位
   利用 view 或 Mango 索引，把涉及该数据主体的全部文档 _id 列表拉出来，包括用户主文档、订单、日志、附件。输出结果写入删除任务单（含时间戳、操作人、工单号），先落库再执行，方便后续审计。

2. 逻辑删除 → 物理擦除
   对每条文档执行 PUT {doc} 设置 "_deleted":true，这一步只是打墓碑。紧跟着在库层面触发手动 compaction（POST /{db}/_compact），把墓碑与旧版本从 .couch 文件里真正回收；若磁盘启用了加密（clustered db 加密或 LUKS），回收即视为“不可恢复”。国内机房若使用对象存储做备份，需同步发起生命周期过期策略，把七天内的备份也清掉。

3. 复制链同步删除
   在多地多活架构里，用过滤复制（filtered replication）把删除记录写成一条特殊文档 {"type":"gdpr_erase","subject_id":"xxx","erase_rev":3}，推送到所有边缘节点；边缘节点收到后，本地执行相同 compaction，保证离线节点上线后也能在第一次同步时完成擦除。整个流程通过 _active_tasks 接口轮询，100% 返回 "changes_done":0 才视为同步结束。

4. 附件与衍生数据
   如果文档含 _attachments，先调用 DELETE /{db}/{doc}/{att}?rev={rev} 逐个删附件，再删文档；对于视图索引（_design/views）里曾出现的用户邮箱，需要重建视图以清除索引段中的残留值，否则审计扫描仍可能命中。

5. 出具删除报告
   把步骤 1~4 的截图、compaction 完成日志、备份清理工单、边缘节点回执打包成PDF 删除报告，存入只读 MinIO 桶，报告哈希写入区块链存证（国内可用 BSN 文昌链），应答数据主体或欧盟监管时一键提供。至此，**“不可检索、不可访问、不可恢复”**三条件全部满足， GDPR 删除闭环完成。

拓展思考

如果面试官继续追问“用户要求只删部分字段而不是整文档，怎么做？”，可回答：
CouchDB 文档级 MVCC 不支持子字段原地擦除，此时采用**“重写文档+旧版本 compaction”策略：先读出最新版本，把敏感字段置空或打掩码（如 "email":"gdpr_erased_3f4a@"），用新 _rev 写回，再对数据库做 compaction，确保旧版本物理消失；同时把字段名写入敏感字段白名单视图**，后续定期扫描，防止业务代码再次写入相同字段。该方案同样适用于**国内 PIPL 的“去标识化”**要求，兼顾性能与合规。