JavaScript不使用内置Proxy类实现代理模式需处理的边界问题

要实现拦截Object A访问、打日志后转发的逻辑，放弃ES6 Proxy手动写代理时，必须覆盖以下边界，否则会出现和原生对象行为不一致的问题：

• 属性访问的基础语义兼容
  不能直接拷贝原对象的属性值做代理，必须保留原属性的所有特性：转发读写时要正确区分数据属性和getter/setter访问器属性，访问器执行时this必须绑定到原对象A，不能绑定到代理对象；属性查找要完整走原对象的原型链，不能只判断A自身的属性，访问不存在的属性时要和原生行为一致返回undefined。
  如果A是数组、Map/Set、Date这类内置实例，必须单独处理原生方法：比如数组的length属性读写、push/pop等变异方法，Map/Set的get/set方法，这类方法内部会校验对象的内部插槽，直接把方法拷贝到代理上调用会抛出"incompatible receiver"类型的错误。
• 全场景this绑定处理
  所有从代理层取出的原对象方法，不管是直接调用、解构后单独调用、还是作为回调传递到外部调用，都要保证方法执行时的this指向符合原生语义。比如原方法里有this === A的判断，不能因为经过代理层就返回false。
• 隐式访问与运算符行为覆盖
  JS很多语法会隐式触发对象访问，这些场景都不能漏：
  • 隐式类型转换：要正确转发Symbol.toPrimitive、valueOf、toString三个属性的访问，否则proxy + ''、if(proxy)这类隐式转换逻辑会和原对象不一致。注意严格相等===的行为无法手动模拟，只要代理和A不是同一个引用，proxy === A永远返回false，这个限制ES6 Proxy也无法突破。
  • 遍历与存在性判断：in操作符、for...in循环、Object.keys()/Object.getOwnPropertyNames()/Object.getOwnPropertySymbols()的返回结果要和原对象完全一致；delete proxy.key操作要转发到原对象执行，返回正确的删除结果。
  • 构造调用兼容：如果A本身是构造函数，代理被new调用时要正确转发构造逻辑，保证instanceof判断的结果符合预期。
• 对象元操作转发
  所有针对代理的元操作都要透传到原对象执行，包括Object.getOwnPropertyDescriptor()读属性描述符、Object.defineProperty()写属性描述符、Object.getPrototypeOf()/Object.setPrototypeOf()读写原型，不能在代理层单独维护一套元信息，否则会导致元编程逻辑失效。
• 特殊对象状态兼容
  如果原对象A被Object.freeze()、Object.seal()、Object.preventExtensions()处理过，或者存在不可写、不可配置的属性，代理层转发写操作时要严格遵循原对象的约束，不能私自修改属性，否则会抛出和原生场景不一致的错误。

提醒：手动代理的性能优势仅存在于极高频次的固定属性访问场景。如果A结构不固定、涉及内置对象、元操作或Symbol属性的访问，手动实现的代码复杂度和维护成本会非常高。大部分业务场景下Proxy的性能开销都在可接受范围内，建议先做实际压测再决定是否弃用Proxy。

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