合法性依据与同意：四类目的、三种同意与一次版本错配

同意不是签一次就完了，它是一次带版本号的授权。

一、十一天后才被发现的旧版本

陈默的发票工具「零票」在十月把隐私政策从 v2.3 升到 v2.4，改动只有一句：新增分析服务，并说明会采集页面事件与设备信息。上线十一天后，他为了回答一份客户问卷导出全部同意记录，发现最近新增的三十八条里，版本号一栏整整齐齐写着 v2.3。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他先怀疑后端写错了版本常量，查了提交记录，常量确实已经改成 v2.4。继续往前追，问题出在前端：同意弹窗的文案被打包进静态资源，缓存策略设得很长，用户看到的是旧文案，点「同意」时回传的也是旧版本号。三十八条记录里，有的来自老用户重新登录，有的来自新注册，他们看到的都是同一份过期文案。

更麻烦的是内容差异。v2.3 的弹窗把「接受服务条款」和「同意分析」合成一个勾选框，v2.4 才拆成两个。也就是说，这三十八人里有一部分从未单独同意过分析，系统却按「已同意」处理。记录是真的，同意是假的。

他试着把三十八条记录批量改成 v2.4，改到一半时停住了：这样做只是在数据库里制造了一个更漂亮的谎言。真正要修的不是记录，是「文案、版本号、后端配置」这三处各自为政的结构。

这次导出原本只是为了回答问卷，却顺带暴露了同意系统最脆弱的一环：记录看起来完整，来源却不可信。他把三十八条逐条打开，发现其中几条的 IP 属于同一间办公室，来源却写着「注册页」；再核对，是同事用测试账号批量导入的演示数据，混进了生产记录。

版本错配不是显示问题，是依据问题。 同意记录的三个要素——谁、何时、哪版——缺一个就无法证明授权存在。版本号写错，等于三十八份授权书指向了一份他们没看过的文本。

缓存不是借口，同源才是解法。 前端缓存本身没错，错在文案与版本号来自两个地方：文案在静态资源里，版本号在后端配置里。两个来源就一定会漂移，只是时间早晚。

旧记录不能批量迁移。 把 v2.3 的记录直接改成 v2.4，看起来省事，实际上是把「没同意过」写成「同意过」。正确做法是保留旧记录，对受影响的人重新征得一次。

同意要有拒绝的余地。 如果不同意分析就无法使用产品，那这个「同意」在法律上站不住，产品上也只是把勾选框当成了装饰。分析与营销必须真的可选，拒绝后核心功能照常可用。

二、四类目的，两条依据

处理目的只有四类：服务、计费、分析、营销。每一类先回答「凭什么处理」，再回答「处理什么」。前者是合法性依据，后者才是字段清单。

合同与同意是两条平行的路，不能互相顶替。用户注册即形成合同关系，为交付服务处理账号与项目数据，依据是合同履行，不需要再要一个「同意服务」的勾选；反过来，分析与营销不是服务必需，不能塞进条款里搭车，只能单独征得同意。以适用法域与专业意见为准。

字段与目的要对成矩阵：七十八个字段乘四类目的，共三百一十二格。真正被某个功能读取、且目的成立的只有九十六格，占 30.8%；其余二百一十六格是 69.2%，应当拒绝。矩阵的作用不是把表格填满，而是让每一个「允许」都能指向一段代码或一条法定义务。

一个字段只能挂一个主目的。邮箱在计费里是发票送达，在营销里是订阅推送，两件事必须分开记录；否则用户撤回营销同意时，你分不清哪一部分该停。主目的之外的使用，要么另立同意，要么不做。

九十六格允许不是拍脑袋定的，而是从功能反推出来的：每一个真正读取个人字段的页面、接口或定时任务，最多贡献一格。反推时最容易多算的是「导出」和「报表」，它们读的字段往往和原功能重复，只是换了个出口；把这些重复项去掉，九十六这个数才站得住。

目的也会变。今天为了排查故障临时打开的调试日志，明天可能被产品经理写进需求文档，变成「用户行为分析」。目的变更不是改一行文案，而是重新判断依据：如果新目的落在原同意范围内，可以继续；超出范围，就必须重新征得。以适用法域与专业意见为准。

三、三类同意与六个字段

三类同意对应三种不同的承诺：条款是使用服务的前提，营销是可选订阅，分析是可选的观测授权。它们的记录粒度不同，撤回后的动作也不同。

每条同意记录固定六个字段，缺一个就只能算「有人口头说过」。

按当前数据，三百四十四个账号里，订阅营销邮件的有二百六十八人，占 77.9%；未订阅七十六人，占 22.1%；一年里撤回二十四人，占 7.0%。撤回必须在二十四小时内生效，且只停止后续处理，不影响撤回前已经发生的处理。以适用法域与专业意见为准。

条款同意不能代替营销同意，营销同意也不能反向解锁分析。三类分开记录的好处是撤回时动作明确：撤回营销只关邮件通道，撤回分析只停采集，撤回条款才触发停服与删除。

IP 与来源这两个字段常被当成「技术细节」省略，但它们决定了一份记录能不能自证。IP 用来证明请求确实来自某个网络位置，来源用来证明用户是在哪个界面做的选择；两者都不改变同意的有效性，却能在争议时把「系统说有」变成「这里有证据」。

六个字段里最容易被做坏的是「哪类」。为了省事，很多实现只存一个布尔值 consented，三类同意共用一列；结果用户撤回营销时，代码只能把整行置否，分析也跟着停了，或者反过来，撤回分析却连发票邮件都发不出去。拆成三个独立字段，才能让撤回精确到通道。

四、修法：同源、检查与重新征得

