上个月陪一家婚介机构过合规检查，检查人员翻到一条两年前的注销记录，只问了一句：这位会员的身份证照片、婚况证明、聊天记录，现在系统里还找得到吗？负责人当场没答上来。这个问题后来变成我们升级婚恋系统的一个专项，题目就一句话——服务终止之后，会员数据到底怎么处理。
多数做婚恋系统的团队，第一反应是把注销写成一条 DELETE，代码一行，问题结束。真做起来才发现，删除是整个生命周期里最简单的一段。难的是三件事：删之前的封存怎么做、备份里的残留怎么处理、删完之后拿不拿得出证据。这三件事任何一件没想清楚，检查时都会变成回答不了的问题。
把留存期限写成配置，而不是代码
婚恋系统里不同字段该留多久，答案不一样。身份证影像这类敏感资料，服务终止后保留期要短；聊天记录涉及纠纷举证，可以放长一点；行为日志又能更长。与其在代码里写死，不如落一张策略表：
CREATETABLEretention_policy(policy_idINTPRIMARYKEY,data_domainVARCHAR(32)NOTNULL,-- id_card / profile / chat / payment / log retain_days INT NOT NULL, -- 服务终止后保留天数 action ENUM('erase','anonymize','archive') NOT NULL, grace_days INT NOT NULL DEFAULT 0 -- 反悔窗口);注册环节给每个会员挂上对应策略，注销那一刻不用现算，调度任务直接按 retain_days 排期。期限做成数据还有个好处：整治要求在变，改一行配置就能生效，不用等发版。
有个字段容易被忽略：支付与订单记录。按财务相关法规，交易凭证有自己的法定保存年限，不能跟着会员注销一起删。所以 payment 这个域的 action 应该是 archive 而不是 erase：先脱敏关联人信息，凭证本身归档保留。这也是婚恋系统和普通社区类产品在删除设计上的一个显著差异：账户没了，账还得在。
备份是删除最容易漏掉的死角
删完线上表，先别急着宣布结束。婚恋系统里最敏感的就是身份证影像和婚况证明这几张表，昨晚的全量备份、上个月的归档里，它们多半还在。婚恋系统的备份轮转周期如果是 30 天，一次“彻底删除”实际要到第 31 天才真正生效，这段窗口期得如实写进隐私政策，对外承诺“即时删除”是给自己挖坑。
我们把整个生命周期画成一张图贴在工位上：
有个实现细节容易踩坑：归档库的索引键要和线上主键解耦。要是归档记录还指着线上 user_id，删掉线上记录之后，归档反而失去寻址依据，后续按期清除就成了空话。
逻辑删除也值得一提。很多婚恋系统用 is_deleted 标记代替真删，这对日常运营没问题，但不能算完成删除义务——标记位一去掉数据就回来了。合规意义上的删除，最终一定要走到脱敏或清空那一步，逻辑删除只能算过程中的封存手段。
脱敏要做幂等，还得留一点可识别性
反悔窗口内会员随时可能撤销注销，所以到期后的默认动作不是物理删除，是脱敏：
defanonymize(user):salt=get_env("ERASURE_SALT")user.nickname="已注销用户"user.phone_hash=hmac_sha256(user.phone+salt)[:16]user.id_card=None# 影像类直接清空，不留可恢复副本 user.save()用 HMAC 而不是明文替换，是为了保留一层"同一自然人"的识别能力：有人注销半年后又用同一个手机号注册，系统靠 phone_hash 能认出这是老会员，把历史标签接回去，但谁都还原不出原号码。影像类字段不参与这套逻辑，直接清空。
幂等是另一个必须满足的性质：调度任务重跑、服务重启之后，同一个会员的脱敏动作执行两次，结果必须一致。第一次执行后原始字段已经不在了，第二次再跑等于对空值操作，只要函数里没有"读原文再变换"的隐藏依赖，就不会出错。我们的做法是脱敏函数只依赖当次入参，不回查任何原始表，重跑一百遍结果也一样。
反悔的处理倒简单：撤销注销的会员按重新注册走实名认证，原数据不还原。反正影像已经清了，想回来就重新提交材料，流程和新人一样。这样避免了"删除又恢复"这个在工程上极易出错的路径。
台账是做给检查看的
每一次清除都要落一条 erasure_log：谁发起、依据哪条策略、覆盖哪几个数据域、几点执行、备份侧何时到期。字段设计和核验留痕一个思路：状态、时间、操作人、渠道四要素齐了，检查时才调得出证据。
婚恋系统的导出接口也应该接上同一张台账，内部人员导了什么、导了多少行、给谁用，事后可追溯。多地整治方案里"内部人员私自导出、备份、转发会员资料"已经被点名，这条台账算是一并交卷。
还有一点：台账自己也要有保留期，而且应该比它记录的数据活得更久。数据删了、台账还在，才能证明"我们按规则删过"；台账跟着数据一起没了，检查时又回到说不清的起点。
复盘
这套东西拆开看不复杂：策略表一张、调度任务一个、脱敏函数一个、台账一张。真正要想清楚的是“删除”这个词对外对内的含义不一样。对用户，它是点完按钮立刻生效的感知；对系统，它是跨备份周期的漫长过程。婚恋系统处理的是最敏感的一类个人数据，把这个过程做实，比多上十个匹配功能都值。
写在最后：文中方案来自我们在婚恋行业 SaaS（云中红线）的一线实践，欢迎交流。
