计算属性名作为类静态成员时，初始化顺序问题本质是字段按声明顺序逐行执行、实时求值，而计算属性名中的引用若依赖尚未初始化的同级或后续静态成员会报错；应优先使用 static block 明确控制顺序，或提前在外部计算键名。
计算属性名作为类静态成员时，初始化顺序问题本质是 JavaScript 类字段的执行时机与表达式求值顺序之间的冲突。关键在于：静态字段按声明顺序从上到下初始化，而计算属性名（[] 包裹的表达式）会在字段初始化阶段**实时求值**——此时其他静态成员可能尚未定义。
静态字段中计算属性名依赖未初始化的静态成员
常见错误写法：
class Example {
static prefix = 'user';
static key = 'id';
// ❌ 报错：Cannot access 'prefix' before initialization
static [`${Example.prefix}_${Example.key}`] = 'default-value';
}
原因：计算属性名中的 Example.prefix 在 static prefix 初始化完成前就被访问了。虽然 prefix 声明在前，但计算属性名属于“初始化表达式”，其求值发生在该字段自身初始化时刻，而此时 Example 构造函数尚未完全建立，静态上下文不可靠。
- 静态字段初始化不是“先全部声明、再统一赋值”，而是逐行执行、立即求值
- 计算属性名里的引用必须指向已初始化完成的值（如全局变量、字面量、或已执行完的顶层 const）
- 不能安全依赖同一 class 内、声明位置在其之后（或同级但未执行完）的静态字段
用静态初始化块（static block）明确控制顺序
ES2022 引入的 static block 是最清晰、最可靠的解法。它在类定义时同步执行，且可安全访问已声明的静态成员：
class Example {
static prefix = 'user';
static key = 'id';
// ✅ 延迟到 static block 中定义计算出的键名属性
static computedKeyProp;
static {
const fullKey = `${this.prefix}_${this.key}`;
this[fullKey] = 'default-value';
this.computedKeyProp = fullKey;
}
}
优势：
- 块内
this指向类本身，可安全读写已声明的静态字段 - 执行时机确定：在类定义末尾、实例化之前，且早于任何实例方法调用
- 逻辑集中，意图明确，避免字段声明区混入副作用
退而求其次：用顶层常量或 IIFE 隔离依赖
若需兼容不支持 static block 的环境（如旧版 Node.js 或某些打包配置），可将计算逻辑移出类体：
// ✅ 提前计算，不依赖类内部初始化顺序
const STATIC_KEY = `${'user'}_${'id'}`;
class Example {
static prefix = 'user';
static key = 'id';
static [STATIC_KEY] = 'default-value';
}
或用立即执行函数确保求值时机可控：
class Example {
static prefix = 'user';
static key = 'id';
// ✅ IIFE 确保在字段声明后、类定义完成前求值
static [(() => `${Example.prefix}_${Example.key}`)()] = 'default-value';
}
注意：IIFE 方案虽可行，但可读性较差，且仍隐含对 Example 构造函数可用性的假设，不如 static block 稳健。
避免在静态字段中直接使用 this 或类名引用
以下写法看似合理，实则危险：
class Example {
static version = 1;
// ❌ 危险：this 在字段初始化时不一定指向 Example（尤其在继承或装饰器场景）
static [this.version + '_config'] = {};
}
根本原则：静态字段初始化阶段，this 不可靠；类名（如 Example.version）仅在该字段声明位置之后的字段中才可用——但无法保证其已初始化。唯一安全的是外部作用域中已求值完成的值。
- 优先用
static block替代复杂字段初始化逻辑 - 字段声明区只放字面量、纯函数调用（无副作用）、或明确已初始化的外部常量
- 对动态键名有强需求时，考虑是否真需挂载为静态属性，还是改用静态 getter 或工具方法返回