修法有三步。第一步让同意文案与政策版本同源：版本号只存一处，弹窗、政策页、后端记录都读同一个常量，任何一处改版，三处一起变。第二步在发布前跑一条「版本一致性」检查：构建时抓取线上弹窗实际渲染的版本号，与后端配置比对，不一致就阻断发布。第三步对三十八条错配记录不迁移，而是标记为待重新征得，在下一次登录时单独弹出分析与条款两个选项。

检查脚本的判据要写死，不能靠人看。构建产物里的版本号、接口返回的版本号、政策页展示的版本号，三者必须完全相等；任意两个不等，构建失败，并把三个值打印出来。这条检查只花几秒钟，却能挡住这次事故的全部三十八条错配。

重新征得的时机也要设计。用户下次登录时弹一次，弹窗里只放分析与条款两项，默认都不勾选；用户拒绝分析不影响登录，拒绝条款则进入停服流程。旧记录保留原样并标记 superseded，不删除，因为它是「当时确实发生过什么」的唯一证据。

旧版本本身也要留。政策页保留可访问的历史版本，同意弹窗的文案随版本一起归档，至少覆盖一个完整的同意周期；否则过一阵子有人问「v2.3 到底写了什么」，你只能从缓存快照里猜。留档不是备份数据库，而是留一份人能读懂的文本。

复算：这些数字放在一起，能看出错配的规模与抽查的意义。

账号 344 = 付费 120 + 试用 18 + 暂停 2 + 免费/沉默 204
营销订阅 344 − 76 = 268；268 ÷ 344 = 77.9%
未订阅 76 ÷ 344 = 22.1%
年撤回 24 ÷ 344 = 7.0%
错配 38 条 ÷ 11 天 ≈ 3.5 条/天
字段×目的 78 × 4 = 312 格
允许 96 ÷ 312 = 30.8%；拒绝 (312 − 96) ÷ 312 = 69.2%

三十八条错配听起来不多，但它发生在一句新增说明上。如果那次改版动的是共享清单或保留期，错配的就不只是版本号，而是整段授权基础。版本一致性检查的成本是一次构建脚本，收益是把这类问题挡在发布之前。

营销订阅 77.9% 这个数字只说明存量，不说明质量。真正要看的是一年里撤回的 7.0%：如果某个月突然升高，先查是不是邮件频率变了，再查退订入口是不是藏得太深。撤回率高不一定是坏事，它说明用户看得见出口。

季度抽查十条记录，重点看三件事：版本号是否等于当前政策、同意类型与来源是否匹配、撤回后二十四小时内是否真的停了。十条里错一条，就扩大到全量比对；这不是不信任记录，而是记录本身没有自证能力。

五、行动清单与复算验收

这八条按「先定目的、再定依据、最后管版本」的顺序做，一个人按顺序做完即可。

• 列出四类处理目的：服务、计费、分析、营销，写进数据地图的用途列。
• 给每类目标注合法性依据：服务与计费为合同，分析与营销为同意。
• 建立三类同意记录：条款、营销、分析，分开存储、分开撤回。
• 每条记录补齐六个字段：谁、何时、哪版、哪类、IP、来源。
• 让同意文案与政策版本同源，版本号只保留一个来源。
• 撤回在二十四小时内生效，并写一条可查询的处理记录。
• 每季度抽查十条同意记录，核对版本、类型、来源与撤回结果。
• 保留旧版本政策与旧文案，至少覆盖一个完整的同意周期。

清单可以压缩成一句话：目的有依据，同意有记录，记录有版本，撤回有动作。四件事任何一件缺失，其余三件都会在某个具体场景里失效。

验收标准：任取一条同意记录，都能回答「谁在何时同意了哪一版的哪一类内容」，答不出就是记录不合格。

使用边界与实操验收

边界一：同意不是唯一的合法性依据。 服务与计费走合同履行，履行合同所必需的处理不需要同意；把一切都做成勾选框，既啰嗦，也会让真正的可选同意失去意义。

边界二：本文不构成法律意见。 四类目的与两条依据是产品侧的分类方法，具体到某个法域是否成立，要看当地监管指引与专业意见。以适用法域与专业意见为准。

边界三：撤回不等于退订。 退订只关掉邮件通道，撤回同意还要停止对应的数据处理，并按保留期处理历史数据。两者可以同时发生，但不能互相替代。

边界四：未成年人场景要另论。 涉及儿童或未成年人的产品，同意的取得方式、验证强度与撤回路径都不同，不能直接套用本文的成人账号模型。

边界五：不同法域的规则不同。 GDPR 的同意标准、CCPA 的选择退出、PIPL 的单独同意各有口径；同一套界面要按投放地区做差异化，不能一份文案全球通用。以适用法域与专业意见为准。

关键参考与核验范围

• GDPR Art 6：处理的合法性 ：用于核对各项合法性依据及合同履行的边界。
• GDPR Art 7：同意的条件 ：用于核对同意应自由给出、具体、知情且可撤回。
• GDPR Art 13：收集时的告知 ：用于核对告知义务与目的、依据、保留期的披露项。
• GDPR Art 14：非直接收集的告知 ：用于核对间接获得个人数据时的告知时限与内容。
• ICO：合法性依据指南 ：用于核对选择依据时的判断顺序与记录要求。

以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。

系列导航

• 回到本组目录：一个人的隐私工程：数据地图、最小化与删除权
• 上一篇：数据最小化：二十三个没人读的字段与一次删列迁移
• 下一篇：隐私政策与产品行为：十二个域名、九个披露与三个漏项
• 相关：数据地图：十二张表、七十八个字段与一次「我们到底收了什么」