【免费下载链接】jetbrains-cc-guiJetbrains Claude Code and Codex GUI Plugin项目地址https://gitcode.com/gh_mirrors/id/jetbrains-cc-gui点击查看免费下载导读本篇文章聚焦仓库内 Vercel React Best Practices Agent Skill 中的一条服务端性能规则——Use after() for Non-Blocking Operations规则原文。该规则解决的是 Next.js 服务端代码中日志、埋点、审计等副作用任务阻塞 HTTP 响应的问题。读完本文你将掌握after()的正确用法、适用场景与边界并能在 Agent 驱动的代码生成与评审中准确识别并改写此类阻塞模式。规则定位一条关于“响应速度”的中等影响服务端规则在 .agents/skills/vercel-react-best-practices 这套由 Vercel 维护的性能优化规则集中server-after-nonblocking属于Server-Side Performance服务端性能类别。该类别在 8 大规则类别中优先级排名第 3整体影响级别为 HIGH参见 SKILL.md 中的优先级表与 _sections.md 对第 3 节的描述。规则自身的元数据frontmatter明确标注了它的定位titleUse after() for Non-Blocking OperationsimpactMEDIUM中等影响impactDescriptionfaster response times加快响应时间tagsserver, async, logging, analytics, side-effects含义很直接把日志、埋点、分析统计这类与用户请求结果无关的副作用任务从“响应前必须完成”的同步阻塞路径中移出从而让服务端更快地把响应返回给客户端。核心问题副作用任务为什么会在阻塞响应在典型的 Next.js Route Handler路由处理器或 Server Action 中开发者习惯按顺序写完整个业务流程例如“先改数据库再写日志最后返回响应”。从功能正确性看这没有问题但从性能看await logUserAction(...)这类日志/埋点调用会串行追加在数据库操作之后客户端必须等它完成才能收到响应。日志系统的一次网络请求、磁盘写入或第三方分析 API 调用都可能让本可以立刻返回的响应多等几十甚至几百毫秒。规则文件中给出了反面示例规则原文import { logUserAction } from /app/utils export async function POST(request: Request) { // Perform mutation await updateDatabase(request) // Logging blocks the response const userAgent request.headers.get(user-agent) || unknown await logUserAction({ userAgent }) return new Response(JSON.stringify({ status: success }), { status: 200, headers: { Content-Type: application/json } }) }这段代码的问题在于await logUserAction({ userAgent })在return之前执行客户端必须等日志写完才能拿到 200 响应。日志任务既不影响业务状态数据库已经更新成功也不影响返回给用户的数据却被放进了用户请求的关键路径critical path上。解决方案after()把副作用推迟到响应发送之后Next.js 提供了after()API从next/server导入。它的语义是将注册的回调任务调度到响应发送完成之后再执行因此日志、埋点等副作用不再阻塞响应。规则文件给出的正确示例规则原文import { after } from next/server import { headers, cookies } from next/headers import { logUserAction } from /app/utils export async function POST(request: Request) { // Perform mutation await updateDatabase(request) // Log after response is sent after(async () { const userAgent (await headers()).get(user-agent) || unknown const sessionCookie (await cookies()).get(session-id)?.value || anonymous logUserAction({ sessionCookie, userAgent }) }) return new Response(JSON.stringify({ status: success }), { status: 200, headers: { Content-Type: application/json } }) }对照反面示例可以提炼出该写法的几个关键点响应立即返回after()注册回调后函数立刻走到return响应随即发送给客户端日志任务在后台继续执行。在after()回调内重新读取请求上下文示例中没有沿用外层request.headers.get(user-agent)而是在回调内通过await headers()与await cookies()获取 user-agent 和 session-id。这正是 Next.js 异步请求 APINext.js 15 中headers/cookies变为异步、需要await的推荐用法也保证了回调在后台执行时仍然能拿到属于该请求的上下文数据。回调允许继续异步工作after(async () {...})支持异步回调回调内的await不会影响已发出的响应。规则文件用一句话总结了效果响应立即发送而日志在后台完成The response is sent immediately while logging happens in the background。常见使用场景规则文件列出了after()最典型的五类用途规则原文场景说明Analytics tracking埋点上报、访问统计、行为分析与用户响应结果无关Audit logging审计日志、操作留痕需要记录但无需等待完成Sending notifications邮件、Webhook、推送通知等外部通知发送Cache invalidation缓存失效、缓存重建等异步维护任务Cleanup tasks临时文件清理、资源释放等收尾工作这些任务的共同特征是执行失败不影响已完成的业务操作也不影响已返回的响应内容。它们天然适合放到响应之后执行从而把响应耗时压到最短。重要的行为特性与适用边界规则文件明确强调了两条关键行为规则原文after()即使响应失败或发生重定向也仍会执行。这意味着不能把after()当作“响应成功后的钩子”来用——如果业务逻辑要求“只有操作成功才记录/通知”必须在调用after()之前自行判断并决定是否注册回调而不是依赖响应状态。after()在 Server Actions、Route Handlers 和 Server Components 中均可用。三处使用场景覆盖了 Next.js App Router 服务端代码的主要入口。从使用边界看也应当注意after()适合的是“可丢弃、可延迟”的副作用任务如果某次调用是业务主流程的一部分例如用户必须等待其结果才能继续仍然应该放在响应前await。规则文件在反面示例中保留await updateDatabase(request)这一主流程调用也印证了这一点——不是所有 await 都要消除而是要把非关键副作用移出关键路径。与相邻规则协同从“非阻塞”到“并行”的服务端性能体系server-after-nonblocking并非孤立规则它和同仓库规则集中的若干相邻规则共同构成了服务端性能优化组合拳async-api-routes.md针对 API 路由中独立的异步操作主张“先发起 Promise、后 await”例如先启动auth()与fetchConfig()再统一Promise.all收敛。它与after()的差异在于前者处理的是响应前必要的并行化后者处理的是响应后无关任务的推迟。server-parallel-fetching.md针对 React Server Components 树内串行执行导致的瀑布流主张通过组件组合composition让多个 fetch 同时进行同样服务于减少服务端等待的目标。bundle-defer-third-party.md把“分析/日志类第三方库不阻塞主路径”的思路延伸到客户端——用next/dynamicssr: false把 Analytics 组件推迟到水合之后再加载。它与after()一前一后分别处理客户端加载期和服务端响应期的非关键路径优化。从规则命名与分类上看server-after-nonblocking.md 与 server-auth-actions.md、server-cache-lru.md 等同属server-前缀类别参见 README.md 对server-前缀的说明都聚焦“服务端渲染与数据获取的性能”。在 Agent/LLM 场景中的价值如何被自动应用该规则文件并非普通的性能博客而是以“可供 Agent 与 LLM 直接消费”的形式设计的。从 README.md 与 SKILL.md 可以看出这套规则库的结构约定是每个规则文件一个area-description.md文件名前缀决定所属类别server-对应第 3 节 Server-Side Performance文件统一包含 frontmattertitle / impact / impactDescription / tags与固定的“错误示例 → 正确示例 → 补充说明 → 参考链接”四段式结构参见 _template.md元数据中的 impact 级别CRITICAL / HIGH / MEDIUM 等见 README.md用于引导自动重构与代码生成的优先级排序。在本仓库中这套规则存放于 .agents/skills/vercel-react-best-practices 目录是随项目分发的 Agent Skill 资产。当 Agent 被用于编写、评审或重构 React/Next.js 代码时可以依据本规则自动识别“响应前await日志/埋点”的反模式并改写为after()形式同时对 impact 为 MEDIUM、效果为“加快响应时间”的改动给出明确的价值说明。这正是 SKILL.md 中列出的典型触发时机——数据获取、代码评审、性能重构。小结把“非关键任务”从响应关键路径上移走server-after-nonblocking规则的核心方法论可以概括为一句话在服务端代码中凡是与用户响应结果无关的副作用任务都应该用after()调度到响应发送之后执行而不是在响应前await它们。配合异步请求 APIheaders()/cookies()在回调内安全读取请求上下文即可在保持日志、埋点、通知、缓存失效、清理等任务完整性的前提下把响应耗时压缩到业务主流程所需的最小值。对于 JetBrains Claude Code 插件内置的这套 Agent Skill 而言它既是一份可直接检索的规则文档也是 Agent 自动重构服务端代码时的行为基准。赞分享【免费下载链接】jetbrains-cc-guiJetbrains Claude Code and Codex GUI Plugin项目地址https://gitcode.com/gh_mirrors/id/jetbrains-cc-gui点击查看免费下载相关推荐Papermark 中的 Next.js after() 非阻塞操作实践用 after()/waitUntil 提升响应速度Papermark 中的 Next.js after 非阻塞操作实践用 after /waitUntil 提升响应速度 导读 after 是 Next.js后端前端企业应用LibreHardwareMonitor硬件监控与远程监控教程LibreHardwareMonitor硬件监控与远程监控教程 LibreHardwareMonitor 是一款开源免费的 硬件监控 软件MPL 2.0 协指标监控OpenMetadata 前端工程实践用 Next.js after() 调度非阻塞操作让日志与分析不再拖慢接口响应OpenMetadata 前端工程实践用 Next.js after 调度非阻塞操作让日志与分析不再拖慢接口响应 在 OpenMetadata 仓库的 sk数据目录数据血缘数据治理后端MCP 服务上一篇lxmusic-source-all洛雪音源完整合集22 个现成脚本导入即用下一篇XUnity Auto TranslatorUnity游戏自动翻译插件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考