应使用字符串枚举（如 StatusEnum）而非字面量硬编码订单状态，因其提供编译期类型检查、避免拼写错误、支持双向映射与遍历；扩展性不足时可用 const 断言+联合类型替代。
为什么不能用 const 或字面量硬编码订单状态
直接写 "pending"、"shipped" 这类字符串散落在代码各处，会导致类型检查失效、拼写错误难发现、重构成本高。比如把 "canceld"（少个 l）传进数据库更新逻辑，运行时才暴露，而 IDE 和 TypeScript 都无法提示。
枚举能提供编译期约束和语义化命名，尤其在订单状态这种有明确流转关系、需被多处消费（前端展示、后端校验、数据库字段映射）的场景里，是更安全的选择。
用 TypeScript enum 实现状态定义与双向映射
TypeScript 的 enum 支持数字/字符串成员，但订单状态推荐用**字符串枚举**：可读性强、序列化友好、避免数字隐式转换风险（比如 StatusEnum[0] 会返回 "pending"，但 0 并无业务含义）。
- 定义时每个成员必须显式赋值为字符串字面量，禁止省略
- 若需反查（如根据数据库存的
"paid"找到对应枚举成员），直接用StatusEnum["paid"]即可，TypeScript 会推导出类型"paid" - 若需遍历所有状态（如生成下拉选项），用
Object.values(StatusEnum)，但注意它返回的是字符串数组，不是枚举成员本身
enum StatusEnum {
PENDING = "pending",
PAID = "paid",
SHIPPED = "shipped",
DELIVERED = "delivered",
CANCELED = "canceled"
}
如何在接口和数据库之间安全传递状态值
后端 API 返回的 JSON 字段（如 status: "shipped"）和数据库中存储的字符串必须与枚举值完全一致，否则反序列化或校验会失败。
- API 响应 DTO 中字段类型应为
StatusEnum，而非string，强制约束取值范围 - 数据库字段建议用
ENUM类型（MySQL/PostgreSQL）或带 CHECK 约束的VARCHAR，确保底层数据不越界 - 接收前端请求时，用
zod或class-validator校验：例如z.string().refine(v => Object.values(StatusEnum).includes(v))，比手动if (v !== "pending" && ...)更可靠
枚举扩展性差？用联合类型 + const 断言替代
当项目后期需要支持插件化状态（如第三方物流接入新增 "out_for_delivery"），原生 enum 无法动态扩展，且跨包引用易导致编译错误。此时更灵活的做法是：
- 用
const对象 +as const声明状态集合 - 导出类型
type OrderStatus = typeof ORDER_STATUS[keyof typeof ORDER_STATUS] - 这样既保留类型安全，又允许其他模块通过
declare module注入新状态，且 IDE 能正确提示补全
const ORDER_STATUS = {
PENDING: "pending",
PAID: "paid",
SHIPPED: "shipped",
DELIVERED: "delivered",
CANCELED: "canceled"
} as const;
type OrderStatus = typeof ORDER_STATUS[keyof typeof ORDER_STATUS];
字符串枚举看着简洁，但一旦涉及状态机流转校验（比如“不能从 canceled 直接回到 paid”），光靠枚举本身不够——得配合状态转换表或专用校验函数，这点容易被忽略。
