document.write会阻塞html解析并清空文档，导致白屏、整页刷新及hydration失败；应改用innerhtml、动态创建元素或服务端渲染等安全替代方案。
别用 document.write，尤其在现代页面中——它会同步阻塞 HTML 解析，且在 DOM 加载完成后调用直接清空整个文档。
为什么 document.write 会阻塞渲染
浏览器解析 HTML 是流式进行的。当遇到 document.write，它必须立即执行并写入内容，期间暂停 HTML 解析器，等 JS 执行完、写入完成、新内容被重新解析后才继续。这意味着：
- 后续所有 HTML 标签（包括
<link>、<script></script>、<img>）都得排队等待 - 如果写入的是外部资源（比如
document.write('<script src="a.js"></script>')），还会触发额外网络请求，进一步拉长白屏时间 - 在
DOMContentLoaded之后调用，document.write会隐式调用document.open()，清空当前文档并重开流——用户看到的就是整页刷新式闪退
document.write 在现代框架/构建流程中的实际风险
很多老代码或第三方统计脚本仍依赖它，但和现代前端实践天然冲突：
- Webpack/Vite 等打包工具默认将 JS 注入
或底部，此时 DOM 可能已加载完成，document.write直接清空页面 - 服务端渲染（SSR）或静态生成（SSG）页面里混入
document.write，会导致 hydration 失败或内容错乱 - Lighthouse 会明确标记为「避免使用
document.write」，影响性能评分 - Chrome 已对跨域 iframe 中的
document.write加强限制，部分场景直接报DOMException
安全替代方案：按场景选方法
不是所有动态写入都要砍掉，关键是选对时机和方式：
- 想插入一段 HTML 到某个容器？用
element.innerHTML = htmlString（注意 XSS 风险，需转义） - 想动态加载脚本？用
document.createElement('script')+appendChild，或更现代的import()动态导入 - 广告/统计等第三方代码？优先走异步加载 + 回调机制；若必须兼容旧 SDK，加
if (document.currentScript)判断执行时机，或包裹在setTimeout延迟到 DOM 就绪后 - 服务端已知要插入的内容？直接由后端模板或 SSR 渲染，避免客户端拼接
真正麻烦的不是语法本身，而是它把“执行时机”这个隐含条件暴露成了运行时行为——而现代前端工程里，时机几乎全靠生命周期和调度控制。一旦漏判，就是整页重绘或白屏几秒。
