好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 “以后可能有用”不是合法数据需求。每个事件应回答一个可操作问题，字段必须能说明对哪个决策有贡献，否则它只增加隐私与高基数成本。
风控既要限制滥用，也要限制自己收集的数据。优先使用短期、粗粒度、可解释信号，并为共享网络、弱网和辅助技术保留恢复与申诉路径。
先定义系统契约
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 维护事件目录：owner、purpose、allowed fields、sampling、retention 和删除方式；客户端只接受编译时 schema，服务端再次丢弃未知属性。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 兼容性通过显式能力协商决定，旧客户端得到可解释的降级路径，而不是进入半可用状态。
“行为埋点的数据最小化：先写决策问题，再决定采什么”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
哪些情况会破坏契约
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 把异常对象、URL 和用户输入整体附加到事件会意外收集内容；永久匿名 ID 与精确时间仍能组合识别个人。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
如何逐条验证契约
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 逐事件做字段血缘审查并注入敏感 canary，验证网络请求、落库、导出与仪表盘都只出现允许字段。
- 连续执行一百次开始、失败、重试和取消，检查句柄、监听器、队列及临时数据回到基线。
- 对日志和埋点做字段白名单检查，证明内容载荷、密钥、完整 IP 与用户可识别信息不会离开设备。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。