发布于 由admin

JS `AsyncContext` (提案) `Context Propagation` 在 `Promise Chains` 中的行为

咳咳，大家好！ 今天咱们聊聊 JavaScript 里一个挺有意思，但又有点绕的概念：AsyncContext (提案) 和 Context Propagation 在 Promise Chains 里的表现。 准备好，系好安全带，咱们要开始一场“异步上下文穿越之旅”了！

啥是 AsyncContext？ 别慌，先喝口水

首先，得明白 AsyncContext 是个啥玩意儿。 简单来说，它就像一个“异步小书包”，可以让你在异步操作之间传递一些数据。 想象一下，你写了一个复杂的异步程序，里面涉及各种 setTimeout、Promise、async/await。 在这些异步操作中，你可能需要共享一些信息，比如用户 ID、请求 ID、或者一些配置信息。

以前，你可能得靠全局变量，或者一层层地把这些信息作为参数传递下去。 这样代码写起来不仅丑陋，而且容易出错，维护起来更是噩梦。 AsyncContext 就是为了解决这个问题而生的。

Context Propagation： 让书包跟着 Promise 跑

Context Propagation 顾名思义，就是让这个“异步小书包”能够自动地在异步操作之间传递。 这意味着，当你在一个 AsyncContext 里启动一个 Promise 链时，这个 Promise 链里的所有 then、catch、finally 都能访问到这个 AsyncContext 里的数据。

来，看个例子，别光说不练

咱们先来个简单的例子，看看 AsyncContext 怎么用：

// 假设我们有一个 AsyncContext 的实现 (现在还是提案阶段，所以需要 polyfill 或者实验性环境)
import { AsyncLocalStorage } from 'async_hooks';

const asyncLocalStorage = new AsyncLocalStorage();

