17370845950

在使用JavaScript Proxy包装第三方库函数时，开发者可能会在开发环境运行正常，但在生产构建中遭遇TypeError，尤其涉及Reflect.get的receiver参数。本文深入探讨了Proxy#get和Reflect.get中receiver参数的正确用法，解释了为何不当使用会导致生产环境报错，并提供了正确的代码实践，以确保Proxy行为在所有环境中一致且健壮。

理解Proxy与Reflect.get中的receiver参数

在JavaScript中，Proxy对象允许你拦截并自定义对目标对象的各种操作。其中，get陷阱（trap）用于拦截属性读取操作。当一个属性被读取时，Proxy的get方法会被调用，其签名如下：

get(target, property, receiver)

• target: 被代理的目标对象。
• property: 被访问的属性名。
• receiver: Proxy本身，或者继承Proxy的对象（如果Proxy作为原型链的一部分）。这个参数表示最初接收到属性访问的对象。

在get陷阱内部，我们常常会使用Reflect.get来获取目标对象的原始属性值。Reflect.get的签名如下：

Reflect.get(target, propertyKey, receiver)

• target: 要从中获取属性的对象。
• propertyKey: 要获取的属性的名称。
• receiver: 如果target上的propertyKey是一个getter函数，那么receiver将作为该getter函数执行时的this上下文。如果propertyKey是一个普通数据属性，receiver通常会被忽略。

生产环境TypeError的根源

当尝试使用Proxy来修改MUI的styled函数时，原始代码示例如下：

import * as muiSystem from '@mui/system';

type CreateMUIStyled = typeof muiSystem.styled;
type MUIStyledParams = Parameters;

const system = new Proxy(muiSystem, {
  get(target, prop, receiver) {
    if (prop === 'styled') {
      // 问题所在：将Proxy的receiver直接传递给了Reflect.get
      const styled = Reflect.get(target, prop, receiver); 

      return function (...args: Parameters) {
        const newOptions = getComposedOptions(args[1]);
        const newArgs: MUIStyledParams = [...args];
        newArgs.splice(1, 1, newOptions);
        const styledResult = styled(...newArgs);

        return function (
          ...newestArgs: Parameters>
        ) {
          return styledResult(...newestArgs);
        };
      };
    }
    // 原始代码此处返回undefined，这会导致访问其他属性时失败
    return Reflect.get(target, prop, receiver); // 应该处理其他属性的访问
  },
});

export const styled = system.styled;

这段代码在开发环境中可以正常运行，但在生产环境中却抛出了一个TypeError：

