MySQL的YEAR类型跨世纪不安全，需显式用YEAR(4)并校验范围1901–2155；PostgreSQL宜用smallint存年份；前端传数字、后端禁用日期解析；查询时年份条件必须为整数字面量。
MySQL 中 YEAR 类型真能跨世纪安全用？
不能直接信。mysql 的 year 类型在 5.6.5 及之后默认是 4 位显示（1901–2155），但底层仍分 1 字节存储的 year(2) 和 year(4) 两种模式——而 year(2) 已被弃用且行为诡异：输入 0 可能变成 2000，70 变成 1970，71 又变 2071。实际项目里只要出现年份跨度可能覆盖 1970–2069 之外（比如历史档案、长期设备寿命预测），就必须禁用 year(2)。
- 建表时显式写
YEAR(4)，别省略括号或依赖默认 - 确认 MySQL 版本 ≥ 5.6.5，旧版本
YEAR默认就是 2 位逻辑 - 应用层插入前校验值范围：必须在
1901到2155之间，超出会截断或报错
PostgreSQL 没有 YEAR 类型，怎么只存年份又不浪费空间？
用 smallint 最实在。它占 2 字节，范围 -32768 到 +32767，足够覆盖公元前后万年需求，且支持索引、约束、分区——比用 date 存 '2024-01-01' 省 4 字节，比 text 存 '2024' 更易校验和计算。
- 加
CHECK约束：例如CHECK (year_value BETWEEN 1 AND 9999) - 避免用
extract(year from now())动态取年份再插入，容易漏掉时区/边界问题 - 如果后续要关联日期计算（比如“距今多少年”），
smallint比date多一步转换，但性能差异可忽略
前端界面选年份控件传到后端，为什么存进数据库总差一年？
大概率是 JavaScript 的 Date 构造函数搞的鬼：new Date('2024-01') 或 new Date(2024, 0) 看似没问题，但传给后端时若序列化为 ISO 字符串（如 '2024-01-01T00:00:00.000Z'），再被后端解析成本地时区时间，就可能因时区偏移导致年份错乱——尤其在 UTC+8 区域，2024-01-01T00:00:00.000Z 对应北京时间是 2024-01-01 08:00:00，但如果后端按字符串截取或误解析，可能拿到 2023。
- 前端提交纯数字
2024，别传Date对象或 ISO 字符串 - 后端接收字段类型设为整数（如 Java 的
Integer，Python 的int），跳过任何日期解析逻辑 - 若必须用日期控件，选只输出年份的库（如
react-year-picker），而非全日期选择器
跨世纪年份查询慢？不是数据量问题，是类型隐式转换
当字段是 YEAR 或 smallint，但 WHERE 条件写成 WHERE year_col = '2024'（字符串），MySQL 或 PostgreSQL 会触发隐式类型转换：要么把整数字段转字符串逐个比较，要么把字符串转整数再匹配——前者无法走索引，后者在某些驱动里可能失败。实测百万级表，这种写法查询耗时从 5ms 涨到 1200ms。
- WHERE 条件中年份值必须是整数字面量：
WHERE year_col = 2024，不是'2024' - ORM 中检查生成的 SQL，确保参数绑定类型是整数，不是字符串
- 用
EXPLAIN看执行计划，如果type是ALL或key为空，八成是类型不匹配
年份看着简单，但跨世纪、跨时区、跨语言栈时，最容易栽在类型对齐上——不是存不下，是存对了但读错了、比错了、算错了。
