猴子补丁场景下如何替代eval()？浏览器扩展合规适配咨询

嘿，这个问题我太熟了！Mozilla对eval的限制确实卡得很严，毕竟它一直是XSS和代码注入风险的重灾区。不过别担心，完全有安全合规的替代方案来实现猴子补丁的效果，而且比用eval更稳健，我给你列几个常用的：

这是最稳妥也最常用的方式，完全不碰任何动态执行代码的手段，就是对目标函数做一层“包装”——先保存原始函数的引用，再替换成我们自己的函数，在里面插入补丁逻辑后再调用原始函数。

比如你要拦截fetch请求的话，代码会是这样：

// 先把原始函数存起来，别弄丢了
const originalFetch = window.fetch;

// 替换成我们的包装函数
window.fetch = async function(...args) {
  // 这里写你的补丁逻辑，比如修改请求参数、打印日志
  console.log('抓到一个请求:', args[0]);
  
  // 调用原始函数，记得用apply/call保持this指向和参数正确
  const response = await originalFetch.apply(this, args);
  
  // 也可以在这里修改响应内容
  return response;
};

这种方式完全符合Mozilla的安全规范，审核人员绝对挑不出毛病。

如果你的补丁目标是某个类的实例方法，直接修改它的原型链方法就行，原理和上面一样，但更适合类的场景。

比如要patchElement.prototype.appendChild来记录页面添加的元素：

const originalAppendChild = Element.prototype.appendChild;

Element.prototype.appendChild = function(child) {
  // 补丁逻辑：记录添加的元素
  console.log('页面新增元素:', child.tagName);
  
  // 调用原始方法，保持原有功能正常
  return originalAppendChild.call(this, child);
};

同样，这里没有任何动态代码执行，纯静态的函数引用替换，安全得很。

如果你之前用eval是因为需要根据不同配置动态切换补丁逻辑，那可以把所有可能的逻辑都预定义成函数，用配置项来选择对应的逻辑，彻底避开动态执行。

举个例子：

// 先把所有可能的补丁逻辑都写好，存成一个映射表
const patchHandlers = {
  logRequest: (args) => { console.log('请求URL:', args[0]); },
  addCustomHeader: (args) => { 
    args[1].headers = {...args[1].headers, 'X-My-Extension': 'active'}; 
  }
};

// 保存原始fetch
const originalFetch = window.fetch;

// 从配置里读取要启用的补丁（比如用户设置里选的）
const activePatch = 'logRequest';

window.fetch = async function(...args) {
  // 执行选中的预定义逻辑
  if (patchHandlers[activePatch]) {
    patchHandlers[activePatch](args);
  }
  
  return originalFetch.apply(this, args);
};

这样哪怕需要动态切换补丁，也不用碰eval，完全合规。

• 补丁时机要选对：确保在目标函数/类已经加载完成后再执行补丁，比如在扩展的content script里用run_at: document_idle，或者监听DOMContentLoaded事件后执行，避免补丁失效。
• 别破坏原有逻辑：一定要记得调用原始函数，并且用apply/call正确传递this和参数，不然页面原有功能可能直接崩了。
• 审核时说明清楚：提交Mozilla审核时，可以在备注里提一句你用的是静态函数包装的方式，没有使用动态代码执行，能帮审核人员快速通过。

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