为何Google Closure Compiler不保留构造函数内复用的索引变量？

Great question—let’s break this down step by step, since Closure Compiler’s advanced optimizations can feel opaque at first.

1. Why Does This Happen? #

This behavior boils down to how Closure Compiler’s ADVANCED_OPTIMIZATIONS (the most aggressive mode, which you’re almost certainly using) analyzes variable scope and prioritizes performance vs. bundle size.

Here’s the breakdown:

• When your index variable (keyA) is defined inside a constructor, the compiler sees it as a local, scoped constant that’s only used within that narrow context. It assumes that inlining the full string literal (obj["some-very-long-key"]) is faster than resolving a variable lookup, so it replaces the variable reference with the literal directly.
• When you remove the constructor wrapper (e.g., move the variable to the global or outer function scope), the compiler’s scope analysis changes. It now considers that the variable might be reused elsewhere, or referenced outside the immediate code block. Inlining the literal would mean duplicating the long string every time it’s used, which actually increases bundle size—so it keeps the variable to avoid redundancy.

The compiler’s default priority here is runtime performance over bundle size, which is why it opts for inlining in the constructor case even if it bloats your code.

2. How to Keep Variables as Short Indexes (While Keeping Constructors) #

Since you prioritize smaller bundle size over the tiny performance hit of variable lookups, here are three reliable ways to force the compiler to retain short variable names for your long keys, without ditching your constructor structure:

Option 1: Use Class Static Constants (ES6+) #

Move your long keys to static class constants marked with @const. The compiler will recognize these as reusable, non-modifiable values and compress their names instead of inlining the full string:

/** @const */
class MyClass {
  static KEY_A = "some-very-long-key";
  static KEY_B = "another-extremely-long-key";

  constructor() {
    const obj = {};
    obj[MyClass.KEY_A] = "value1";
    obj[MyClass.KEY_B] = "value2";
  }
}

After compilation, MyClass.KEY_A will be compressed to something like a.a, making your index accesses far more compact.

Option 2: Add @nocollapse to Local Variables #

If you want to keep the variable inside the constructor, add the /** @nocollapse */ annotation to tell the compiler not to inline the literal. It will instead compress the variable name to a short identifier:

class MyClass {
  constructor() {
    /** @nocollapse */
    const KEY_A = "some-very-long-key";
    const obj = {};
    obj[KEY_A] = "value";
  }
}

This works because @nocollapse prevents the compiler from folding the variable reference into its literal value, forcing it to retain the variable (and compress its name).

Option 3: Use a Shared Constants Object #

Create a top-level constants object marked with @const, then reference its properties in your constructor. The compiler will compress both the object and property names:

/** @const */
const APP_KEYS = {
  USER_PROFILE: "user-profile-data-v2",
  SETTINGS_PREFERENCES: "app-settings-preferences-2024"
};

class MyClass {
  constructor() {
    const obj = {};
    obj[APP_KEYS.USER_PROFILE] = "data";
    obj[APP_KEYS.SETTINGS_PREFERENCES] = "preferences";
  }
}

This is especially useful if you reuse the same long keys across multiple classes or functions—you’ll get consistent, compact references everywhere.

As you noted, these approaches do introduce a tiny variable lookup overhead compared to inline literals, but the tradeoff for smaller bundle size is almost always worth it for projects with frequent long keys.

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