应存字符串但需严格校验和集中定义，避免硬编码与数字存储；枚举集合仅在动态配置或多语境场景下必要；schema validator 必须完整 enum 列表且同步更新，新增状态需兼顾数据迁移与排序逻辑。
枚举字段该不该存成字符串？
直接存字符串（如 "active"、"inactive"）最常见，但容易埋坑：后期想加语义化描述、国际化支持或类型校验时，字段本身不携带任何元信息。MongoDB 没有原生枚举类型，所以字段值本身只是 BSON 字符串或数字，靠应用层约束。
建议用字符串，但必须配合严格的应用层校验和集中式枚举定义。不要在多个服务里各自硬编码 "pending" / "approved" —— 一旦某处漏改，数据就脏了。
- 所有枚举值统一定义在共享库或配置中心，例如 C# 用
public static class OrderStatus，Node.js 用const ORDER_STATUS = { PENDING: "pending", APPROVED: "approved" } - 写入前必须走校验函数，比如
isValidStatus(value)，不能只依赖 schema validation - 避免用数字（如
0、1）存状态——可读性差，且无法直接映射到前端 label 或 i18n key
要不要单独建枚举集合？
单独建一个 enum_definitions 集合（含 type、value、label、i18n_key、sort_order 等字段）听起来很“规范”，但实际多数项目没必要。
它只在以下场景真正有价值：枚举项需要运行时动态增删（如运营后台配置审批流节点），或同一枚举在多处需不同 label/i18n（如 "draft" 在订单页叫“草稿”，在文章页叫“未发布”）。
- 如果枚举项固定、变更频率低（如 HTTP 方法
"GET"/"POST"），直接代码内定义 + 字段级校验更轻量 - 若真建枚举集合，务必给
{ type: 1, value: 1 }加唯一复合索引，否则查status对应的中文名会慢 - 不要在业务文档里用
$lookup关联枚举集合——每次查询都多一次 IO，聚合管道变重，且无法利用覆盖索引
schema validation 怎么写才不踩坑？
MongoDB 的 validator 是第一道防线，但写错等于没写。常见错误是只校验字段存在性，不校验值范围。
正确写法示例（在创建集合时设置）：
db.createCollection("orders", {
validator: {
$jsonSchema: {
properties: {
status: {
enum: ["pending", "confirmed", "shipped", "delivered", "cancelled"]
}
}
}
}
})-
enum数组必须完整列出所有合法值，不能只写几个“常用项” - 新增枚举值时，必须同步更新
validator和应用层定义，否则写入会因校验失败而报Document failed validation - 不要用正则替代
enum（如pattern: "^(pending|confirmed).*$"），既难维护又无法被客户端工具识别 - 如果字段允许 null，要显式写
"nullable": true，否则null会被拒绝
扩展时最容易忽略的点
后续加新状态（比如从 "shipped" 增加 "in_transit"）看似简单，但真实风险在数据迁移和兼容性上。
- 旧数据不会自动补默认值，查询时得处理
status字段不存在或为null的情况 - 如果用到了
$facet或$group聚合统计各状态数量，新加枚举值后，没匹配到的分组会直接消失——前端图表可能少一块，但后端无报错 - 带索引的枚举字段（如
{ status: 1 }）不需要重建索引，但若之前用了稀疏索引（sparse: true），新加的值可能不被索引覆盖 - 最隐蔽的是排序：字符串枚举按字典序排（
"cancelled"在"confirmed"前），如果业务要求固定顺序（如生命周期流程），必须在应用层做 map 映射，不能依赖 MongoDB 的 sort
