fetch() + replaceChildren() 是当前最稳妥的局部刷新组合，因其不解析字符串、不执行脚本、不销毁父节点，可规避 innerHTML 的 XSS 风险与事件监听器丢失问题，但需注意浏览器兼容性及 DOM 就绪时机。
fetch() + replaceChildren() 是当前最稳妥的局部刷新组合
innerHTML 看似简单，但会清空原有事件监听器、触发内联脚本执行、且对未过滤的 HTML 片段开放 XSS 攻击面。replaceChildren() 不解析字符串、不销毁父节点、不执行脚本，天然规避这些问题。
常见错误现象：TypeError: container.replaceChildren is not a function——浏览器版本过低（Chrome 86+ / Firefox 78+ / Safari 14.1+ 才支持）；Uncaught DOMException: Failed to execute 'replaceChildren' on 'Element'——传入了 null 或非节点/字符串值。
- 后端返回纯 HTML 字符串时，先用
DOMParser解析：const doc = new DOMParser().parseFromString(html, 'text/html'); container.replaceChildren(...doc.body.children); - 若后端返回 JSON，则应逐个
document.createElement()构建节点再传入replaceChildren()，避免拼接字符串 - 保留部分固定子节点（如分页控件）？别用
replaceChildren()全量替换，改用container.querySelectorAll('.dynamic-content').forEach(el => el.remove());清理后再append()新节点
容器未就绪就执行 JS 是最常被忽略的阻塞点
document.getElementById('content') 返回 null 不是因为 ID 写错，而是脚本在 DOM 加载完成前就运行了。这会导致后续所有操作静默失败，控制台也不报错（因为 null.innerHTML 是合法赋值，只是无效）。
使用场景：页面顶部内联脚本、或未加约束的模块化 JS 文件。
立即学习“前端免费学习笔记（深入）”；
- 脚本放在
<body>底部是最快捷的解法，无需额外判断 - 若必须放
<head>，包裹在document.addEventListener('DOMContentLoaded', () => { ... })中 - 不要依赖
window.onload——它等全部资源（图片、字体等）加载完才触发，延迟远高于必要
服务端返回内容格式错位直接导致前端渲染失败
局部刷新要求后端只返回「可直接插入」的 HTML 片段，比如 <div class="item">...</div><div class="item">...</div>。一旦混入 <html>、<body>、<script> 标签，DOMParser 解析后结构错乱，replaceChildren() 插入的是 head 或空文档片段。
性能影响：浏览器需额外解析完整 HTML 文档结构，哪怕只用其中一小部分，开销也远高于纯片段。
- 后端模板务必关闭 layout 包裹，例如 Express 的
res.render('list-item', { layout: false }) - Node.js 中用
fs.readFileSync读取静态 HTML 片段时，确认文件不含<html>根节点 - 调试时直接在浏览器访问接口 URL，肉眼检查响应体是否“干净”——这是比 console.log 更快的排障方式
滚动中频繁触发刷新会卡死主线程
监听 scroll 事件直接调用 fetch() 是典型反模式。用户快速滚动时，可能在 1 秒内触发几十次请求，既浪费带宽，又因并发 Promise 堆积拖慢渲染。
使用场景：长列表按需加载、锚点导航后动态填充区块、tab 切换时刷新对应区域。
- 用
IntersectionObserver替代 scroll 监听，仅在目标容器即将进入视口时触发加载 - 加防抖（debounce）不如用节流（throttle）+ 请求取消：保存上一个
AbortController实例，新请求发起前调用abort() - 对同一 URL 的重复请求，用
Map缓存 pending Promise，避免多次拉取相同内容
replaceChildren() 就能真正零阻塞地动起来。 
