JavaScript while循环不同null判断写法的耗时差异原因咨询

实测现象记录 #

在算法平台练习链表反转算法时，对三种循环条件写法做了对照测试，结果如下：

• 写法1：使用松散非空判断while(head != null)

  while(head != null) {
     temp = head.next
     head.next = prev
     prev = head
     head = temp
   }
  

  运行结果正确，实测耗时96ms，内存占用43.6MB，速度排名未进入前50%。
• 写法2：直接使用真值判断while(head)

  while(head) {
     temp = head.next
     head.next = prev
     prev = head
     head = temp 
   }
  

  实测耗时降至63ms，速度超过96%的提交方案，内存占用微升至44.2MB。
• 写法3：使用严格非空判断while(head !== null)
  逻辑与写法1完全一致，仅替换相等运算符为严格相等，实测耗时64ms，速度明显快于写法1，和写法2基本持平。

性能差异的底层原理 #

关于“显式和null比较增加开销”的猜测并不准确，核心差异来自运算符本身的执行逻辑，以及JS引擎在短执行场景下的优化特性：

1. while(head)的真值判断走引擎最底层快速路径
   这种写法只需要校验值是否为JS规范定义的falsy值（null、undefined、0、''、NaN、false），是JS引擎实现中最基础的判断逻辑，不需要做任何额外的类型转换，JIT编译器甚至可以直接把这个判断编译为单步的空值检查指令，执行开销极低。在链表遍历场景下，节点遍历的终止值只有null，不会出现其他falsy值，因此这个写法逻辑完全安全。
2. while(head !== null)的严格判断几乎没有额外开销
   严格相等判断不会触发隐式类型转换，引擎只需要校验值的类型和值本身是否匹配null，判断路径长度和真值判断几乎一致，因此性能和while(head)基本持平，测试中1ms的差距属于平台运行的正常误差范围。
3. while(head != null)的松散相等带来额外类型检查开销
   性能问题的核心是!=松散相等运算符：按照ECMAScript规范，松散相等比较前必须执行隐式类型转换流程，走完整的抽象相等比较算法——引擎首先要检查两侧值的类型是否一致，类型不一致时还要按规则做类型转换后再比较。哪怕在这个链表场景里head始终是对象或者null，在代码执行的冷启动阶段，JIT编译器没有收集到足够的类型信息，不敢贸然跳过类型检查步骤，必须生成完整的类型判断、转换相关的字节码，没法走最短的快速判断路径，执行开销自然高很多。
4. 短执行场景放大了语法开销差异
   算法题的代码总执行时长极短，大部分代码跑在JS引擎的解释执行或者基线编译阶段，还没等到JIT编译器做深度热点优化，所以语法层面的字节码开销差异会被直接放大；如果是长时间运行的线上业务代码，JIT经过多轮类型收集后会把!=null的冗余检查优化掉，最终几种写法的性能差异会几乎消失。

实践建议：如果场景中明确遍历终止值只有null，优先使用while(head)写法即可；如果需要严格区分null和undefined的场景，再使用!== null的写法，尽量避免在性能敏感的短循环里使用!=做判断。另外测试中观察到的内存微小波动属于平台运行时的正常现象，和循环条件写法没有关联。

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