esm中document.write失败是因为其执行时机晚于html解析阶段且被浏览器主动拦截。esm默认defer，执行时文档已关闭，调用会清空页面或静默失败；chrome等自v55起对跨域、异步的esm中document.write实施拦截。
ESM 模块本身并不支持 document.write，不是因为语法报错，而是因为它在模块执行上下文中根本不可用——document.write 在现代浏览器中已被明确禁用，尤其当脚本以 <script type="module"></script> 方式加载时。
为什么 ESM 中调用 document.write 会失败
document.write 只在 HTML 解析阶段、文档仍在“打开”（document.readyState === "loading"）时才有效。而 ESM 脚本默认是 defer 行为：它们会延迟到 DOM 解析完成、DOMContentLoaded 之后才执行。此时文档已关闭（document.readyState === "interactive" 或 "complete"），再调用 document.write 会直接清空整个页面，或抛出静默失败（取决于浏览器策略）。
更关键的是，Chrome 等主流浏览器自 v55 起对 document.write 实施主动拦截——若满足“跨域 + 解析阻塞 + 低网速 + 主文档顶层调用”等条件，会直接忽略该调用。ESM 脚本天然满足“主文档顶层”和“异步延迟执行”特征，因此几乎必然落入拦截范围。
ESM 的设计逻辑天然排斥 document.write
ESM 强调静态可分析性、确定性加载与作用域隔离。document.write 却是动态、副作用强、破坏解析流的典型操作：
- 它会中断 HTML 解析器，强制同步下载并执行插入的脚本，导致渲染阻塞；
- 它无法被静态分析工具识别依赖关系，破坏 tree-shaking 和构建优化；
- 它绕过模块作用域，直接操作全局文档流，与 ESM 的封装原则相悖。
这种限制实际提升了页面性能与稳定性
禁止 document.write 并非限制能力，而是推动采用更可控、可预测的替代方案：
- 用
element.innerHTML = sanitizedHTML或element.textContent替代，配合 DOMPurify 做 XSS 过滤； - 用
import()动态加载模块，按需获取逻辑而非拼接字符串； - 将内容注入交由模块内部统一管理（如通过
document.getElementById+appendChild），确保时机可控、结构清晰。
这些做法避免了页面重绘抖动、资源竞争和不可调试的副作用，使首屏时间更稳定、LCP 更可优化、调试体验更线性。