// 启动一个 AsyncContext
asyncLocalStorage.run({ userId: '123', requestId: '456' }, () => {
  // 在这个回调函数里，我们可以访问到 userId 和 requestId
  console.log('Initial Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }

  // 创建一个 Promise
  Promise.resolve()
    .then(() => {
      // 在 Promise 的 then 回调里，也能访问到 userId 和 requestId
      console.log('Promise then Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
      return 'Hello';
    })
    .then(result => {
      console.log('Promise then Context (after resolve):', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
      console.log('Result from previous then:', result);
    })
    .catch(err => {
      // 如果 Promise 链里有错误，catch 回调也能访问到 userId 和 requestId
      console.error('Promise catch Context:', asyncLocalStorage.getStore());
      console.error('Error:', err);
    })
    .finally(() => {
      // 无论 Promise 链成功还是失败，finally 回调都能访问到 userId 和 requestId
      console.log('Promise finally Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
    });

  console.log('After Promise Creation:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
});

console.log('Outside AsyncContext:', asyncLocalStorage.getStore()); // 输出: undefined (或者 null，取决于实现)

在这个例子里，我们用 asyncLocalStorage.run 启动了一个 AsyncContext，并且设置了 userId 和 requestId。 然后，我们创建了一个 Promise 链。 你可以看到，在 Promise 链的各个回调函数里，我们都能通过 asyncLocalStorage.getStore() 访问到 userId 和 requestId。

Promise 链的“上下文传递”机制

AsyncContext 和 Promise 链的结合，关键在于 Context Propagation。 它确保了当 Promise 链中的一个回调函数被执行时，它的 AsyncContext 和创建这个 Promise 时的 AsyncContext 是一样的。

深入虎穴： 复杂一点的 Promise 链

咱们再来个复杂一点的例子，看看 AsyncContext 在更复杂的 Promise 链里怎么表现：

import { AsyncLocalStorage } from 'async_hooks';

const asyncLocalStorage = new AsyncLocalStorage();

asyncLocalStorage.run({ userId: '123', requestId: '456' }, async () => {
  console.log('Initial Context:', asyncLocalStorage.getStore());

  const nestedPromise = () => {
    return Promise.resolve()
      .then(() => {
        console.log('Nested Promise then Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
        return new Promise(resolve => {
          setTimeout(() => {
            console.log('Nested Promise setTimeout Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
            resolve('Nested Timeout Resolved');
          }, 50);
        });
      });
  };

  const mainPromise = Promise.resolve()
    .then(() => {
      console.log('Main Promise then Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
      return nestedPromise();
    })
    .then(result => {
      console.log('Main Promise then (after nested) Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
      console.log('Result from nested promise:', result);
      return 'Main Resolved';
    })
    .then(finalResult => {
      console.log('Main Promise then (final) Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
      console.log('Final Result:', finalResult);
    });

  await mainPromise; // 等待 mainPromise 完成

  console.log('After Main Promise Completion:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
});

console.log('Outside AsyncContext:', asyncLocalStorage.getStore());

这个例子里，我们定义了一个 nestedPromise 函数，它返回一个 Promise。 在 nestedPromise 里，我们又用 setTimeout 创建了一个新的 Promise。 可以看到，即使在 setTimeout 的回调函数里，我们仍然可以访问到最初的 AsyncContext。

Async/Await 的“上下文传递”

async/await 本质上是 Promise 的语法糖，所以 AsyncContext 也能很好地支持 async/await。

import { AsyncLocalStorage } from 'async_hooks';

const asyncLocalStorage = new AsyncLocalStorage();

asyncLocalStorage.run({ userId: '123', requestId: '456' }, async () => {
  console.log('Initial Context:', asyncLocalStorage.getStore());

  async function fetchData() {
    console.log('fetchData Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
    await new Promise(resolve => setTimeout(resolve, 50));
    console.log('fetchData Context (after await):', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
    return 'Data from server';
  }

  async function processData(data) {
    console.log('processData Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
    return `Processed: ${data}`;
  }

  try {
    const data = await fetchData();
    console.log('After fetchData:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
    const processedData = await processData(data);
    console.log('After processData:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
    console.log('Processed Data:', processedData);
  } catch (error) {
    console.error('Error Context:', asyncLocalStorage.getStore());
    console.error('Error:', error);
  }

  console.log('After Try/Catch:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456' }
});

console.log('Outside AsyncContext:', asyncLocalStorage.getStore());

在这个例子里，我们定义了两个 async 函数：fetchData 和 processData。 可以看到，即使在 async 函数里，我们也能访问到最初的 AsyncContext。 await 关键字会暂停函数的执行，直到 Promise resolve，但 AsyncContext 会一直保持不变。

错误处理与 Context Propagation

当 Promise 链中发生错误时，AsyncContext 仍然会被正确地传递到 catch 回调函数中。 这样，你就可以在 catch 回调函数里访问到导致错误的上下文信息，方便你进行调试和错误处理。

import { AsyncLocalStorage } from 'async_hooks';

const asyncLocalStorage = new AsyncLocalStorage();

asyncLocalStorage.run({ userId: '123', requestId: '456', attempt: 1 }, async () => {
  console.log('Initial Context:', asyncLocalStorage.getStore());

  try {
    const result = await Promise.reject(new Error('Something went wrong'));
    console.log('Result:', result); // 不会执行到这里
  } catch (error) {
    console.error('Catch Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456', attempt: 1 }
    console.error('Error:', error);

    // 重试逻辑 (改变 context)
    if (asyncLocalStorage.getStore().attempt < 3) {
      const currentContext = asyncLocalStorage.getStore();
      asyncLocalStorage.run({...currentContext, attempt: currentContext.attempt + 1}, async () => {
        console.log('Retry Context:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456', attempt: 2 }
        try {
           //这里可以模拟一个成功的promise
           const result = await Promise.resolve("Retry Success!");
           console.log("Retry Result", result);
        } catch(retryError){
          console.error("Retry Failed Context", asyncLocalStorage.getStore());
          console.error("Retry Error", retryError);
        }
      });
    }
  }

  console.log('After Try/Catch:', asyncLocalStorage.getStore()); // 输出: { userId: '123', requestId: '456', attempt: 1 } (注意: context 在 try/catch 之后恢复到初始状态,除非你在catch中显式修改了)
});

console.log('Outside AsyncContext:', asyncLocalStorage.getStore());

这个例子展示了如何在 catch 回调函数里访问到 AsyncContext，并且根据上下文信息进行重试。 关键点在于，即使在错误发生时，AsyncContext 仍然会被正确地传递下去。 如果在 catch 块中启动了新的 AsyncContext (如重试的例子)，那么新的 AsyncContext 只会在重试的范围内生效。

AsyncContext 的一些注意事项

  • 不要滥用： AsyncContext 并不是万能的。 过度使用 AsyncContext 可能会导致代码难以理解和维护。 只在真正需要共享异步上下文信息时才使用它。
  • 小心内存泄漏： 如果你在 AsyncContext 里存储了大量的数据，或者长时间不释放 AsyncContext，可能会导致内存泄漏。 要及时清理不再需要的 AsyncContext。
  • 线程安全： AsyncContext 通常不是线程安全的。 如果你在多线程环境中使用 AsyncContext，需要进行适当的同步。 (在 Node.js 的单线程环境下，这通常不是问题，但在 Worker Threads 中需要注意)
  • 性能影响： AsyncContext 会带来一定的性能开销。 在性能敏感的场景中，需要仔细评估 AsyncContext 的性能影响。

AsyncContext 的替代方案

虽然 AsyncContext 很有用，但它并不是唯一的解决方案。 在某些情况下，你可以使用其他技术来达到类似的效果：

技术 优点 缺点 适用场景
全局变量 简单易用 容易出错，难以维护，线程不安全 简单的、非并发的、不需要隔离的场景
函数参数传递 清晰明确 代码冗长，修改麻烦 参数数量较少，调用链不深的场景
Context 对象 (手动传递) 灵活可控 需要手动传递，容易出错 需要细粒度控制上下文传递的场景
AsyncContext 自动传递，避免手动传递的麻烦 学习成本较高，性能有一定影响，可能存在内存泄漏的风险 需要在多个异步操作之间共享上下文信息的复杂场景，例如请求追踪、用户身份验证等
Zones (Angular) 类似于 AsyncContext，提供异步上下文管理 主要用于 Angular 框架，通用性较差 Angular 应用中需要异步上下文管理的场景

总结

AsyncContext 是一个强大的工具，可以帮助你更好地管理异步操作之间的上下文信息。 它通过 Context Propagation 机制，确保了 Promise 链中的各个回调函数都能访问到正确的上下文。 但是，AsyncContext 并不是万能的，你需要根据实际情况选择合适的解决方案。

记住，代码的目的是为了解决问题，而不是为了炫技。 只有当你真正理解了 AsyncContext 的原理和适用场景，才能把它用好。

好了，今天的“异步上下文穿越之旅”就到这里。 希望大家有所收获！ 下次再见！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注