📚 课程目录第3章数据分类方法

数据分类方法：按业务领域、敏感度、数据类型分类

数据分类这件事，说白了就是给数据贴标签。但标签怎么贴、贴几层，直接决定了后续API设计的复杂度。我在好几个项目里都见过一个通病——分类太粗，结果API权限控制跟筛子一样；或者分类太细，开发团队直接罢工。这一章，咱们就把三种最实用的分类方法讲透。

这是最直观的分类方式。你先梳理公司的业务线，然后每条业务线就是一个大类。举个例子，电商系统常见的业务域：

我个人习惯，每个业务域用一个两位字母缩写作为前缀。比如用户域用 US，商品域用 PD。这样在API路径、数据库表名、日志标签里都能一眼识别归属。你想想看，如果所有数据都混在一个大池子里，后面做权限隔离的时候得多痛苦？

技巧：业务域划分不要太细。我见过有人把“用户头像”单独做一个域，结果管理成本暴涨。一般5-8个业务域是比较合理的范围。

这一层是安全架构师最关心的。敏感度分类决定了数据能不能出内网、能不能缓存、能不能在API响应里明文返回。我一般把敏感度分成四个等级：

等级	定义	示例	API处理要求
C0	公开数据	商品名称、公告内容	可直接返回，允许缓存
C1	内部数据	订单状态、用户昵称	需认证，禁止公开缓存
C2	敏感数据	手机号、详细地址	需脱敏或加密，审计日志必记
C3	机密数据	支付密码、身份证号	加密存储，API响应需最小化

注意：我曾经遇到一个项目，把C2级数据当C1级处理，结果手机号在日志里明文存储。等合规审计的时候，整个团队加班两周整改。分级标准一定要严格执行，别存侥幸心理。

这一层更多是技术层面的考量。不同数据类型对API的设计约束完全不同。我把常见的数据类型归为以下几类：

嗯，这里要注意。数据类型分类和前面两种分类不是互斥的。一个用户头像，它既属于用户域，敏感度可能是C1，数据类型又是非结构化。所以你在做分类方案时，得把这三个维度组合起来用。

我在主导一个金融项目时，把这三个维度整合成了一个三维分类矩阵。每个数据资产都有一个三元组标签：

// 三维分类标签示例
// 格式：[业务域]_[敏感度]_[数据类型]

用户手机号: US_C2_STRUCTURED
商品主图:   PD_C1_UNSTRUCTURED
订单日志:   OD_C0_TIMESERIES
支付密码:   US_C3_STRUCTURED

有了这个标签，API网关就能自动路由。比如检测到 C2 或 C3 的数据，强制走加密通道；检测到 TIMESERIES 类型，自动切换到时序查询引擎。说白了，分类的最终目的就是为了自动化决策，而不是给运维人员增加负担。

  核心原则：三个维度的分类不是铁路警察各管一段，而是协同工作的。业务域决定路由，敏感度决定安全策略，数据类型决定序列化方式。缺一个，API设计就会出现盲区。

为什么我强调一定要同时用三个维度？因为单一维度的分类太脆弱了。比如只按业务域分，你没法区分用户昵称和用户密码在安全等级上的差异；只按敏感度分，你又不知道这个数据该走关系型查询还是时序查询。三个维度互相补充，才能构建出经得起推敲的API设计基础。

有了三维分类矩阵，下一步就是把这些标签映射到API的具体设计里。我总结了一套常见的映射规则：

分类标签	API端点设计	传输方式	缓存策略
US_C0_STRUCTURED	`GET /api/v1/users/profile`	HTTPS + JSON	CDN缓存5分钟
US_C2_STRUCTURED	`POST /api/v1/users/phone`	HTTPS + 加密Payload	禁止缓存
PD_C1_UNSTRUCTURED	`GET /api/v1/products/images`	预签名URL	客户端本地缓存
OD_C0_TIMESERIES	`GET /api/v1/orders/trends?start=&end=`	HTTPS + JSON	Redis缓存聚合结果

你看，分类标签一旦确定，API的技术选型基本就定了七八成。剩下的就是按照规范写代码。我在项目里一般要求每个API的文档里必须注明分类标签，这样不管是前端调用还是后端维护，大家都能快速理解这条API的约束条件。

避坑：分类标签一旦发布，尽量不要随意修改。我曾经在项目中因为业务调整，把一批数据的敏感度从C1降到了C0。结果忘记通知安全团队，导致原本加密传输的接口突然开了明文通道。虽然没出事故，但被审计的时候写了几十页解释文档。分类变更必须有严格的审批流程。

为了方便你理解这三个维度的协作关系，我画了一张结构图。它展示了业务域、敏感度和数据类型如何共同作用于API设计。

这张图很清楚地展示了三个维度如何汇合。每个维度各自独立，但最终通过组合标签共同驱动API的设计决策。你在实际工作中，先跑通这张图里的逻辑，再去做具体的接口开发，会顺畅很多。