动态脚本加载的最佳实践:可控、可追踪、可销毁
在前端开发中,通过动态创建 script 标签并插入 DOM,是实现按需加载脚本的常用技术。然而,这一操作若不遵循规范,极易引发执行顺序错乱、重复加载、错误捕获缺失等问题。归纳而言,核心原则可总结为三点:可控、可追踪、可销毁。

防重复加载:确保脚本的唯一性
同一脚本被多次插入会导致重复执行,尤其在模块被多次请求时更为突出。一种稳妥的做法是维护全局缓存,记录所有已发起请求的脚本 URL。
具体的落地方式有以下几点需要注意:
- 建议使用 Map 或 Set 来存储已发起请求的
script src地址。需注意 URL 是否包含查询参数,这会影响缓存键的唯一性。 - 插入前应先检查页面上是否已存在对应
元素,或该 URL 是否已在缓存中。双重检测更可靠。 - 尽量避免仅依赖
id属性判断——id 可能缺失或与其他脚本冲突。最可靠的判断依据仍是src字符串本身。
把握加载生命周期:监听、清理、超时处理
仅仅插入脚本还不够,必须精确监听脚本的 load 和 error 事件。而且,不应仅依赖 onload 属性——它虽灵活,但解绑不便。
正确做法是使用 addEventListener 绑定事件,后续可借助 removeEventListener 及时解绑,防止内存泄漏。
load回调触发时,应执行后续业务逻辑,例如 resolve 一个 Promise。error回调中,不仅要 reject Promise,还可上报异常信息便于排查问题。- 如果脚本插入后长时间无响应(如超过 10 秒),应主动 abort 并清理相关资源——移除标签、清除定时器等。
插入位置与执行上下文:怎么放,放在哪
脚本默认在插入点执行,但 async 和 defer 属性会影响其行为。因此插入前需明确意图。
- 按需加载时,通常设置
async = true,保证非阻塞加载。但如果脚本之间有执行顺序依赖,则需改用defer,或手动实现串行加载。 - 统一插入到
document.head是好习惯——它比操作document.body更可靠,可避免因插入位置不同导致 CSSOM 或 JS 执行时机出现差异。 - 避免直接往
document.body插入——页面未 ready 时 body 可能为null,导致报错。
支持清理与降级:精致的脚本生命周期管理
动态脚本也应具备“可卸载”意识。尤其在 SPA(单页应用)中,组件销毁或路由切换时,若未及时清理脚本,会成为资源负担。
- 创建脚本元素时保存引用,并提供
unload()方法,用于移除标签、清空缓存项、解绑事件监听器。 - 对于不支持 ES 模块或较新 API 的旧环境(如旧版 IE 浏览器),需准备 fallback 方案——可以是 JSONP,或极少数场景下使用
document.write(需谨慎使用)。 - 如果主加载路径失败,可准备备用路径,例如从 CDN 备源或本地 fallback 文件重新加载。
总体来说,每次动态创建脚本,都应具备明确的加载标识、错误兜底和资源回收路径。编写函数时,建议返回一个 Promise,并对外暴露 cancel 方法,方便调用方主动干预加载过程。
动态加载脚本并非“插进去就不管了”,而是一个完整的生命周期管理过程。遵循这三条原则,才能确保代码在各种加载场景下稳定可靠地运行。
