字符串枚举比整型更安全，尤其在跨服务或演进场景下：MongoDB无原生枚举，全靠应用层约定；字符串易读、可调试、抗重构，避免整型映射不一致导致的静默失败。
字符串枚举比整型更安全，尤其在跨服务或演进场景下
直接说结论：MongoDB 本身不支持原生枚举类型，所谓“枚举状态”全靠应用层约定。字符串值（如 "pending"、"completed"）比整型（如 0、1）更易读、可调试、抗重构——只要字段名没变，改个字符串值不会导致查询无声失败。
常见错误现象：status: 2 存进去了，但代码里忘了定义 2 → "cancelled"，查出来就是 undefined 或空状态；更糟的是，不同微服务用的整型映射不一致，A 服务存 1 表示“已发货”，B 服务却当它是“已支付”。
- 整型适合纯内部、生命周期极短、且无外部交互的临时状态（比如前端 loading 状态机）
- 字符串天然兼容 MongoDB 的
$in、$eq查询，无需额外转换，聚合阶段也更直观 - 如果已有整型状态字段，别硬转——先加字符串副本字段（如
status_str），双写过渡，等下游全部切完再删旧字段
用 Mongoose Schema 做字符串枚举校验，但别信 enum 的默认行为
Mongoose 的 enum 选项看起来能约束取值，但默认只在 .save() 时校验，updateOne()、findOneAndUpdate() 等直连操作完全绕过它——线上出过太多“手动 db.collection.update() 改了个错字，结果状态崩了”的事故。
- 必须开启
runValidators: true才能在更新时触发enum校验，例如：Model.findOneAndUpdate({ _id }, { status: "invalid" }, { runValidators: true }) - 更稳妥的做法是封装一个
setStatus()方法，在里面做白名单判断，而不是依赖 Schema 被动拦截 - 注意：Mongoose
enum不校验大小写，"PENDING"和"pending"都会通过，建议统一转小写存入
聚合查询中字符串枚举的性能和索引影响几乎可忽略
有人担心字符串比整型占空间、查得慢。在真实业务数据量下（千万级以内），只要字段有索引，status: "shipped" 和 status: 3 的查询性能差异微乎其微。MongoDB B-tree 索引对短字符串（≤ 20 字符）的比较效率很高。
- 确保给状态字段建了索引：
db.orders.createIndex({ status: 1 }) - 避免在聚合里用
$switch把整型转字符串再匹配——直接存字符串，一步到位 - 如果真有高频范围查询（比如“所有非终态”），考虑冗余一个布尔字段
is_terminal: false，而不是靠$in列一堆字符串
迁移已有整型状态到字符串时，最危险的是驱动层自动类型转换
Node.js MongoDB Driver 默认把数字当 NumberInt 存，但某些 ORM 或旧版驱动会悄悄把 1 当成 JavaScript number 写入，而另一些地方又当 Long 读——导致同一条记录里 status 在不同查询里有时是 1，有时是 NumberLong(1)，$eq 匹配直接失效。
- 迁移前先用
db.collection.find({ status: { $type: "int" } }).count()确认当前实际存储类型 - 批量更新时显式指定类型：
{ status: "confirmed" }，别用String(oldStatus)拼接，防止空字符串或"undefined" - 上线后紧盯日志里的
status: null或status: ""，这是类型转换失败最常漏出的痕迹
状态字段看着小，但一旦混用类型、跨服务共享、又没留好迁移钩子，后续排查成本远高于初期多敲几个字符。字符串不是银弹，但它把“错在哪”从“不知道”变成了“一眼看见”。
