Proxy 无法拦截 Map、Set、Date、RegExp 等内建对象的私有内部槽，因其方法依赖原始实例的内部状态，而 Proxy 实例无此槽位，导致方法失效或报错。
Proxy 无法真正拦截 Map、Set、Date、RegExp 等内建对象的“私有内部槽”（internal slots），这不是 bug，而是 JavaScript 规范的设计限制。这类问题的典型表现是：代理后方法调用返回 undefined 或 NaN，甚至静默失败，但控制台无报错——根本原因在于这些方法依赖对象自身的内部状态，而 Proxy 包裹后，this 指向 proxy 实例，无法访问原始目标的内部槽。
看行为异常：三类典型失灵信号
遇到以下情况，大概率是内部槽访问失效：
-
Date 方法返回 NaN：如
p.getFullYear()返回NaN，但p.toString()正常 —— 因为getFullYear读取 [[DateValue]] 槽，而toString是普通方法调用（可被 get 拦截） -
Map/Set 方法不生效或报错：如
proxyMap.set('a', 1)无反应，proxyMap.size仍为 0；或proxySet.has(x)总返回false—— 它们依赖 [[MapData]] / [[SetData]] 槽，Proxy 的set或gettrap 无法触达 -
正则方法返回空或类型错误：如
proxyRegex.test('abc')报TypeError: Method RegExp.prototype.test called on incompatible receiver—— 表明 this 绑定失败，内部校验拒绝非原生 RegExp 实例
查构造方式：是否直接代理了内建实例
只要写的是 new Proxy(new Map(), handler) 或 new Proxy(new Date(), handler)，就已落入陷阱。内部槽只对原始构造实例有效，Proxy 是全新对象，没有这些槽位。即使你在 get 中用 Reflect.get(target, prop, target) 显式绑定 this，apply trap 也拦不住底层槽读取逻辑。
验证方法很简单：
- 打印
Object.prototype.toString.call(proxy)：若返回[object Map]，说明外观像 Map，但不是真正的 Map 实例 - 检查
proxy instanceof Map：结果为false（除非你手动重写getPrototypeOftrap 并返回 Map.prototype，但这不解决内部槽问题）
绕过而非强拦：替代方案比修复更实际
面对内部槽不可代理的事实，硬在 Proxy 里修补所有方法（如手写 get 中对 size、has、get 全部 target.xxx.call(target)）既繁琐又不可靠。更务实的做法是：
-
用包装器模式替代直接代理：创建一个普通对象，把 Map 实例作为私有字段存入，所有操作通过方法委托，再在方法中加拦截逻辑。例如：
class TrackedMap { #map = new Map(); get size() { console.log('size accessed'); return this.#map.size; } } -
对关键属性做白名单代理：如果只需监听某些字段（如 Map 的
size变化），可用Object.defineProperty+ getter/setter 封装，避免碰触内部方法 - 改用 WeakMap 存储元信息：把代理逻辑所需的额外状态（如访问日志、权限标记）存在 WeakMap 中，键为原始 Map 实例，避免污染目标对象
记住这个边界：Proxy 不是万能壳
它能拦截规范定义的“抽象操作”（如 [[Get]]、[[Set]]），但对引擎私有的内部槽（[[MapData]]、[[DateValue]]、[[RegExpMatcher]] 等）完全无权访问。这不是 Reflect API 的缺陷，而是语言安全模型的一部分——防止用户代码绕过内建对象的封装约束。所以，识别这类问题的核心，就是看“出问题的方法是否依赖对象身份和内部状态”，而不是看它是否属于某个对象的属性。
