我发现自己遇到了这样的情况，最终使用了IIFE

// using TypeScript

class SomeClass {
    constructor() {
        // do something here
    }

    doSomethingAsync(): SomeClass {
        (async () => await asyncTask())();
        return this;
    }
}

const someClass = new SomeClass().doSomethingAsync();

如果你有其他依赖于异步任务的任务，你可以在IIFE完成执行后运行它们。

最接近异步构造函数的方法是等待它完成执行，如果它还没有在它的所有方法中执行:

class SomeClass {
    constructor() {
        this.asyncConstructor = (async () => {
            // Perform asynchronous operations here
        })()
    }

    async someMethod() {
        await this.asyncConstructor
        // Perform normal logic here
    }
}

@slebetmen的公认答案很好地解释了为什么这行不通。除了答案中给出的两种模式之外，另一种选择是仅通过自定义异步getter访问您的异步属性。然后构造函数()可以触发属性的异步创建，但是getter在使用或返回属性之前检查属性是否可用。

当你想在启动后初始化一个全局对象，并且你想在一个模块中做这件事时，这种方法特别有用。而不是在index.js中初始化并将实例传递到需要它的地方，只需在需要全局对象的地方调用模块。

使用

const instance = new MyClass();
const prop = await instance.getMyProperty();

实现

class MyClass {
  constructor() {
    this.myProperty = null;
    this.myPropertyPromise = this.downloadAsyncStuff();
  }
  async downloadAsyncStuff() {
    // await yourAsyncCall();
    this.myProperty = 'async property'; // this would instead by your async call
    return this.myProperty;
  }
  getMyProperty() {
    if (this.myProperty) {
      return this.myProperty;
    } else {
      return this.myPropertyPromise;
    }
  }
}

我通常更喜欢返回一个新实例的静态异步方法，但这里有另一种方法。它更接近于字面上的等待构造函数。它与TypeScript一起工作。

class Foo {
  #promiseReady;

  constructor() {
    this.#promiseReady = this.#init();
  }

  async #init() {
    await someAsyncStuff();
    return this;

  }

  ready() {
    return this.promiseReady;
  }
}

let foo = await new Foo().ready();

如果可以避免扩展，则可以一起避免类，并使用函数组合作为构造函数。你可以使用作用域中的变量代替类成员:

async function buildA(...) {
  const data = await fetch(...);
  return {
    getData: function() {
      return data;
    }
  }
}

简单的使用它

const a = await buildA(...);

如果你使用typescript或flow，你甚至可以强制构造函数的接口

Interface A {
  getData: object;
}

async function buildA0(...): Promise<A> { ... }
async function buildA1(...): Promise<A> { ... }
...

这里有很多伟大的知识和一些超级()深思熟虑的回答。简而言之，下面概述的技术相当简单、非递归、异步兼容，并且遵循规则。更重要的是，我认为这里还没有正确地覆盖它-尽管如果错误请纠正我!

我们不调用方法，而是简单地将II(A)FE赋值给实例prop:

// it's async-lite!
class AsyncLiteComponent {
  constructor() {
    // our instance includes a 'ready' property: an IIAFE promise
    // that auto-runs our async needs and then resolves to the instance
    // ...
    // this is the primary difference to other answers, in that we defer
    // from a property, not a method, and the async functionality both
    // auto-runs and the promise/prop resolves to the instance
    this.ready = (async () => {
      // in this example we're auto-fetching something
      this.msg = await AsyncLiteComponent.msg;
      // we return our instance to allow nifty one-liners (see below)
      return this;
    })();
  }

  // we keep our async functionality in a static async getter
  // ... technically (with some minor tweaks), we could prefetch
  // or cache this response (but that isn't really our goal here)
  static get msg() {
    // yes I know - this example returns almost immediately (imagination people!)
    return fetch('data:,Hello%20World%21').then((e) => e.text());
  }
}

看起来很简单，怎么用呢?

// Ok, so you *could* instantiate it the normal, excessively boring way
const iwillnotwait = new AsyncLiteComponent();
// and defer your waiting for later
await iwillnotwait.ready
console.log(iwillnotwait.msg)

// OR OR OR you can get all async/awaity about it!
const onlywhenimready = await new AsyncLiteComponent().ready;
console.log(onlywhenimready.msg)

// ... if you're really antsy you could even "pre-wait" using the static method,
// but you'd probably want some caching / update logic in the class first
const prefetched = await AsyncLiteComponent.msg;

// ... and I haven't fully tested this but it should also be open for extension
class Extensior extends AsyncLiteComponent {
  constructor() {
    super();
    this.ready.then(() => console.log(this.msg))
  } 
}
const extendedwaittime = await new Extensior().ready;

在发帖之前，我在@slebetman的评论中对这种技术的可行性进行了简短的讨论。我并没有完全被这种直接的解雇所说服，所以我认为我应该进一步讨论/推翻它。请尽你最大的努力吧。