unstable_after

unstable_after 允许你安排在响应（或预渲染）完成后执行的工作。这对于不应阻塞响应的任务和其他副作用（如日志记录和数据分析）非常有用。

它可以在服务器组件（包括 generateMetadata）、服务器操作、路由处理程序和中间件中使用。

该函数接受一个在响应（或预渲染）完成后执行的回调函数：

import { unstable_after as after } from 'next/server'
// 自定义日志函数
import { log } from '@/app/utils'
 
export default function Layout({ children }: { children: React.ReactNode }) {
  after(() => {
    // 在布局渲染完成并发送给用户后执行
    log()
  })
  return <>{children}</>
}

值得注意的是： unstable_after 不是动态 API，调用它不会导致路由变为动态。如果它在静态页面中使用，回调函数将在构建时或页面重新验证时执行。

参考

参数

• 一个在响应（或预渲染）完成后执行的回调函数。

无服务器函数持续时间

unstable_after 将按照平台的默认或配置的最大无服务器函数持续时间运行。如果你的平台支持，你可以使用maxDuration路由段配置来配置超时限制。

值得注意的是

• 即使响应未能成功完成，unstable_after 也会执行。包括抛出错误或调用 notFound 或 redirect 时。
• 你可以使用 React 的 cache 来对 unstable_after 内部调用的函数进行去重。
• 由于响应已经发送，无法在 unstable_after 内部设置 cookies。
• 动态 API 不能在 unstable_after 内部调用。应在 unstable_after 外部调用它们，并使用它们返回的对象。
• unstable_after 可以嵌套在其他 unstable_after 调用内部，例如，你可以创建包装 unstable_after 调用的实用函数来添加额外功能。

替代方案

unstable_after 的使用场景是在不阻塞主要响应的情况下处理次要任务。它类似于使用平台的 waitUntil() 或从 promise 中移除 await，但有以下区别：

• waitUntil()：接受一个 promise 并将任务排队在请求生命周期内执行，而 unstable_after 接受一个在响应完成后执行的回调函数。
• 移除 await：在响应期间开始执行，会消耗资源。在无服务器环境中也不可靠，因为函数在发送响应后立即停止计算，可能会中断任务。

我们推荐使用 unstable_after，因为它在设计时考虑了其他 Next.js API 和上下文。