完美转发代理需用reflect而非直接操作target，因其能严格模拟引擎行为、保留getter/setter、正确处理this绑定与symbol属性，并通过receiver参数保障原型链完整；handler必须覆盖get、set、has、ownkeys、deleteproperty五项并统一使用reflect转发，才能实现零损耗拦截与语义一致的还原。
构建“完美”的转发代理，关键不在完全屏蔽原始行为，而在于零损耗地拦截 + 可靠地还原默认操作。proxy 负责捕获动作，reflect 负责原样执行——二者配合，才能做到既可观察、又不破坏语义。
为什么必须用 Reflect 而不是直接操作 target？
直接写 target[prop] = value 或 target[prop] 会绕过原型链上的 getter/setter、丢失 this 绑定、无法处理 Symbol 属性的正确访问，甚至在严格模式下对不可写属性赋值会静默失败。Reflect 方法则严格模拟 JavaScript 引擎的内部行为，参数完整、返回明确、语义一致。
-
Reflect.get(target, prop, receiver)确保 getter 中的this指向代理本身（而非 target） -
Reflect.set(target, prop, value, receiver)返回布尔值，明确告知是否成功（Object.defineProperty抛异常，它只返回false） -
Reflect.has、Reflect.deleteProperty等全部对应底层内部方法，无歧义
基础转发代理：一个不能少的三要素
真正健壮的转发代理，handler 至少要覆盖 get、set、has、ownKeys、deleteProperty 这五个核心捕获器，并统一使用 Reflect 转发。漏掉任一环节，都可能造成行为不一致。
-
get和set必须传入receiver参数（通常是 proxy 自身），否则继承链中断 -
ownKeys决定Object.keys()、for...in等枚举结果，不实现会导致代理后无法遍历 -
has影响prop in proxy的结果，不实现会退化为默认逻辑（可能不符合预期）
避免常见陷阱：receiver、不可扩展与冻结对象
即使只是转发，也要预判目标对象的状态。比如对 Object.freeze(obj) 创建代理时，set 拦截中若不检查 Object.isExtensible(target) 或 !Object.getOwnPropertyDescriptor(target, prop)?.writable，就直接调用 Reflect.set，会因底层拒绝而抛错。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 对不可扩展对象，
defineProperty和新增属性会失败，可在set中提前判断并处理 - 对 sealed/frozen 对象，
deleteProperty应返回false，而不是让Reflect.deleteProperty抛错 - 始终用
Reflect.getOwnPropertyDescriptor获取属性描述符，比Object.getOwnPropertyDescriptor更可靠
进阶：透明代理与原型代理的区分
“完美”还意味着区分操作意图。例如，想让 proxy instanceof SomeClass 成立，就必须在 getPrototypeOf 和 isExtensible 等捕获器中也做 Reflect 转发；若希望代理自身可被 instanceof 识别为新类型，则需自定义 getPrototypeOf 返回代理构造器的 prototype。
- 透明转发：所有 Reflect.xxx 都原样调用，proxy 行为 ≈ target 行为
- 增强转发：在 Reflect 调用前后插入逻辑（如日志、验证），但不改变返回值和副作用
- 协议级转发：连
apply、construct、getPrototypeOf都覆盖，让函数/类代理也成立
不复杂但容易忽略：真正的转发代理不是写几个 get/set 就完事，而是把 Proxy 支持的每个可拦截操作，都用对应的 Reflect 方法兜住，并尊重目标对象的元状态。这样才经得起 Object.assign、JSON.stringify、解构、in、for...in 等各种场景的考验。
