4、数据契约的Schema设计：字段命名规范、数据类型选择、可选与必填字段、版本号管理
数据契约的Schema设计，说白了就是给数据定规矩。你想想看，没有规矩的数据，就像没有交通规则的城市——谁都能跑，但谁都跑不快。我在好几个项目里都见过这种混乱，后来痛定思痛，才总结出这套方法。
4.1 字段命名规范：别让名字成为灾难
字段命名这事，看着简单，坑却不少。我接手过一个老项目，同一个用户ID，有的叫user_id，有的叫uid，还有的叫userId。每次联调都要翻文档，效率低得吓人。
我个人习惯用这套规则：
- 全小写+下划线：比如
order_amount，别用驼峰或大小写混搭 - 业务前缀：比如
usr_、ord_、pay_，一眼就能看出归属 - 避免缩写：除非是公认的（比如
id、url），否则别自己造缩写 - 动词+名词：比如
is_active、has_paid，语义清晰
命名规范示例
# 推荐
order_id
user_name
is_deleted
created_at
# 不推荐
orderId # 驼峰
UserName # 大小写混搭
del_flag # 含义模糊
crt_tm # 自己造的缩写嗯，这里要注意：命名规范一定要写到契约里，并且用工具强制检查。我曾经有个团队，口头约定用下划线，结果两周后review代码，发现一半人还是用了驼峰。后来加了lint规则，才彻底解决。
4.2 数据类型选择：别让精度吃掉你的成本
数据类型选错了，要么存不下，要么浪费存储。我见过最夸张的例子，有人用STRING存布尔值，一个字段占了几十字节，其实一个bit就够了。
我的建议是：
- 能用整数别用字符串：比如状态码、枚举值，用
INT比STRING省空间 - 时间戳用
TIMESTAMP：别用STRING存时间，查询和计算都慢 - 金额用
DECIMAL：别用FLOAT，精度会丢。我吃过这个亏，对账差了一分钱，查了三天 - 大文本用
TEXT或CLOB：别塞进VARCHAR(4000)里，性能会崩
| 数据类型 | 适用场景 | 避坑点 |
|---|---|---|
INT |
ID、状态码、计数 | 注意范围，别溢出 |
DECIMAL(18,2) |
金额、精确计算 | 精度和标度要匹配业务 |
TIMESTAMP |
时间记录 | 统一时区，别混用 |
VARCHAR(n) |
短文本、名称 | 长度别设太大，浪费空间 |
BOOLEAN |
开关、标志位 | 别用INT(1)代替 |
小技巧：在契约里明确每个字段的数据类型和长度，别留模糊空间。比如user_name VARCHAR(64)，比user_name STRING好得多。
4.3 可选与必填字段：别让空值搞崩你的逻辑
字段是可选还是必填，这事得想清楚。我见过一个支付系统，pay_time字段设为可选，结果下游消费方没做空值判断，直接报了空指针。线上事故，赔了不少钱。
我的原则是：
- 核心字段必填：比如订单ID、用户ID、金额，这些不能为空
- 扩展字段可选：比如备注、标签，可以为空
- 条件必填：比如支付方式选了信用卡，那信用卡号就必须填
注意：可选字段不是让你随便填。如果某个字段90%的情况都为空，那它可能不该出现在这里，考虑拆到扩展表里。
我曾经优化过一个数据契约，把20个可选字段砍到5个，剩下的放到一个ext_info JSON字段里。存储成本降了30%，查询性能反而提升了。
4.4 版本号管理：别让升级变成灾难
版本号这事，我踩过最大的坑。有一次升级契约，直接把字段类型从INT改成了STRING，结果所有下游服务都崩了。从那以后，我定了几条铁律：
- 语义化版本：
MAJOR.MINOR.PATCH，比如1.2.3MAJOR：不兼容的变更（删字段、改类型）MINOR：向后兼容的新增（加字段）PATCH：小修小补（改注释、修文档）
- 版本号写在契约里：每个数据契约都要带版本号，比如
version: "2.1.0" - 向下兼容：升级时，旧字段不能删，只能标记为
deprecated - 版本过期机制：旧版本保留至少3个月，到期前通知所有消费方迁移
版本号管理示例
# 契约版本 2.1.0
version: "2.1.0"
fields:
- name: order_id
type: INT
required: true
deprecated: false
- name: user_id
type: INT
required: true
deprecated: false
- name: old_status # 旧字段，标记为废弃
type: STRING
required: false
deprecated: true
deprecation_message: "请使用 new_status 字段"
- name: new_status
type: INT
required: true
deprecated: false嗯，这里有个细节：版本号要跟着契约文件走，别跟代码走。我见过有人把版本号写在代码注释里，结果代码改了，注释没改，版本号对不上，排查问题花了一整天。
4.5 知识体系总览
下面这张图，把Schema设计的四个核心维度串起来了。你可以把它当成一个检查清单，每次设计契约时对照着过一遍。
说白了，Schema设计就是给数据立规矩。规矩立好了，后面所有环节都顺畅。规矩没立好，后面全是补丁。我个人习惯在设计阶段多花30%的时间，把命名、类型、必填、版本都敲死，这样后面能省下300%的返工成本。