2. 数据最小化原则

好，咱们今天聊一个很实在的话题——数据最小化。

说白了，就是能少拿就少拿，能不给就不给。我见过太多项目，一上来就把用户的所有信息往数据库里塞，好像不把身份证号、家庭住址、通讯录全拿过来就亏了似的。结果呢？数据泄露的时候，哭都来不及。

2.1 数据收集范围控制

先问自己一个问题：这个功能，真的需要这个字段吗？

我习惯在需求评审阶段就拉上产品经理和法务，一起过一遍数据收集清单。每多一个字段，就多一分风险。你想想看，用户注册一个天气应用，你非要问人家生日干嘛？

控制范围，有几个实操要点：

• 按需收集：只收集业务功能直接依赖的数据。比如外卖App，需要你的地址和电话，但不需要你的职业信息。
• 设定保留期限：数据不是越久越好。我建议在系统设计时就加上自动过期策略。比如用户注销账号后，30天内自动清理所有个人数据。
• 明确使用场景：收集时就要说清楚，这个数据用在哪儿。不能今天说用于推荐，明天拿去卖广告。

我在项目中遇到过一件事：一个社交App，非要收集用户的精确位置来做“附近的人”功能。后来我们发现，其实用城市级别的模糊定位就足够了。改了之后，用户隐私风险直接降了一个量级。

2.2 数据字段裁剪

字段裁剪，就是把你收集来的数据，再“削”掉一层。嗯，这里要注意，不是所有字段都要原封不动地存进数据库。

举个例子：用户注册时填了手机号，但你只需要知道这个手机号是否唯一。那你可以只存一个哈希值，而不是明文手机号。这就是裁剪。

常见的裁剪策略：

原始字段	裁剪后	说明
身份证号（18位）	后4位	仅用于身份校验时，不需要完整号码
手机号（11位）	前3位+后4位	展示时脱敏，后台可保留完整用于验证
家庭地址（详细）	只保留街道/小区名	物流配送需要精确地址，但数据分析不需要
出生日期（年月日）	只保留年份	年龄分析用，不需要具体日期

我个人习惯在数据入库前，就做一层“裁剪中间件”。所有数据进来，先过一遍裁剪规则，再落库。这样即使后端代码有漏洞，泄露出去的也是裁剪后的数据。

2.3 数据脱敏基础概念

脱敏，说白了就是把敏感信息“藏起来”。但藏的方式有很多种，你得根据场景选。

我曾经犯过一个错：把用户邮箱全部替换成固定字符串“xxx@xxx.com”，结果测试环境跑了一周才发现，所有用户的邮箱都变成一样的了，业务逻辑直接崩掉。嗯，从那以后我再也不敢乱脱敏了。

常见的脱敏方法：

• 替换：用固定字符（如*）替换敏感部分。比如手机号变成 138****1234。
• 加密：用密钥加密，需要时再解密。适合需要还原的场景。
• 哈希：不可逆的散列处理。适合唯一性校验，但不适合展示。
• 泛化：把精确值变成范围。比如年龄25岁变成20-30岁。
• 置乱：打乱数据顺序，但保持统计特征。适合数据分析场景。

来看一个简单的代码示例，用Python做手机号脱敏：

def mask_phone(phone: str) -> str:
    """
    手机号脱敏：保留前3位和后4位，中间用****代替
    示例：13812345678 -> 138****5678
    """
    if len(phone) != 11:
        raise ValueError("手机号长度不正确")
    return phone[:3] + "****" + phone[-4:]

# 使用示例
print(mask_phone("13812345678"))  # 输出：138****5678

最后说一句：数据最小化不是一句口号，它是你系统设计里实实在在的每一行代码、每一个表结构、每一条API接口。我建议你在做技术方案评审时，把“数据最小化”作为一个必检项。少拿数据，少出问题，少背锅——这道理，你品，你细品。