JDK动态代理只能代理Map/Set等接口，不能代理HashMap/HashSet等具体类；需传入{Map.class}等接口数组，由InvocationHandler委托真实实例，并显式处理Object类方法以防递归。
Proxy 代理 Map 和 Set 实例时，直接用 Proxy.newProxyInstance 行不通——因为 JDK 动态代理只支持接口，而 Map、Set 是接口，但它们的实现类（如 HashMap、HashSet）不是接口，不能被动态代理直接“代理实例”。真正能代理的是它们的接口行为，而非具体集合对象本身。所谓「Receiver 报错」，本质是混淆了 Proxy 与 Reflect.set 的使用场景：前者用于方法调用拦截，后者用于属性赋值拦截，而 Map/Set 的增删查改走的是方法调用路径（put、add、get 等），不涉及 Reflect.set 或 receiver 参数问题。
明确代理目标：只代理接口，不代理实例
Map 和 Set 是接口，JDK 动态代理只能代理接口，不能代理具体类（如 new HashMap()）。你不能对一个 HashMap 实例做 Proxy.newProxyInstance，但可以创建一个实现 Map 接口的代理对象，并在 invoke 中委托给内部真实 Map：
- 传入的
interfaces必须是{Map.class}或{Set.class}，不能是{HashMap.class}（会抛IllegalArgumentException） - 代理对象本身不是
HashMap，而是运行时生成的$ProxyN类，它实现了Map接口，但内部持有真实 Map 实例作为 target - 所有方法调用（
put、get、size等）都经由InvocationHandler.invoke转发，不会触发属性赋值，因此不存在Reflect.set的receiver绑定问题
避开 Object 方法陷阱，防止无限递归
代理 Map 时，toString()、hashCode()、equals() 这些 Object 方法也会被转发到 invoke。若未特殊处理，直接 method.invoke(target, args) 可能导致递归（例如 target.toString() 再次触发代理）：
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 必须判断
method.getDeclaringClass() == Object.class，对这类方法直接调用target原生实现 - 不要用
method.getName().equals("toString")字符串匹配——不可靠，且无法覆盖重载或桥接方法 - 示例逻辑：
if (method.getDeclaringClass() == Object.class) {
return method.invoke(target, args);
}
正确构造代理：ClassLoader 和 target 要匹配
常见失败不是因为「Receiver 报错」，而是类加载器不一致或 target 不兼容：
-
ClassLoader必须能加载Map.class（通常用Map.class.getClassLoader()最稳妥，避免用Thread.currentThread().getContextClassLoader()在 Web 环境下出错） -
target应为实际集合实例（如new HashMap()），且需确保它真正实现了所有被代理接口的方法（比如代理Map就别传ArrayList） - 接口数组不能为空；若需同时代理
Map和Serializable，要显式写成{Map.class, Serializable.class}
需要属性级响应式？用 Proxy（ES6）而非 java.lang.reflect.Proxy
如果你实际想监听 map[key] = value 这种属性赋值操作（即 JavaScript 风格的响应式 Map），那 Java 没有原生语法支持——java.lang.reflect.Proxy 只拦截方法调用，不拦截字段访问或数组下标赋值。此时所谓「Receiver 报错」其实是误用了概念：
- Java 中
map.put("k", "v")是方法调用，走invoke，和receiver无关 - 若真需要类似 JS Proxy 的属性拦截能力，应考虑 CGLIB（代理类）、Byte Buddy（字节码增强）或自定义包装类 + 重写所有 setter/getter
- Reflect.set 是 JavaScript API，不是 Java 的——标题中混用 JS 概念导致理解偏差
