这个问题太戳中痛点了——隐式的顺序依赖真的很坑新人，注释要么被忽略，要么随着代码更新慢慢失效。我给你几个实用的思路，从简单到进阶，都能帮你摆脱对注释的依赖：

1. 封装成统一的初始化入口（最省心的方案） #

直接把两个函数的调用逻辑封装到一个对外暴露的初始化函数里，同时把loadPlugins和createStoreInstance设为模块私有（比如用JavaScript的#私有语法，或者闭包隐藏）。这样外部调用方根本没机会单独调用createStoreInstance，自然不会犯顺序错误。

示例代码：

// 模块内部私有函数，外部无法直接调用
async function #loadPlugins() {
  // 插件加载逻辑
  return loadedPlugins;
}

async function #createStoreInstance(plugins) {
  const initialState = {
    featureFlag: plugins["somePlugin"].isEnabled
  };
  return configureStore({ initialState });
}

// 对外唯一的初始化入口
export async function initializeApp() {
  const plugins = await #loadPlugins();
  return await #createStoreInstance(plugins);
}

这样新人拿到代码，只能看到initializeApp，调用它就自动完成了正确的流程，完全不用关心内部顺序。唯一的小缺点是，如果测试时需要单独模拟某一步，可能需要额外做些处理，但大部分应用初始化场景下，统一入口足够好用。

2. 显式传递依赖结果（最推荐的无隐式方案） #

把loadPlugins的返回值作为createStoreInstance的参数，彻底消除隐式的全局依赖。函数签名直接告诉调用者：“我需要插件数据才能运行”，新人一看就知道得先获取这个参数，而参数只能来自loadPlugins。

示例代码：

export async function loadPlugins() {
  // 加载插件，返回插件集合
  const plugins = { /* 插件数据 */ };
  return plugins;
}

export async function createStoreInstance(plugins) {
  // 这里可以加个类型检查，确保传入的是合法的插件数据
  if (!plugins || !plugins["somePlugin"]) {
    throw new Error('参数错误：请传入合法的插件集合');
  }
  const initialState = {
    featureFlag: plugins["somePlugin"].isEnabled
  };
  return configureStore({ initialState });
}

// 调用方式
const plugins = await loadPlugins();
const store = await createStoreInstance(plugins);

这个方案的优点太明显了：函数完全是“纯”的（不依赖外部隐式状态），依赖关系写在函数签名上，自文档化拉满，测试也方便——想测createStoreInstance直接传模拟的插件数据就行，不用真的执行loadPlugins。这是我最推荐的方案，从根源上解决了时间耦合的问题。

3. 增加依赖检查与明确错误提示（兼容现有代码的过渡方案） #

如果不想大改现有代码结构，可以加一个模块级别的标志位，在loadPlugins里标记完成状态，createStoreInstance开头先检查这个状态，不满足就抛出清晰的错误，而不是让它默默失败。

示例代码：

// 模块内部标志位，跟踪插件是否加载完成
let pluginsLoaded = false;

export async function loadPlugins() {
  // 插件加载逻辑
  pluginsLoaded = true;
}

export async function createStoreInstance() {
  if (!pluginsLoaded) {
    throw new Error('初始化错误：请先调用loadPlugins()完成插件加载');
  }
  const initialState = {
    featureFlag: await getPlugin("somePlugin").isEnabled
  };
  return configureStore({ initialState });
}

这个方案改动最小，而且错误信息非常明确，新人看到错误就知道该做什么。唯一的小问题是还是依赖了隐式的全局状态，但比只靠注释靠谱多了——至少失败时会给出明确的指引。

4. 用类/工厂函数封装初始化状态（适合复杂应用） #

如果你的应用初始化流程还有更多步骤，用类来封装整个初始化状态和流程会更清晰。把插件、store这些状态设为私有，对外只提供初始化方法和获取实例的方法，确保只有完成初始化后才能拿到可用的store。

示例代码：

class AppInitializer {
  #plugins = null;
  #store = null;

  async initialize() {
    // 先加载插件
    this.#plugins = await this.#loadPlugins();
    // 再创建store
    this.#store = await this.#createStoreInstance();
  }

  // 私有方法，外部无法调用
  async #loadPlugins() {
    // 插件加载逻辑
    return { /* 插件数据 */ };
  }

  async #createStoreInstance() {
    const initialState = {
      featureFlag: this.#plugins["somePlugin"].isEnabled
    };
    return configureStore({ initialState });
  }

  // 对外提供获取store的方法，先检查是否初始化完成
  getStore() {
    if (!this.#store) {
      throw new Error('请先调用initialize()完成应用初始化');
    }
    return this.#store;
  }
}

// 使用方式
const initializer = new AppInitializer();
await initializer.initialize();
const store = initializer.getStore();

这个方案把所有初始化逻辑都封装在类内部，状态被严格管控，外部调用方只能按照正确的顺序操作。如果未来还要加其他初始化步骤（比如初始化路由、配置），直接在initialize方法里加就行，扩展性很强。

如果让我选的话，显式传递依赖结果的方案是最优解——它完全消除了隐式状态，代码自己就能说明自己的依赖，测试和维护都更轻松。如果不想动太多现有代码，加检查和明确错误是性价比最高的过渡方案；统一入口适合简单的初始化流程；类封装则更适合有复杂初始化逻辑的大型应用。

内容来源于stack exchange