2. 请求接收与验证：别让删除请求卡在第一关

数据删除请求处理，第一步往往最容易被忽视。我见过太多团队，把精力都花在后端删除逻辑上，结果请求入口乱成一锅粥。说白了，入口没管好，后面全是坑。

这一章，我们聊聊请求怎么收、怎么验、怎么设计表单。嗯，都是实操中踩过的坑。

2.1 请求渠道：你得让用户找得到你

用户想删数据，首先得知道往哪儿发请求。我个人习惯，至少开放三个渠道：

• 邮件渠道：最传统，也最通用。设置专用邮箱，比如 privacy-requests@company.com。别用客服邮箱混着收，我吃过这个亏——邮件淹没在几千封投诉里，根本翻不出来。
• 工单系统：适合有用户后台的产品。用户登录后，在「隐私设置」里直接提交工单。好处是自动关联用户ID，省去身份核验的麻烦。
• API 接口：面向开发者或合作伙伴。比如第三方平台要删除调用你 API 时产生的数据，总不能让人家发邮件吧？

2.2 身份验证机制：你怎么知道是「他」本人？

这是最头疼的环节。我曾经遇到一个案例：用户 A 发邮件要求删除用户 B 的数据，理由是「B 是我朋友，他让我帮忙删」。你想想看，这能信吗？

身份验证，核心就一句话：证明「请求者」就是「数据主体」。我常用的验证方式分三级：

这里有个坑：邮箱验证并不安全。我遇到过用户邮箱被盗，攻击者冒充用户发删除请求。所以对于高价值账户，我建议至少 L2 起步。

2.3 请求表单设计：少让用户填一个字

表单设计的原则很简单：用户想删什么，你让他选，别让他写。我见过最离谱的表单，就一个文本框，写着「请描述你要删除的数据」。结果呢？有人写「把我所有数据都删了」，有人写「删掉我上周三下午发的那个帖子」——根本没法自动化处理。

我推荐的表单字段如下：

• 必填字段：
  • 用户标识（邮箱/手机号/用户ID）
  • 删除范围（单选或多选：个人信息、订单记录、聊天记录、全部数据）
  • 删除原因（可选，但建议保留，用于内部统计）
• 可选字段：
  • 期望完成时间（实际上由 SLA 决定，但给用户一个心理预期）
  • 备注（特殊说明，比如「请保留我的订单记录，只删个人信息」）

代码示例？嗯，给你一个简单的 HTML 表单结构：

<form action="/delete-request" method="POST">
  <label>注册邮箱：</label>
  <input type="email" name="email" required>

  <label>删除范围：</label>
  <select name="scope" multiple>
    <option value="personal">个人信息（姓名、电话、地址）</option>
    <option value="orders">订单记录</option>
    <option value="all">全部数据</option>
  </select>

  <label>删除原因（选填）：</label>
  <textarea name="reason"></textarea>

  <button type="submit">提交删除请求</button>
</form>

2.4 请求接收后的自动响应

用户提交请求后，别让他干等。我习惯做三件事：

1. 立即发送确认邮件：告知请求已收到，附上请求编号和预计处理时间。
2. 自动去重检查：同一个用户 24 小时内重复提交相同范围的删除请求，自动合并。
3. 标记异常请求：比如同一个 IP 短时间内提交大量删除请求，标记为可疑，转人工审核。

我曾经遇到一个用户，连续提交了 17 次删除请求，每次只改一个标点符号。后来发现是脚本在刷接口。嗯，从那以后我加上了频率限制——同一个用户每小时最多提交 3 次。

2.5 避坑指南：我踩过的三个坑

• 坑一：表单字段太开放。用户写「删掉我所有数据」，但系统只删了个人信息，没删日志。后来审计发现日志里还有用户 IP，被罚了。所以表单里必须明确「删除范围」的选项，别让用户自由发挥。
• 坑二：验证通过后直接执行。有一次，验证通过后系统自动执行了删除，结果发现是用户配偶冒充的。后来我改成「验证通过后，先进入待处理队列，人工二次确认后再执行」。
• 坑三：忽略请求记录。早期没做请求日志，监管来查「你们处理过多少删除请求」，我拿不出数据。现在每个请求从接收到完成，全链路打日志，随时可查。

好了，请求接收与验证这块，核心就是三个字：收得进、验得准、记得住。下一章我们聊聊请求的优先级排序和 SLA 管理——那又是另一门学问了。