在Redux和React中使用NaN作为默认值是否为不良实践？

你的判断完全正确——在React和Redux的场景下，绝对不应该用NaN作为状态的初始值，你遇到的组件异常跳转问题就是这个选择带来的典型坑，下面来详细拆解原因和解决办法：

1. NaN的特殊性直接破坏比较逻辑 #

JavaScript里的NaN是个非常特殊的存在：它是唯一不等于自身的值。看这个例子：

NaN !== NaN // 返回 true

这就是你组件跳转的根源：组件挂载时，新旧subscription.plan都是NaN，比较结果为true，触发了不必要的/payments/success路由跳转。

2. 干扰React/Redux的浅比较机制 #

React的PureComponent、React.memo，以及Redux中connect的默认浅比较逻辑，都是依赖**严格相等（===）**来判断是否需要更新。而NaN的特性会直接打乱这个逻辑：

• 当状态没有实际变化时，浅比较会误判为“值已更新”，导致组件无意义的重渲染，浪费性能
• 当实际状态确实需要更新时，NaN的比较逻辑也可能出现不符合预期的结果，破坏组件的更新流程
  这些都会干扰React的协调过程，引发各种难以排查的bug。

3. Flow类型检查的“假象” #

你提到Flow不会像null/undefined那样报错，这确实是Flow的类型规则——因为NaN属于number类型，符合你定义的Payments类型要求。但这只是类型层面的合规，完全掩盖了NaN在运行时的异常行为，反而给你造成了“一切正常”的误导。

正确的初始值设置方案 #

针对你的Payments状态，推荐用以下方式替换NaN作为初始值：

• 对于数值类型字段（比如cycle_length、paid_for_users、plan等）：优先用null（如果业务上这些值初始时是未定义状态），或者用符合业务逻辑的默认值（比如0，如果0是合理的初始状态）
• 确保所有初始值都能通过严格相等比较，避免任何特殊值

修改后的初始状态可以是这样：

const INITIAL_STATE: Payments = { 
  cycle_length: null, 
  next_billing_date: '', 
  paid_for_users: null, 
  payment_method: null, 
  plan: null, 
  is_trial: false, 
  price: '', 
  status: '', 
  subscription_id: '', 
  team: null, 
};

同时，在组件的比较逻辑里，可以先判断值是否有效，避免初始状态的误判：

const hasChangedPlan = this.props.subscription.plan != null && this.props.subscription.plan !== subscription.plan;

内容的提问来源于stack exchange，提问作者Tomasz Mularczyk