Greasemonkey 中如何将用户脚本作为通用JS库供其他脚本调用？

首先明确结论：完全支持将独立的用户脚本作为通用JS库给其他脚本复用，这是Greasemonkey从设计之初就支持的代码复用机制，不需要复杂的跨沙箱通信逻辑。

核心实现方式：通过@require语法引入库脚本 #

这是当前最成熟、性能最好的复用方案，具体写法和注意事项如下：

第一步：适配你的库脚本 #

把准备作为库的独立脚本做两个调整，保证引入后能正常被调用：

• 不要把所有对外暴露的方法、变量都封装在闭包内部，需要将可复用的能力挂到全局上下文中，比如：

  // 库脚本的核心暴露逻辑示例
  window.CommonLib = {
    fetchData: (url) => fetch(url).then(res => res.json()),
    escapeHtml: (str) => str.replace(/[&<>"']/g, s => ({'&':'&amp;','<':'&lt;','>':'&gt;','"':'&quot;',"'":'&#39;'}[s]))
  }
  

• 如果库不需要权限类API，可以把脚本的@grant设置为none，减少沙箱对代码执行的限制，降低调用方的权限配置成本。

第二步：在调用方脚本中配置@require #

按照Greasemonkey的元数据规范，在调用脚本的头部配置区，通过@require声明库脚本的可访问地址。脚本管理器在处理@require资源时，会自动识别并剔除资源内容里的UserScript元数据注释，哪怕被引入的库是带完整元数据头的独立可运行用户脚本，也不会影响正常加载执行。常见的合法写法：

• 如果是公网托管的库脚本（比如发布在用户脚本平台的版本），直接填写脚本对应的raw访问地址即可，示例配置：

  // ==UserScript==
  // @name         业务功能脚本A
  // @namespace    your-namespace
  // @version      1.0.0
  // @require      https://example.com/path/to/common-lib.user.js
  // @grant        none
  // ==/UserScript==
  

• 本地调试场景下，可以通过支持本地路径的脚本管理器（如Violentmonkey、Tampermonkey）测试，此时@require可以直接写本地文件的绝对路径。

注意：原生Greasemonkey出于安全策略限制，默认禁止通过@require引入file://协议的本地脚本路径，这类场景下需要将库脚本托管到可公开访问的HTTPS地址才能正常加载。

关键注意点 #

• @require的加载顺序和书写顺序完全一致，一定要把库脚本的@require行放在所有业务代码对应的加载项之前，否则会出现库未加载完成就被调用的报错。
• 权限要对齐：如果库代码里用到了Greasemonkey专属API（比如GM_setValue、GM_xmlhttpRequest），调用方脚本必须在自己的@grant配置中声明对应的权限，否则就算库代码加载成功，调用API时也会因为权限不足执行失败。
• 做好版本绑定：@require引入的线上库会被脚本管理器缓存，不会每次都拉取最新版本，如果要避免库更新不兼容导致业务脚本崩溃，建议在@require地址中固定对应版本的路径，或附加版本校验参数。

其他可选的复用方案 #

• 内嵌代码复用：如果库的代码量很小，可以直接把可复用的方法写在每个业务脚本的顶部，不用单独拆成独立库。缺点是多脚本复用的时候维护成本极高，每次调整库逻辑都要同步修改所有关联脚本。
• 跨脚本事件通信：如果需要让两个已经在页面上运行的独立脚本互相调用能力，可以通过GM_addValueChangeListener、GM_setValue这类跨脚本通信API实现方法传递。这种方式适合临时的跨脚本交互，不适合做长期维护的通用库，因为方法序列化会丢失闭包、原型链等JS特性，实现复杂度高。
• 动态按需加载：如果脚本管理器支持ES模块语法，可以在业务逻辑触发时通过动态import()的方式拉取库代码，减少脚本初始化阶段的加载体积，适合大体积的工具库场景。

内容的提问来源于stack exchange，提问作者znanija2021