为何使用Live Server运行页面时间歇出现Cannot read property 'classList' of null报错

这个报错的触发逻辑很简单：代码执行到类似document.querySelector('.xxx').classList.xxx的语句时，选择器没匹配到任何DOM节点，返回了null，这时候尝试读取null身上的classList属性，就会直接抛错。
它在Live Server环境下经常呈现“时好时坏”的不稳定状态，本质是Live Server的运行特性把原本就存在的时序竞态问题放大了：

• 脚本执行和DOM解析的竞速波动
  如果你写DOM操作逻辑时没做加载时机控制——比如把操作DOM的script标签放在head里、没加defer属性、也没等DOMContentLoaded事件触发就直接跑选择器代码，这种写法本身就有隐患。比如最常见的场景：你写了document.getElementById('nav-toggle').classList.toggle('open')，但这个id对应的按钮写在body的最末尾，脚本不加控制就放在head里执行，那跑到这行代码的时候，按钮的HTML还没被浏览器解析到DOM树里，自然拿到null。
  在普通静态文件服务下，资源加载顺序相对固定，这种代码要么每次都报错，要么每次都正常。但Live Server本身会注入热更新相关的代码、动态调整静态资源的响应优先级，不同请求的返回速度会出现随机波动：某一次JS脚本资源比HTML里的目标DOM节点先到达执行队列，找不到元素就触发报错；下一次HTML解析走到目标节点位置、脚本才开始执行，就所有功能都正常。
• 动态渲染元素的插入时机不稳定
  如果你的目标元素不是写死在初始HTML源码里的，是靠JS根据判断条件、接口返回动态生成的，那Live Server的热重载逻辑会偶尔打乱执行顺序：有时候找元素的脚本先执行完，对应的DOM节点还没被插入页面，就会拿到null；下一次热重载的时候，动态渲染的逻辑先跑完，再执行选择器代码就不会出问题。
• 外部资源加载的速度波动打破了固定阻塞逻辑
  页面如果引入了外部第三方脚本、样式表，这些资源的加载速度会因为缓存命中、Live Server文件监听触发的重新编译出现随机变化。正常情况下，被引入的外部脚本加载完成后，浏览器才会继续解析后面的HTML，等你的DOM操作脚本跑的时候，所有目标节点都已经在DOM树里了，自然不会报错；但如果某次外部资源被浏览器完整缓存，瞬时就加载完成，就会导致DOM操作脚本比预期时机提前执行，跳过了还没被解析到的目标节点，最终因为拿到null触发classList的读取错误。

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