4. 数据最小化原则在SDK中的实践

数据最小化，说白了就是“能少拿就少拿，能删就早删”。

我早年接手过一个分享SDK，里面硬编码了十几个字段，连用户屏幕分辨率、电池电量都采了。结果隐私合规评审被直接打了回来。那次整改后我养成一个习惯：每个字段都要问一句“真的必需吗？”

4.1 数据最小化原则的工程解读

数据最小化不只是理念，它得落到代码里。我个人习惯把它拆成三层：

• 采集层 – 只从宿主App拿“业务必需的”字段
• 存储层 – 存之前做匿名化/脱敏，不留原始标识
• 生命周期层 – 设置TTL，超时自动废弃

工程上我们通常会准备一张“数据字段清单表”，和产品、法务一起逐条确认。嗯，这里要注意：不是产品说“这个字段以后可能用”就加进去，法律要求的是“当前功能必需”。

4.2 只采集必要字段：字段裁剪与配置化

很多分享SDK一上来就传整张用户表。我建议做法是：用配置文件定义“采集白名单”，每个业务场景独立一份配置。

// 采集白名单配置示例（JSON）
{
  "share_text": {
    "fields": ["title", "description", "url"],
    "optional": ["thumbnail_url"]
  },
  "share_image": {
    "fields": ["image_url", "width", "height"],
    "optional": []
  }
}

为什么这么干？你想想看，如果产品加一个新分享类型，只需要在配置里加一行就行，不必改SDK代码。我在项目中遇到过好几次因为硬编码字段列表，导致每次发版都得重新走一遍合规评审。后来改成配置化，法务审过一次配置，后面只做增量审查，效率高多了。

4.3 匿名化处理：脱敏与聚合策略

匿名化不是简单地对某个字段“打星号”。我个人习惯分两种场景：

• 不可逆脱敏 – 比如对手机号做SHA-256加盐后截断，用于设备指纹匹配，但无法还原原始手机号。
• 聚合匿名 – 比如上报“用户年龄区间”而非精确年龄，用于数据分析。

字段类型	原始值	匿名化处理后	适用场景
手机号	13812345678	sha256(13812345678 + salt)[:8]	设备关联但不可溯源
精确年龄	28	区间: 25-30	用户画像统计
定位坐标	39.9042,116.4074	城市级: “北京市”	地区分布分析

// 脱敏函数示例（Kotlin）
fun anonymizePhone(phone: String, salt: String): String {
    val combined = phone + salt
    val digest = MessageDigest.getInstance("SHA-256").digest(combined.toByteArray())
    // 只保留前8位十六进制字符串
    return digest.take(8).joinToString("") { "%02x".format(it) }
}

我曾经踩过一个坑：对IMEI做MD5脱敏，结果被攻击者用彩虹表反向破解。后来换成SHA-256加随机盐，才真正做到“不可逆”。

4.4 废弃数据自动清理：TTL与定时任务

数据最小化不只是“采集时控制”，还有“存多久”的问题。

我通常给每个数据条目打上expire_time，然后启一个轻量级定时任务定期清扫。SDK里不建议直接用线程池扫数据库，我推荐的做法是利用宿主App的WorkManager或AlarmManager，避免额外资源消耗。

// 清理过期数据（伪代码）
fun cleanExpiredData(context: Context, ttlHours: Int = 168) { // 默认7天
    val cutoff = System.currentTimeMillis() - ttlHours * 60 * 60 * 1000
    db.execSQL("DELETE FROM share_records WHERE create_time < ?", arrayOf(cutoff))
    // 记录清理日志
    Log.d("SDK_Privacy", "Cleaned $deletedCount expired records at ${Date()}")
}

这里有个容易被忽略的点：TTL参数应该可由宿主App配置。比如金融类App可能要求3天内必须删除，而工具类App允许30天。我建议在SDK初始化接口里暴露一个 setTtlHours() 方法，默认值由产品合规策略决定。

4.5 实战避坑指南

• 别只依赖宿主App清理 – 万一宿主App自己不调用清理接口呢？SDK内部应该也有一套保底清理逻辑。
• 日志也要注意最小化 – 我之前发现后台日志里打印了完整的用户昵称和手机号，直接违反了最小化。后来改成只打 userId-fragment。
• 废弃数据清理不可逆 – 如果业务想“恢复删除”那就麻烦了。所以我一般先做逻辑删除（标记为已删除），保留24小时再物理删除，给运维留个反悔窗口。
• 合规审计日志必不可少 – 每条数据从采集到删除的全生命周期，都应该留下不可篡改的记录。方便隐私评审时展示“我们确实执行了最小化”。