JavaScript Proxy的[[GetPrototypeOf]]为何是不变量？数组转对象的更佳方案？

Great question! Let's break down your two questions one by one, with practical solutions to boot.

Why does the [[GetPrototypeOf]] invariant exist? #

This invariant is all about preserving predictability and consistency in JavaScript's prototype system. Here's the core reasoning:

• Transparency is key: Proxies are designed to be as "transparent" as possible—code interacting with a proxy should behave almost identically to code interacting with the target object. If you could override the prototype of a proxy to mismatch its target, you'd break this transparency.
• Avoiding broken assumptions: Lots of JavaScript code relies on prototype checks. For example:
  • If your target is an array but the proxy returns Object.prototype as its prototype, Array.isArray(proxy) would return false even though the underlying data is an array.
  • instanceof checks would also lie—proxy instanceof Array would fail, confusing developers and breaking logic tied to type checks.
• Minimizing surprise: Developers expect a proxy to inherit the target's identity. Changing the prototype would create counterintuitive behavior that's hard to debug.

In short, this invariant ensures proxies don't sabotage the fundamental rules of JavaScript's prototype chain.

A more规范的数组转对象 implementation? #

Your current Proxy approach works, but we can refine it to be more elegant. We also have a simpler, non-Proxy alternative that avoids prototype-related headaches entirely.

Option 1: Optimized Proxy Approach (Reusable Handler) #

Instead of creating a new handler for every row, we can reuse a single shared handler and store the row data in a private field. We'll also fix the console.log issue by adding traps for property enumeration:

'use strict';
class Inflator {
  #values; // Private field to hold the row array securely

  constructor(fields, values) {
    this.#values = values;
    return new Proxy(fields, Inflator.sharedHandler);
  }

  // Shared handler reused across all instances
  static sharedHandler = {
    get(target, prop, receiver) {
      const fieldMeta = target[prop];
      // Map property to row index if metadata exists
      if (fieldMeta?.index !== undefined) {
        return receiver.#values[fieldMeta.index];
      }
      // Fallback to default behavior for other properties
      return Reflect.get(target, prop, receiver);
    },
    set(target, prop, value, receiver) {
      const fieldMeta = target[prop];
      if (fieldMeta?.index !== undefined) {
        receiver.#values[fieldMeta.index] = value;
        return true;
      }
      return Reflect.set(target, prop, value, receiver);
    },
    // Make properties visible in console.log and loops
    ownKeys(target) {
      return Object.keys(target);
    },
    // Ensure property descriptors are correctly reported
    getOwnPropertyDescriptor(target, prop) {
      const fieldMeta = target[prop];
      if (fieldMeta) {
        return {
          enumerable: true,
          configurable: true,
          get: () => this.get(target, prop),
          set: (val) => this.set(target, prop, val)
        };
      }
      return Reflect.getOwnPropertyDescriptor(target, prop);
    }
  };
}

// Usage remains identical
const rawData = {
  fields: {
    col1: {index: 0},
    col2: {index: 1},
    col3: {index: 2},
  },
  rows: [
    ['r1c1', 'r1c2', 'r1c3'],
    ['r2c1', 'r2c2', 'r2c3'],
  ],
};

const data = rawData.rows.map(row => new Inflator(rawData.fields, row));

console.log(data[0]); // Now shows col1/col2/col3 directly!
console.assert(data[0].col1 === 'r1c1');
console.assert(data[1].col3 === 'r2c3');

This version:

• Cuts down on memory usage by reusing one handler
• Fixes the console.log and Object.assign quirks
• Uses private fields to keep row data safe from external tampering

Option 2: Object.defineProperty (No Proxy Needed) #

If your field mapping is static (won't change after initialization), creating a plain object with getters/setters is simpler and avoids Proxy prototype limitations entirely:

'use strict';
function inflateRow(fields, row) {
  const inflated = {};
  for (const [prop, { index }] of Object.entries(fields)) {
    Object.defineProperty(inflated, prop, {
      get() {
        return row[index];
      },
      set(value) {
        row[index] = value;
      },
      enumerable: true, // Ensure properties show up in loops/console
      configurable: true
    });
  }
  return inflated;
}

// Usage
const rawData = {
  fields: {
    col1: {index: 0},
    col2: {index: 1},
    col3: {index: 2},
  },
  rows: [
    ['r1c1', 'r1c2', 'r1c3'],
    ['r2c1', 'r2c2', 'r2c3'],
  ],
};

const data = rawData.rows.map(row => inflateRow(rawData.fields, row));

console.log(data[0]); // Shows { col1: 'r1c1', col2: 'r1c2', col3: 'r1c3' } directly
console.assert(data[0].col1 === 'r1c1');
console.assert(data[1].col3 === 'r2c3');

This approach:

• Produces a standard Object instance with the correct prototype
• Requires no workarounds for console.log or enumeration
• May perform better than Proxy (no trap invocation overhead)
• Is more straightforward for static mappings

Which to Choose? #

• Use the Proxy approach if you need dynamic field mappings, or want to leverage other Proxy traps (like intercepting delete or in checks).
• Use the Object.defineProperty approach if your field mapping is fixed, and you want simplicity and better performance.

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