Uncaught TypeError: 'get' on proxy: property 'styled' is a read-only and non-configurable data property on the proxy target but the proxy did not return its actual value (expected '(o,s={})=youjiankuohaophpcn{n6e

这个错误信息非常关键，它指出Proxy的get陷阱未能返回目标对象muiSystem上styled属性的“实际值”。这通常发生在以下情况：

1. styled属性是一个getter或方法，它依赖于特定的this上下文。
2. Reflect.get被错误地调用，导致styled函数内部的this绑定不正确。

在原始代码中，Reflect.get(target, prop, receiver)这一行是问题的核心。这里的receiver是Proxy实例本身。当Reflect.get尝试从target（即muiSystem）获取styled属性时，如果styled是一个需要特定this上下文（例如muiSystem本身）的getter或方法，而你传入了Proxy实例作为receiver，那么styled内部的逻辑可能会因为this上下文不匹配而失败。对于一些只读且不可配置的属性，JavaScript引擎会更严格地检查Proxy的get陷阱是否返回了与目标属性完全相同的值。如果Reflect.get由于receiver不正确而未能正确地“激活”或获取到styled的真实行为，就会触发此错误。

正确的Reflect.get用法

为了确保Reflect.get能够正确地获取到目标属性的值，尤其当该属性是getter或方法时，其receiver参数应该指向目标对象本身，或者一个能够正确模拟目标对象this上下文的对象。

正确的做法是将target（即muiSystem）作为Reflect.get的第三个参数：

Reflect.get(target, propertyKey, target)

这样可以保证当styled属性被访问时，如果它是一个需要this上下文的函数，其this将正确地绑定到muiSystem对象上，从而避免TypeError。

解决方案

基于上述分析，对Proxy的get陷阱进行修改，确保Reflect.get使用正确的receiver：

import * as muiSystem from '@mui/system';

type CreateMUIStyled = typeof muiSystem.styled;
type MUIStyledParams = Parameters;

const system = new Proxy(muiSystem, {
  get(target, prop, receiver) {
    if (prop === 'styled') {
      // 修正：将target作为Reflect.get的receiver参数
      const styled = Reflect.get(target, prop, target); 

      // 确保 styled 是一个函数，以防万一
      if (typeof styled !== 'function') {
        console.warn(`muiSystem.styled is not a function. Prop: ${String(prop)}`);
        return styled; // 返回原始值
      }

      return function (...args: Parameters) {
        // 假设 getComposedOptions 存在且逻辑正确
        const newOptions = getComposedOptions(args[1]);
        const newArgs: MUIStyledParams = [...args];
        newArgs.splice(1, 1, newOptions);
        const styledResult = styled(...newArgs);

        return function (
          ...newestArgs: Parameters>
        ) {
          return styledResult(...newestArgs);
        };
      };
    }
    // 对于其他属性，也应该使用Reflect.get并传递target作为receiver
    return Reflect.get(target, prop, target); 
  },
});

export const styled = system.styled;

// 假设 getComposedOptions 函数的定义
function getComposedOptions(options: any) {
  // 实现你的自定义逻辑
  return { ...options, someCustomProperty: true };
}

代码解释：

1. const styled = Reflect.get(target, prop, target);: 这是最关键的改动。我们将target（即muiSystem）作为Reflect.get的第三个参数传递。这确保了当muiSystem.styled被访问时，如果它是一个需要特定this上下文的方法或getter，this会被正确地绑定到muiSystem上。
2. 处理其他属性: 原始代码在if (prop === 'styled')之外返回undefined，这意味着任何其他对muiSystem属性的访问都将失败。正确的做法是也通过Reflect.get来获取它们，并同样传递target作为receiver，以保持一致性。

为什么开发环境和生产环境表现不同？

这种开发环境正常、生产环境报错的现象在前端开发中并不少见，通常有以下几个原因：

1. 构建工具优化: 生产构建通常会进行代码压缩、混淆、Tree Shaking等优化。这些优化可能会改变代码的执行上下文、变量作用域或函数绑定方式，从而暴露在开发环境中不明显的this绑定问题。例如，某些库在生产模式下可能会对内部方法进行更严格的this上下文检查。
2. JavaScript引擎模式: 生产环境可能运行在更严格的JavaScript引擎模式下（例如，更严格的ES模块解析），这会使得某些非标准或不规范的代码行为被识别为错误。
3. MUI库的内部实现: MUI或其他库可能在生产构建中对styled函数或其依赖项的实现方式有所不同，例如，它可能在生产模式下将其实现为更严格的getter或使用不同的模块导出机制，从而对this上下文的要求更严格。

总结与注意事项

• receiver参数的重要性: 在使用Proxy和Reflect.get时，务必理解receiver参数的含义。Proxy#get中的receiver是Proxy实例本身，而Reflect.get中的receiver是用于this绑定的上下文。
• 正确绑定this: 当通过Reflect.get从target对象获取属性时，如果该属性是一个方法或getter，为了确保其内部的this上下文正确，应将target本身作为Reflect.get的第三个receiver参数。
• 全面代理: 如果你打算代理一个对象的所有属性访问，确保Proxy#get陷阱能够处理所有属性的获取，而不仅仅是特定的属性。通常，这意味着在处理完特定逻辑后，使用Reflect.get(target, prop, target)作为默认的回退。
• 生产环境测试: 始终在生产环境中测试你的Proxy实现，因为开发环境和生产环境的行为可能存在细微差异，尤其是在涉及底层JavaScript机制（如Proxy和Reflect）时。
• 谨慎修改库函数: 代理或修改第三方库的内部函数需要非常小心，因为它可能依赖于特定的内部状态或this上下文。在进行此类操作时，深入理解库的内部工作原理至关重要。