-
我用数字枚举定义订单状态,以为类型安全了,结果一个不存在的数字 99 也能传进去、遍历枚举时还莫名多出一倍的项:一次 TypeScript 数字枚举两个坑的深度复盘
我用 TS 数字枚举定义订单状态 enum OrderStatus { Pending, Paid, Shipped }(值默认 0、1、2),以为用了枚举类型就安全了。可线上两件怪事:一个不属于这枚举的数字 99 被传进了参数类型为 OrderStatus 的函数、TS 居然不报错,导致 switch 走到没人料到的分支;用 Object.keys 遍历枚举出来的项数是成员的两倍、还混着数字和字…- 0
- 0
-
一个把数字枚举的值直接存进数据库的设计,在我往枚举中间插了一个新成员后,让所有历史订单的状态集体错位了一格:一次 TypeScript 枚举持久化的深度复盘
订单状态用 TS 数字枚举、状态值以数字存库。某次在'待支付'和'已支付'间插了个'支付中',发布后大量历史订单状态集体往后错位一格——已发货显示成已支付。根因是 TS 数字枚举不显式赋值时值从 0 自动递增、靠声明顺序决定,往中间插成员让后面所有值 +1,而数据库里历史数据存的旧数字没变、代码却用新枚举去解释,含义被悄悄换掉。本文讲透数…- 0
- 0
-
我用数字枚举定义状态,本以为类型很安全,结果一个根本不在枚举里的数字 99 被当成合法状态溜了进来,遍历枚举时还冒出一堆奇怪的数字键,我对着 TypeScript 数字枚举这两个坑排查了大半天的复盘
一个让我对 TypeScript 的 enum 从信任到警惕的坑,隐蔽在 enum 看起来是个限定取值范围保证类型安全的好东西,我以为用了它一个变量就只能是枚举里那几个值,可它既没拦住非法的值溜进来又在运行时生成了一堆我没料到的东西。用数字枚举 enum Status { Active, Inactive, Pending }(0,1,2)。坑1:数字枚举类型居然能接受任意数字,setStatus…- 0
- 0
-
我用数字枚举判断用户角色,结果第一个角色 Admin 怎么判都是"假"、权限全乱了,我对着 TypeScript 数字枚举的几个坑排查了大半天的复盘
用 TS 写权限判断,定义了 enum Role { Admin, User, Guest },很多地方用 if(user.role) 判断有没有角色/是不是某角色,逻辑看着没毛病,线上却出诡异权限 bug:偏偏 Admin 各种判断都被当成"没角色/假值",管理员权限全乱套。盯着代码反复看,Admin 明明是合法枚举值凭什么 if 判断是 false?排查大半天才理解数字枚举…- 0
- 0
-
我遍历一个数字枚举想拿到所有选项,结果拿到了双倍的条目、数字和名字混在一起,我盯着这串诡异的结果查了半天才搞懂枚举反向映射的深度复盘
我定义了个数字枚举 enum Status { Active, Inactive, Deleted } 想遍历它拿所有选项做下拉框,只有 3 个选项,Object.keys 却返回了 6 个:["0","1","2","Active","Inactive","Deleted"],…- 0
- 0
-
插个枚举值搞乱所有历史数据:TS 数字枚举避坑复盘
这是一个改了一行无害的代码却让历史数据集体错乱的诡异事故,排查时让我惊出一身冷汗。起因小到不能再小:产品要在订单状态里新增一个待审核的状态,我们的订单状态是用 TypeScript 的枚举定义的,我很自然地把这个新状态插进了枚举中间一个语义上最合适的位置,改完测试新功能一切正常就上线了。可第二天客服那边就炸了:大量用户反馈自己历史订单的状态显示全乱了,明明早就已完成的订单变成了已取消,数据像被恶意…- 0
- 0
-
插一个枚举值搞乱历史数据:TS 数字枚举避坑
有个订单状态我们用 TypeScript 枚举表示:enum OrderStatus { Created, Paid, Shipped, Completed },然后把状态值存进数据库——存的是数字,平稳跑了大半年。直到某次迭代我要在已付款和已发货之间加一个备货中,很自然地把它插在中间,改完测试一切正常便上线。然后客服就炸了:大量用户反馈我明明已收到货订单却显示备货中、我刚下单还没付款怎么显示已发…- 0
- 0
enum
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×