JS动态注入脚本的三种方法：createElement、innerHTML与document.write对比

一、首选标准方案：document.createElement('script')

document.createElement('script') 是 W3C 与 WHATWG DOM 标准中创建并挂载脚本节点的正统 API。无论是主流的按需加载工具（如 Webpack 动态导入底层 polyfill）、第三方统计埋点 SDK，还是单页应用（SPA）的路由级异步加载，均基于此接口构建。

1. 标准四步操作流程

使用 createElement 注入外部脚本遵循严谨的生命周期步骤：

1. 创建节点：调用 document.createElement('script') 在内存中分配 HTMLScriptElement 对象，此时不产生任何网络流量。
2. 配置属性：设置 src 目标路径，并根据执行需求配置 async 或 defer 标识。
3. 绑定生命周期钩子：在挂载之前注册 onload 与 onerror 事件，精确获知资源加载与初始化结果。
4. 挂载入 DOM 树：通过 document.head.appendChild(script) 或 document.body.appendChild(script) 插入文档，此时浏览器网络层被正式触发，开始拉取文件并择机执行。

2. 完整代码示例：异步外部脚本加载

// 健壮的动态脚本加载基础函数
function loadExternalScript(url) {
  return new Promise((resolve, reject) => {
    // 1. 创建 script 元素
    const script = document.createElement('script');
    
    // 2. 配置属性：默认动态创建的 script.async 为 true（非阻塞）
    script.src = url;
    script.async = true;
    script.crossOrigin = 'anonymous';

    // 3. 必须在挂载前绑定事件，防止强缓存命中导致事件丢失
    script.onload = () => {
      resolve({ status: 'loaded', url });
    };
    
    script.onerror = () => {
      // 发生网络错误或 404 时及时清理并抛出异常
      script.remove();
      reject(new Error(`Failed to load script: ${url}`));
    };

    // 4. 插入 DOM 树激活网络下载
    document.head.appendChild(script);
  });
}

// 使用示例
loadExternalScript('https://cdn.example.com/sdk.js')
  .then(() => console.log('SDK 初始化完毕'))
  .catch(err => console.error(err));

3. 动态内联脚本的注入

如果需要动态执行一段本地生成的代码字符串，使用 createElement 同样是最规范的做法。通过设置 script.textContent 或 script.text，挂载后会立即同步执行：

const inlineScript = document.createElement('script');
inlineScript.textContent = 'console.log("内联脚本同步执行成功");';
document.head.appendChild(inlineScript);
// 执行完毕后推荐将标签移除，保持 DOM 干净整洁
inlineScript.remove();

二、为何 innerHTML 无法正常注入运行脚本：HTML5 安全防御机制

许多初学者在需要插入一段带有 HTML 与 JavaScript 混合的代码片段时，会直觉性地采用如下写法：

const box = document.getElementById('container');
// 直觉做法：向 innerHTML 中塞入 script 标签
box.innerHTML = '<script src="https://cdn.example.com/app.js"></script>';

1. 实际表现与规范原因揭秘

上述代码运行后，打开浏览器的开发者工具检查元素面板，你会发现 <script> 标签确实被成功添加到了 #container 节点之下。然而在网络面板（Network）中，浏览器压根没有发出任何 HTTP 请求；若在标签内写内联脚本，控制台也不会打印任何信息。

这并不是浏览器 Bug，而是 HTML5 规范刻意规定的安全防御机制。在 W3C HTML5 规范关于 innerHTML 的解析算法中明确指出：

2. 为什么 innerHTML 仍容易导致 XSS 漏洞？

既然 innerHTML 不执行 <script> 标签，为什么它依然是前端最臭名昭著的跨站脚本攻击（XSS）入口？

原因在于：HTML5 仅拦截了直接声明的 <script> 标签，但无法拦截其他 HTML 元素的内联事件处理器属性。攻击者只需要构造带有错误触发或伪协议的标签即可轻松绕过，例如：

// innerHTML 会拦截下面这个：
box.innerHTML = '<script>alert("test")</script>'; // 不执行

// 但 innerHTML 绝不会拦截带有 onerror 的图片标签：
box.innerHTML = '<img src="invalid-url" onerror="alert(document.cookie)">'; // 立即执行！

因此，绝不能将 innerHTML 当作动态运行脚本的手段；在处理不可信的用户输入时，更应严格使用 textContent 或成熟的 DOMPurify 过滤库。

三、传统 document.write() 的致命缺陷与生命周期陷阱

