dom解析中断是浏览器解析html时被脚本错误强制打断，导致后续标签不处理、元素不创建、事件绑定失效；修复关键在于切断错误传播链，而非事后捕获。
DOM 解析中断不是“页面崩溃”，而是浏览器在解析 HTML 时被脚本错误强制打断，后续标签不被处理、元素不创建、事件绑定失效——修复核心是切断错误传播链，而非等报错后再 try/catch。
document.write() 或同步脚本阻塞导致的解析中断
当 document.write() 在 DOM 已加载后执行，或外部脚本中含同步死循环、未捕获异常，浏览器会直接终止 HTML 解析，后续 DOM 节点永远不生成。这不是 JS 运行时错误，而是解析器层面的中断。
- 避免在任何非初始加载阶段调用
document.write()；现代项目里它基本该被标记为禁用 - 检查第三方 SDK（如旧版统计代码、广告脚本）是否含隐式
document.write()，用curl -s URL | grep -i write快速扫描 - 同步脚本若必须执行耗时逻辑，请拆成
setTimeout(fn, 0)或queueMicrotask()让出主线程，防止解析卡死
DOMContentLoaded 触发前就操作 DOM 的典型失败路径
脚本放在 里，又没加 defer 或 async，就会在 标签还没解析到时就执行 document.querySelector('#form') —— 返回 null，接着调 .addEventListener() 报错，整个脚本 halt，后面所有初始化逻辑全丢弃。
- 优先用
<script defer src="main.js"></script>：保证执行顺序，且 DOM 构建完成后再运行 - 不用
async：它不保序，多个 async 脚本谁先下载完谁先执行，依赖关系易乱 - 如果必须内联脚本，包裹在
document.addEventListener('DOMContentLoaded', () => { ... })里，但注意这比defer多一次事件调度开销 - React/Vue 等框架项目中，不要在
mounted/useEffect外直接查 DOM，尤其别在模块顶层写document.getElementById
HTML 结构不合法引发的静默解析失败
缺少闭合标签（如 <div><p>内容</p></div>）、自闭合标签误写（<img src="x">）、或在 <table> 里直接放 <code><div>，会导致浏览器纠错模式启动，DOM 树结构与预期严重偏离——你找的元素可能根本不在你以为的位置。
<ul>
<li>用浏览器开发者工具的 Elements 面板手动展开 DOM，确认目标节点是否真实存在、嵌套层级是否符合预期</li>
<li>运行 <code>console.log(document.body.innerHTML) 对比原始 HTML，看浏览器是否已重写结构
脚本错误未被捕获导致后续初始化丢失
一个表单提交 handler 里 emailjs.send() 报错，没加 try/catch，整个事件回调中断，后面本该执行的 loading 状态切换、按钮禁用等逻辑全失效——用户点不动、没反馈、以为页面卡了。
- 对所有第三方 API 调用（
emailjs.send()、fetch()、localStorage.setItem()）做最小粒度try/catch，错误至少打到console.error() - 用
window.addEventListener('error', e => { ... })捕获全局未处理错误，但注意它抓不到 Promise reject，得另配window.addEventListener('unhandledrejection', ...) - 关键路径上别依赖单点脚本成功：表单提交失败时，用
localStorage缓存用户输入，刷新后自动还原，而不是直接丢数据 - 避免在
onload或DOMContentLoaded回调里堆叠长串逻辑；拆成小函数，每个函数独立 try/catch，失败不影响其余流程
DOM 解析中断最麻烦的地方在于它不报红字错误，只表现为“某块区域没渲染”“某个按钮点不了”——你得从浏览器 Elements 面板开始逆向排查，而不是盯着 Console 里最后一条 log。真正的修复发生在脚本执行前，不是错误发生后。
