DOM解析中断主因是脚本执行时机不当，如document.querySelector在元素未解析时调用致null错误；修复应优先确保元素存在，推荐用defer属性（仅限外部脚本）使脚本在DOM就绪后执行。
DOM 解析中断不是“页面卡住”，而是浏览器在解析 HTML 时被脚本错误打断，后续标签不建模、不渲染——根本原因往往不是代码写错了，而是执行时机或上下文不对。
document.querySelector 返回 null 导致后续报错
这是最常见诱因：脚本在 #myForm 元素还没被解析进 DOM 时就调用 document.querySelector('#myForm')，返回 null；紧接着对 null 调用 .addEventListener()，抛出 TypeError: Cannot read property 'addEventListener' of null，浏览器直接中断 DOM 构建流程。
- 典型场景：把
<script>放在<head>里，且没加defer或async - 验证方法：打开开发者工具 → Console，看是否有类似错误；再切到 Elements 面板，检查目标元素是否真的没出现在 DOM 树中
- 修复优先级：比改逻辑更重要的是确保元素存在 —— 不要靠 try/catch 掩盖问题，要从加载顺序根治
使用 defer 属性让脚本等 DOM 就绪再执行
defer 是原生 HTML 解决方案，不需要监听事件、不依赖框架，且兼容所有现代浏览器（IE10+）。
- 必须满足两个条件才生效：脚本是外部文件（
<script src="xxx.js"></script>），且属性写法为defer（不能带值，如defer="true"无效） - 效果：脚本下载与 HTML 解析并行，但执行严格推迟到整个文档解析完成、
DOMContentLoaded触发前 - 注意：多个
defer脚本按出现顺序执行，适合有依赖关系的模块；但不能用于动态插入的<script>标签
DOMContentLoaded 事件不是万能兜底
很多人以为包一层 document.addEventListener('DOMContentLoaded', ...) 就安全了，但实际容易踩坑：
立即学习“前端免费学习笔记（深入）”；
- 如果脚本本身被浏览器标记为“parser-blocking”（比如没加
async/defer的内联脚本），它会阻塞 HTML 解析，此时DOMContentLoaded还没机会触发，错误已在前面发生 - 该事件只保证 DOM 构建完成，不保证资源（如图片、字体、CSS）加载完毕；若脚本依赖
offsetHeight等布局信息，仍可能读到 0 - 在旧版 IE（window.onload，但后者等全部资源加载完，延迟更高
内联脚本必须放在目标元素之后
如果非要用内联脚本（比如快速调试、服务端模板注入），唯一可靠方式是把它写在目标元素闭合标签之后：
<form id="myForm">...</form>
<script>
// ✅ 此时 myForm 已在 DOM 中
document.querySelector('#myForm').addEventListener('submit', handler);
</script>
这种写法不依赖任何事件或属性，浏览器解析到 script 时，前面的 form 标签早已完成建模。但要注意：<body> 末尾才是最安全位置，避免嵌套结构意外截断。
真正难处理的不是语法错误，而是“脚本跑太快，DOM 还没跟上”——修复重点永远在加载链路，而不是补救报错逻辑。
