在 JavaScript 引擎中，函数也是对象，所有函数实例的隐式原型都指向 Function.prototype。当我们试图对原型上的方法做代理或重写时，操作会立刻波及每一个通过函数声明、表达式或内置构造函数产生的函数。理解原型链查找与 this 绑定机制，是安全改造的前提。
原型方法与 this 的底层关系
Function.prototype 上定义的成员（如 call、apply、bind）在调用时，引擎会通过调用者的隐式原型链找到它们。以 func.call(obj, arg) 为例，call 方法执行时内部的 this 指向 func 本身，而第一个参数 obj 会被作为新的执行上下文。如果我们在原型上替换了 call，新函数必须保证原始 this 与参数传递不被破坏，否则所有依赖原生语义的代码都会失效。
很多开发者忽略的一点是：原型方法本身就是普通函数，只不过被挂载在了共享对象上。当你用赋值方式覆盖它，旧引用就丢失了，除非手动保存。而 Proxy 并不直接替换属性，而是在 get 阶段返回包装后的函数，因此原始方法仍可通过 Reflect 或闭包访问，这种非侵入特性对大型系统尤为重要。
直接重写原型的风险与示例
下面是一段常见但危险的重写代码，它在 Function.prototype.call 前插入日志，却忘了返回原方法执行结果，也没有正确透传 this：
// 错误示例：破坏原生 call 语义
const originalCall = Function.prototype.call;
Function.prototype.call = function(context, ...args) {
console.log('call invoked on', this);
// 遗漏 originalCall.apply 调用，且未返回结果
};
function test() { return 'ok'; }
console.log(test.call(null)); // 输出 undefined，原生行为被破坏
这段代码会导致所有使用 call 的地方拿不到返回值，甚至在一些严格校验返回值的库中直接报错。另一个坑是重写时把 this 绑定错对象，例如用箭头函数定义替换方法，箭头函数没有自身 this，会继承外层 this，彻底打乱调用上下文。
即便我们保存了原方法，若在替换函数中用 function 声明却忘记用 originalCall.call(this, context, ...args) 方式调用，也会因为 this 丢失而抛出异常。因此直接重写要求作者完全清楚原生实现的每一个细节，维护成本极高。
使用 Proxy 进行安全代理
Proxy 可以包装目标对象并拦截属性读取。我们可以创建一个代理对象替换全局 Function.prototype 的引用吗？由于原型不可配置场景较多，更稳妥的做法是代理单个函数或构造器的原型，或者在模块内对特定函数做包装。以下示例展示如何用 Proxy 拦截 call 调用且保留原生行为：
// 安全代理示例：包装指定函数的原型方法
function createSafeProxy(fn) {
const proto = Object.getPrototypeOf(fn);
return new Proxy(fn, {
get(target, prop, receiver) {
if (prop === 'call') {
const original = target.call;
return function(context, ...args) {
console.log('before call, context=', context);
const result = original.call(target, context, ...args);
console.log('after call, result=', result);
return result;
};
}
return Reflect.get(target, prop, receiver);
}
});
}
function demo(a, b) { return a + b; }
const proxyDemo = createSafeProxy(demo);
console.log(proxyDemo.call(null, 1, 2)); // 正常输出 3，且带日志
上述代码中，Proxy 的 get 拦截仅在访问 call 时返回增强函数，其余属性走 Reflect.get 保证原生透明。增强函数内部通过 original.call(target, ...) 明确绑定 this 为原目标函数，因此不会破坏语义。
如果需要对所有函数生效，可以代理 Function.prototype 本身，但必须使用 Object.defineProperty 配合 writable 配置，且始终在拦截内调用原始方法。下表对比两种方案差异：
| 方案 | 侵入性 | 可恢复性 | 风险点 |
|---|---|---|---|
| 直接赋值重写 | 高，覆盖全局 | 低，需手动存原引用 | 遗漏返回、this 绑定错 |
| Proxy 包装 | 低，可局部使用 | 高，不修改原对象 | 代理嵌套、性能开销 |
实践中的避坑建议
在框架增强或 AOP 日志场景中，优先采用 Proxy 而非重写原型。若必须重写 Function.prototype.apply 等核心方法，务必先通过 const orig = Function.prototype.apply 保存，并在新函数末尾返回 orig.apply(this, arguments)。同时避免用箭头函数定义替换方法，防止 this 词法捕获。
还要注意递归代理问题：当代理的 get 中又触发了被代理属性的访问，可能陷入死循环。解决方式是在闭包中直接引用原始方法而非再次走 Proxy。最后，任何原型层面的改动都应在开发或测试环境验证全量函数调用，避免线上因微小语义偏差导致雪崩。
小结
正确处理 Function.prototype 的代理与重写，核心在于尊重原生 this 与返回值语义。Proxy 提供了不破坏原对象的安全通道，而直接重写则要求极高的实现严谨度。依据场景选择方案，才能既获得扩展能力又保障系统稳定。
Function_prototypeProxy原型重写修改时间：2026-08-08 11:54:32