计算属性名作为类静态成员时，初始化顺序问题源于模块加载与类定义执行时机错位；静态属性按声明顺序初始化，计算属性名表达式需在类体执行时立即求值，故不可依赖后声明的静态成员，应提前声明依赖项、用 static get 延迟求值或移至模块顶层定义。
计算属性名作为类静态流式成员时，初始化顺序问题本质是 JavaScript 模块加载与类定义执行时机的错位。关键在于：静态属性初始化发生在类体执行阶段，而计算属性名（[expr]）中的表达式会在该时刻立即求值——若表达式依赖尚未定义的静态成员，就会报 ReferenceError 或得到 undefined。
静态成员必须按声明顺序正向引用
JS 引擎从上到下解析类体，静态属性初始化严格遵循代码书写顺序。后面声明的静态值不能被前面的计算属性名表达式使用。
- ❌ 错误示例：
class Api {
static VERSION = 'v2';
// 报错：Cannot access 'VERSION' before initialization
static [`${Api.VERSION}/users`] = '/api/users';
}
- ✅ 正确做法：把依赖项提前，或改用函数延迟求值
用静态 getter 替代直接赋值
getter 在访问时才执行，天然规避初始化时序问题，适合需要组合其他静态值的场景。
- 将计算逻辑封装进
static get，调用时再拼接 - 保持命名一致性，例如用
ENDPOINTS对象统一管理
class Api {
static VERSION = 'v2';
static get ENDPOINTS() {
return {
USERS: `/api/${Api.VERSION}/users`,
POSTS: `/api/${Api.VERSION}/posts`
};
}
}
// 使用：Api.ENDPOINTS.USERS
模块级常量 + 类外定义静态映射
把易变的、需组合的配置提到类外部，利用模块顶层作用域的执行顺序可控性。
- 先定义基础常量（如
API_VERSION），再定义映射对象 - 类内直接引用该对象，不参与类体初始化竞争
const API_VERSION = 'v2';
const ENDPOINT_MAP = {
[`${API_VERSION}/users`]: '/api/users',
[`${API_VERSION}/posts`]: '/api/posts'
};
class Api {
static ENDPOINTS = ENDPOINT_MAP;
}
避免在类体内做跨静态成员的动态计算
类体不是运行时环境，而是定义上下文。任何需要“读取另一个 static 成员再加工”的逻辑，都不适合放在计算属性名中。
- 计算属性名只适合字面量或全局/模块级已存在、无依赖的表达式
- 例如：
static [Symbol.toStringTag] = 'Api'安全；static [this.NAME] = 1不合法（this在静态上下文中不可用） - 真有复杂逻辑，放到
static init()方法里手动触发