document.write() 产生于上个世纪 JavaScript 刚刚诞生的网景（Netscape）时代。它的设计逻辑是直接向当前的文档输出流（Document Output Stream）写入原始字节字符串。虽然在 2000 年前后的老旧网页中极为普遍，但在现代 Web 应用中，它是最具破坏性且必须杜绝的 API。

1. 致命缺陷一：页面渲染后调用导致“全页清空白屏”

文档流具有严格的生命周期。当浏览器解析 HTML 文档时，文档流处于开启状态；一旦首屏解析完成（例如触发 DOMContentLoaded 或 window.onload 事件后），浏览器会自动关闭文档输出流（相当于内部调用了 document.close()）。

此时，如果在异步操作、用户点击事件或延迟回调中调用 document.write()：

// 错误场景：页面已经加载完成，用户点击按钮时执行动态注入
button.addEventListener('click', () => {
  // 此时文档流已关闭，调用 document.write 会隐式自动执行 document.open()！
  document.write('<script src="https://cdn.example.com/tool.js"></script>');
  // 结果：整页原本的所有 DOM 结构、CSS 样式、React/Vue 实例全部被瞬间抹除！
});

2. 致命缺陷二：同步阻塞主线程与现代浏览器介入拦截（Intervention）

即使在首屏文档解析期间使用 document.write()，它也会强行打断浏览器的预解析器（Pre-parser），迫使主线程停下来等待外部脚本串行下载并执行，导致网页首屏绘制时间（FCP/LCP）严重恶化。

正是由于这一行为对移动端性能极具破坏力，自 Chrome 55 起，Chromium 团队推行了著名的 Chrome Intervention 策略：

• 在 2G/3G 或慢速网络连接环境下；
• 在页面首屏渲染解析期间通过 document.write() 插入的第三方跨域外部脚本；
• 现代浏览器将直接拒绝加载该脚本，并在开发者工具 Console 中输出高危警告：
  [Intervention] Blocked cross-origin request to ... via document.write。

四、三种方法的横向对比与特性矩阵

为了在技术选型与代码审查中建立清晰的评估标准，下表从执行可行性、性能表现、生命周期控制及安全维度对三种方式进行全面对比：

五、生产环境通用脚本加载器封装与实战技巧

在实际生产环境中，动态加载外部脚本不能仅仅写一行简单的 appendChild，还需要处理并发去重、网络超时、CSP 鉴权凭证以及执行依赖顺序。以下是一个工业级的通用动态脚本加载器实现：

/**
 * 生产级动态脚本加载器
 * 特性：自动去重、超时熔断、支持 CSP nonce、Promise 化
 */
class ScriptLoader {
  static _cache = new Map();

  static load(url, options = {}) {
    const {
      timeout = 10000,
      nonce = '',
      attributes = {}
    } = options;

    // 1. 防止重复加载相同资源
    if (this._cache.has(url)) {
      return this._cache.get(url);
    }

    const promise = new Promise((resolve, reject) => {
      const script = document.createElement('script');
      script.src = url;
      script.async = true;
      if (nonce) script.nonce = nonce;

      // 挂载用户自定义扩展属性
      Object.keys(attributes).forEach(key => {
        script.setAttribute(key, attributes[key]);
      });

      // 超时定时器处理
      const timer = setTimeout(() => {
        cleanup();
        reject(new Error(`Script loading timed out after ${timeout}ms: ${url}`));
      }, timeout);

      function cleanup() {
        clearTimeout(timer);
        script.onload = null;
        script.onerror = null;
      }

      script.onload = () => {
        cleanup();
        resolve({ status: 'ready', url });
      };

      script.onerror = () => {
        cleanup();
        script.remove();
        this._cache.delete(url);
        reject(new Error(`Network error while loading script: ${url}`));
      };

      document.head.appendChild(script);
    });

    this._cache.set(url, promise);
    return promise;
  }
}

六、总结与开发建议

梳理 JavaScript 动态注入脚本的三种途径，其技术演进与规则边界非常清晰：

• 唯一正解：始终使用 document.createElement('script')。它具备完全的异步并发控制、完备的生命周期状态捕获能力，并受到现代 CSP 安全策略的全面支持。
• 认知误区：彻底放弃 innerHTML 运行脚本的幻想。HTML5 规范已从底层阻断了该路径，若试图通过构造带有事件属性的字符串绕过限制，往往只会给系统引入严重的 DOM XSS 漏洞。
• 坚决废弃：在任何现代 Web 场景中禁止书写 document.write()。它的页面清空白屏风险与解析阻塞行为已不适应任何现代工程化与组件化开发。