📚 课程目录第4章用户同意机制

4. 用户同意机制：获取、记录、撤回同意

用户同意机制，说白了，就是你要让用户明确地说一句“行”，然后你还得把这句话存好，最后用户说“不行了”的时候，你得让他能顺利收回。听起来简单？但在我做过的项目里，就属这里出的合规问题最多。

4.1 同意的三个核心问题

我习惯把用户同意拆成三个动作来看：获取、记录、撤回。这三个环节缺一不可。你想想看，如果你只实现了“获取同意”的按钮，但用户想撤回时找不到入口，那在 GDPR 或个保法下，你整套机制都是无效的。

环节	核心要求	常见问题
获取	明确、具体、自由给予	默认勾选、捆绑同意
记录	可追溯、不可篡改、有时效	日志不完整、缺少用户标识
撤回	和给予一样容易	撤回路径隐藏、操作复杂

4.2 如何在 API 接口中获取同意

API 设计层面，获取同意不能只是一个“POST /consent”就完事了。我见过很多团队把同意接口设计成 PUT /user/settings 里的一个字段，这其实很不规范。

我个人建议的做法是：为用户每一次同意操作设计独立的资源路径。举个例子：

# 获取同意 - 标准做法
POST /api/v1/consents
Content-Type: application/json

{
    "user_id": "u_abc123",
    "purpose": "personalized_recommendation",
    "data_categories": ["browsing_history", "purchase_history"],
    "consent_timestamp": "2025-02-20T10:30:00Z",
    "source": "checkout_page",
    "consent_version": "v2.1"
}

# 响应
HTTP/1.1 201 Created
{
    "consent_id": "cns_xyz789",
    "status": "active"
}

注意这里的 purpose 字段。你不能写“收集用户数据”这么笼统。为什么？因为用户根本不知道你具体要干嘛。我在项目里踩过这个坑——当时我们只写了一个“数据分析”的用途，结果法务同事直接打回来说：“数据分析”太宽泛，必须拆分。

4.3 如何记录同意

记录同意这件事，核心是不可篡改和可审计。你想想看，万一监管来查，问“这个用户到底有没有同意过？”你拿什么证明？

我建议的同意记录表结构如下：

字段	类型	说明
consent_id	UUID	全局唯一
user_id	string	用户标识
purpose	string	具体的处理目的
data_categories	JSON array	涉及的数据类别
status	enum	active / revoked / expired
granted_at	timestamp	同意时间
revoked_at	timestamp	撤回时间（可为空）
source	string	来源于哪个页面或接口
consent_version	string	用户同意的版本号

小技巧：建议把同意记录设计成追加写的模式。每次状态变更都新增一条记录，而不是在原记录上直接 update。这样审计时能看到完整的变更历史。

4.4 如何撤回同意

撤回同意这件事，法规上的要求是“和给予一样容易”。什么是“一样容易”？说白了，就是用户不能用 2 步给你同意，却要用 7 步才能撤回。我见过一些 app，同意同意在小弹窗里一点就行，但撤回——你得去设置里翻三层菜单，再填一个表单。这就不行。

API 层面，撤回接口应该简单直接：

# 撤回特定同意
POST /api/v1/consents/cns_xyz789/revoke
Content-Type: application/json

{
    "user_id": "u_abc123",
    "reason": "no_longer_want",
    "revoked_at": "2025-02-25T14:00:00Z"
}

# 响应
HTTP/1.1 200 OK
{
    "consent_id": "cns_xyz789",
    "status": "revoked",
    "revoked_at": "2025-02-25T14:00:00Z"
}

注意：撤回同意后，你必须在合理期限内停止对相关数据的处理。我之前遇到过一个案例，用户撤回同意后系统还是跑了三天批处理，结果被举报了。所以，撤回事件最好用消息队列实时推送给下游数据处理服务。

4.5 避坑指南

我曾经在一个项目中遇到这样的情况：产品经理说“我们在注册流程里加一个同意条款的勾选框就行了”。结果呢？那个勾选框是默认勾选的。用户根本不知道已经同意了。这是个大坑——默认同意不算同意。

还有几个常见的坑：

一揽子同意：把所有处理目的塞进一句话。比如“我同意公司收集和使用我的所有个人数据”。这在合规上基本是无效的。
同意界面没有“拒绝”按钮：有些设计只有“同意并继续”，没有“拒绝”选项。这等于强迫用户同意。
撤回后数据未删除：用户撤回同意后，你不能再处理他的数据。但备份数据里的历史记录呢？也得考虑在内。
同意版本管理缺失：隐私政策更新后，你得让用户重新同意。如果没做版本管理，你根本不知道用户同意的是哪个版本。

嗯，这里有个要点：每一次同意的获取，都必须对应一个明确的时间戳和版本号。这样即使未来政策变了，你也能回溯：当时用户看到的是哪个版本的隐私政策？他同意了哪些处理目的？

4.6 同意机制的完整流程

最后，我把整个同意机制的流程画出来。这也是我在每个项目中都会提前画的架构图——别等到开发完才发现少了某个环节。

这张图就是用户同意机制的生命周期。从用户操作开始，到数据最终落地。每一步都得设计好，不然就会出问题。