Next.js on KnightLi的博客

World Monitor 本地运行教程：自建全球新闻和态势监控看板

Mon, 22 Jun 2026 08:05:45 +0800

koala73/worldmonitor 是一个实时全球情报看板，用来聚合新闻、地缘事件、基础设施状态和不同主题频道。它更像一个信息态势页面，适合拿来做自建新闻监控入口。

项目地址：

https://github.com/koala73/worldmonitor

官网：

https://worldmonitor.app

本地启动

README 的快速开始命令：

git clone https://github.com/koala73/worldmonitor.git
cd worldmonitor
npm install
npm run dev

启动后先看默认页面是否正常，再考虑部署。

不同频道怎么跑

项目内置了多个频道开发命令：

npm run dev:tech       # tech.worldmonitor.app
npm run dev:finance    # finance.worldmonitor.app
npm run dev:commodity  # commodity.worldmonitor.app
npm run dev:happy      # happy.worldmonitor.app
npm run dev:energy     # energy.worldmonitor.app

如果你只关心技术新闻，可以先跑 dev:tech；如果关心金融或大宗商品，就分别试 dev:finance 和 dev:commodity。

构建和检查

提交或部署前建议跑：

1
2

npm run typecheck
npm run build:full

这两个命令能先发现 TypeScript 类型问题和生产构建问题。

适合怎么用

World Monitor 适合这些用途：

自己搭一个实时新闻入口。
给团队做技术、能源、金融、商品主题看板。
观察多源新闻流，而不是只依赖单个平台推荐。
二次开发成内部情报 dashboard。

部署建议

README 提到可以看 self-hosting guide，部署方式包括 Vercel、Docker 和静态部署。建议先本地跑通，再部署到 Vercel 或自己的服务器。

使用时要注意：新闻聚合看板只能帮助你更快看到信号，不代表所有信息都已经核实。对金融、地缘、安全类内容，最好点进原始来源交叉验证。

Vercel AI SDK 是什么？TypeScript 开发者构建 AI 应用的统一工具包

Sun, 17 May 2026 23:07:38 +0800

vercel/ai 是 Vercel 维护的开源 AI SDK。

它的定位很明确：给 TypeScript 开发者提供一套统一工具，用来构建 AI 应用和 AI Agent。它来自 Next.js 背后的团队，但并不只服务于 Next.js，也支持 React、Svelte、Vue、Angular 等 UI 框架，以及 Node.js 等运行时。

项目地址：https://github.com/vercel/ai

如果你正在做聊天应用、AI 写作工具、RAG 应用、带工具调用的 Agent、流式输出界面，或者想把多个模型供应商接到同一个应用里，Vercel AI SDK 是一个值得关注的基础库。

它解决的核心问题

现在做 AI 应用，最大麻烦之一不是“能不能调模型”，而是不同模型供应商的接口、流式输出、工具调用、错误处理和前端状态管理都不一样。

例如：

OpenAI 有自己的 SDK 和响应格式。
Anthropic 有自己的消息结构。
Google、xAI、Mistral、DeepSeek、Groq 等也各有差异。
流式输出需要处理 chunk。
工具调用需要处理模型发起的结构化请求。
前端聊天 UI 还要管理消息、加载状态、取消、重试和错误展示。

如果每个供应商都手写一套适配层，项目会很快变复杂。

Vercel AI SDK 的思路是把这些差异收敛到统一 API 后面。开发者用一套接口写应用，再通过 Provider 接入不同模型。

统一 Provider 架构

Vercel AI SDK 的一个核心特点，是 provider-agnostic，也就是不绑定单一模型厂商。

它可以通过统一 API 访问 OpenAI、Anthropic、Google 等模型提供方。项目 README 还提到，默认情况下 AI SDK 会使用 Vercel AI Gateway，让开发者更容易访问多个主流 provider。

这对工程项目很实用。

因为很多 AI 产品最终都不会只依赖一个模型：

有的任务适合强推理模型。
有的任务适合便宜快速模型。
有的任务需要多模态。
有的任务需要长上下文。
有的任务需要本地或私有部署模型。

统一 Provider 架构让应用更容易做模型切换、灰度测试、成本控制和备选方案。

流式输出是前端体验的关键

AI 应用和传统 API 最大的体验差异之一，是响应可能很长。

如果用户每次都要等完整回答返回，聊天工具、写作工具和代码助手会显得很慢。流式输出可以让文本逐步显示，用户更早看到结果。

Vercel AI SDK 对流式生成做了比较完整的封装。开发者不需要从零处理底层事件流，而是可以使用 SDK 提供的生成和流式接口，把模型输出接到前端 UI。

这对 Next.js / React 应用尤其方便。

一个 AI 聊天界面看起来简单，但实际要处理：

消息列表。
用户输入。
服务器请求。
流式 token 展示。
加载状态。
错误状态。
中止生成。
重新生成。

这些都是 AI SDK 试图帮开发者减少重复劳动的地方。

工具调用和 Agent 场景

随着 AI 应用从“聊天”走向“做事”，工具调用变得越来越重要。

模型不只是输出自然语言，还可能需要调用外部函数：

查数据库。
搜索文档。
调用业务 API。
读取订单状态。
生成图表。
创建日历事件。
修改项目文件。

Vercel AI SDK 支持工具调用相关能力，让开发者可以定义工具、参数和执行逻辑，再让模型在合适时机请求调用。

这也是它从“聊天 UI SDK”扩展到“AI 应用和 Agent 工具包”的关键。

不过，工具调用不是加上去就万事大吉。真实项目还要考虑：

参数校验。
权限边界。
工具调用日志。
幂等性。
超时和重试。
人工确认。
敏感操作限制。

AI SDK 可以帮助处理接口和流程，但安全边界仍然需要开发者自己设计。

UI 集成能力

Vercel AI SDK 对前端框架比较友好。

它不仅提供核心生成 API，也围绕聊天、补全、消息状态和流式 UI 做了封装。对于使用 Next.js 和 React 的团队来说，这能减少很多样板代码。

但它并不只适合 Vercel 部署。

如果你的项目本身是 TypeScript 技术栈，或者后端运行在 Node.js 环境，AI SDK 仍然可以作为模型调用和流式处理层来使用。是否部署在 Vercel，取决于你的应用架构、团队习惯和基础设施选择。

Skill for Coding Agents

vercel/ai README 里还有一个有趣的建议：如果你使用 Claude Code、Cursor 等 coding agent，可以把 AI SDK skill 加到仓库里。

示例命令是：

`1`	`npx skills add vercel/ai`

这说明 Vercel 已经意识到，AI SDK 的用户不只是人类开发者，也包括 coding agent。

当 agent 修改使用 AI SDK 的项目时，如果仓库里有专门的 skill，它可以更好地理解 SDK 约定、常见 API、项目结构和最佳实践，减少乱写代码的概率。

这个方向很值得注意。

未来开源项目可能不只提供 README 和 docs，还会提供给 AI coding agent 使用的结构化技能说明。对复杂 SDK 来说，这会变成新的开发者体验入口。

适合哪些项目

Vercel AI SDK 适合这几类场景：

基于 Next.js / React 的 AI 聊天应用。
需要流式输出的写作、问答、客服和代码助手。
需要接入多个模型 provider 的 AI 产品。
想快速构建 RAG 或文档问答原型的团队。
需要工具调用、函数调用或轻量 Agent 能力的应用。
已经使用 TypeScript / Node.js 技术栈的团队。

它尤其适合前端和全栈开发者。因为很多 AI 应用的难点不只是模型调用，而是如何把模型输出变成稳定、流畅、可交互的产品体验。

不适合什么场景

如果你的项目主要是 Python 后端、深度学习训练、模型微调或底层推理服务，Vercel AI SDK 可能不是核心工具。

它更偏应用层，而不是模型训练框架。

如果你需要的是：

自己训练模型。
管理 GPU 推理集群。
做底层 batch inference。
深度控制 tokenizer、KV cache、量化和推理引擎。

那更应该看 PyTorch、vLLM、SGLang、TensorRT-LLM、llama.cpp 或云厂商推理服务。

Vercel AI SDK 更像“把模型能力接进产品”的应用开发层。

使用时要注意什么

第一，不要把统一 API 理解成完全无差异。

不同模型 provider 的能力、上下文长度、工具调用格式、流式细节、错误类型和计费方式仍然不同。统一 SDK 能减少工程摩擦，但不能消除模型差异。

第二，要控制成本。

AI 应用一旦上线，流式聊天、重试、工具调用、RAG 检索和多模型 fallback 都可能增加调用成本。需要做限流、缓存、日志和预算监控。

第三，要处理安全边界。

如果模型能调用工具，就必须限制工具能做什么。不要让模型直接执行高风险操作，也不要把密钥、数据库写权限和生产环境操作裸露给模型。

第四，要保留可观测性。

AI 应用出问题时，不能只看前端报错。你需要知道用户输入、模型选择、工具调用、响应时间、token 消耗、错误类型和最终输出。

小结

vercel/ai 不是一个新的模型，也不是单纯的聊天组件。

它更像 TypeScript AI 应用开发的基础设施：统一 Provider、流式输出、工具调用、前端状态管理和 agent 场景，都被放进一个开源 SDK 里。

对已经使用 Next.js、React、TypeScript、Node.js 的团队来说，它可以显著降低从“模型 API 能跑”到“产品体验可用”的工程成本。

但它也不是万能层。模型选择、权限设计、成本控制、日志监控和业务安全，仍然需要开发者自己负责。

如果你想做 AI 应用，而不是训练模型，Vercel AI SDK 是一个值得先试的工具包。

参考资料

Next.js 高危 SSRF 漏洞 CVE-2026-44578：影响范围与升级建议

Sun, 17 May 2026 17:27:13 +0800

Next.js 在 2026 年 5 月披露了一个高危 SSRF 漏洞：CVE-2026-44578。

根据 GitHub / Vercel 安全公告 GHSA-c4j6-fc7j-m34r 和 NVD 记录，这个漏洞影响自托管的 Next.js 应用，前提是应用使用内置 Node.js server，并且暴露在可接收恶意 WebSocket upgrade 请求的网络环境中。攻击者可能让服务器代理请求到任意内部或外部地址，从而访问内部服务或云元数据端点。

Vercel 托管的部署不受影响。修复版本是 15.5.16 和 16.2.5。

先说结论

如果你在自己服务器、容器、Kubernetes、ECS、VPS、裸机或 PaaS 上自托管 Next.js，需要优先检查。

受影响范围：

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

不受影响或风险较低的情况：

部署在 Vercel 平台上的应用。
已升级到 15.5.16、16.2.5 或更高版本。
没有使用内置 Node.js server 暴露服务的场景。
反向代理或负载均衡已经阻断不需要的 WebSocket upgrade 请求，并且出站访问也做了限制。

推荐处置顺序：

先确认生产环境实际运行的 next 版本。
自托管应用尽快升级到修复版本。
暂时无法升级时，在反向代理或负载均衡层阻断不需要的 WebSocket upgrade。
限制应用服务器访问云元数据、内网管理面和敏感内部服务。
排查近期异常 WebSocket upgrade 请求和内部访问日志。

漏洞是什么

CVE-2026-44578 是一个 Server-Side Request Forgery，也就是 SSRF 漏洞。

SSRF 的核心风险是：攻击者不直接访问内部系统，而是诱导你的服务器替他发请求。服务器通常位于更靠近内网、云平台和内部服务的位置，所以一旦被当成代理使用，可能访问到外部攻击者本来碰不到的资源。

这次 Next.js 的问题出在 WebSocket upgrade 处理路径。安全公告称，自托管应用如果使用内置 Node.js server，攻击者可以通过特制 WebSocket upgrade 请求，让服务器代理访问任意内部或外部目的地。

风险点包括：

内网 HTTP 服务。
管理后台。
云元数据地址。
容器或集群内部服务。
只允许服务器访问的内部 API。

这个漏洞的 CVSS v3.1 评分为 8.6 High，向量是：

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

这意味着攻击面在网络侧，攻击复杂度低，不需要权限，也不需要用户交互，主要影响机密性。

为什么自托管更危险

这次公告明确提到：Vercel-hosted deployments are not affected。

真正需要重点关注的是自托管部署。原因很简单：自托管应用的网络环境千差万别，有些直接暴露 origin server，有些在 Nginx、Traefik、Ingress、Cloudflare、ALB 或自建网关后面，有些运行在云主机、容器网络或 Kubernetes 集群里。

如果这些环境没有限制出站访问，Next.js 进程可能看得到：

169.254.169.254 这类云元数据地址。
内网 IP 段。
只在 VPC 内暴露的服务。
Redis、Elasticsearch、Prometheus、Grafana 等内部组件。
Kubernetes Service、Pod 或管理端点。

所以 SSRF 的危险不只在 Next.js 本身，而在它所在网络里能访问什么。

如何判断是否受影响

第一步，看 next 版本。

在项目目录里执行：

`1`	`npm ls next`

或：

`1`	`pnpm why next`

也可以直接查看：

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

如果版本落在下面范围，就需要处理：

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

第二步，看部署方式。

重点关注这些情况：

使用 next start 运行生产服务。
使用自定义 Node.js server 承载 Next.js。
Docker 镜像里直接启动 Next.js server。
Kubernetes / ECS / VPS / 裸机自托管。
反向代理后面仍然直接暴露 Next.js origin。
应用所在网络能访问内部服务或云元数据。

如果应用部署在 Vercel，按官方公告不受这个漏洞影响。但依然建议保持 Next.js 版本更新，因为同一批版本里可能还修复了其他问题。

应该升级到什么版本

官方修复版本是：

15.5.16
16.2.5

升级示例：

`1`	`npm install next@15.5.16`

或如果使用 16.x：

`1`	`npm install next@16.2.5`

pnpm：

`1`	`pnpm add next@15.5.16`

或：

`1`	`pnpm add next@16.2.5`

升级后重新构建并发布：

1
2

npm run build
npm run start

或按你的 CI/CD 流程重新构建 Docker 镜像并发布。

如果你的项目锁定在 14.x 或 15.x，不建议为了修漏洞仓促跨大版本到 16.x。更稳妥的做法是先升级到 15.5.16 这一修复线，完成测试和发布后，再规划大版本升级。

临时缓解措施

如果暂时不能升级，安全公告给出的核心思路是：不要把 origin server 直接暴露给不可信网络；如果不需要 WebSocket upgrade，就在反向代理或负载均衡层阻断；同时尽量限制 origin 的出站访问。

可以考虑这些缓解方向：

不直接暴露 Next.js origin server。
在 Nginx、Ingress、ALB、Cloudflare 等入口层过滤不需要的 WebSocket upgrade。
如果业务不使用 WebSocket，直接拒绝带有 upgrade 语义的请求。
对应用服务器做 egress 限制，禁止访问云元数据地址和敏感内网段。
用云平台能力启用更安全的元数据访问模式，例如要求 token 的元数据服务。
对管理后台、数据库、缓存、监控系统增加认证和网络隔离。

注意，反向代理规则只是临时缓解，不应该替代升级。框架漏洞最终仍然要通过修复版本解决。

运维排查重点

这个漏洞主要影响机密性，所以排查重点是“有没有被用来访问内部资源”。

建议关注：

Web 访问日志中异常的 Upgrade、Connection、Host、路径和来源 IP。
反向代理或负载均衡日志中异常的 WebSocket upgrade 请求。
Next.js 服务附近的异常出站连接。
云元数据服务访问日志或凭据使用记录。
内网管理服务、监控系统、缓存、搜索服务的异常访问。
IAM 临时凭据、访问密钥、token 是否有异常调用。
容器或主机上是否出现异常进程、下载行为或横向移动迹象。

如果怀疑被利用，建议按泄露场景处理：

保留日志和现场。
轮换可能暴露的云凭据、API key、数据库密码和 session secret。
检查云账号最近的 API 调用。
检查内网服务访问记录。
重建受影响容器或主机。
复查出站访问策略和元数据保护。

这和 React/Next.js RCE 不是一回事

容易混淆的一点是，CVE-2026-44578 是 Next.js WebSocket upgrade SSRF，不是之前 React Server Components 相关的 RCE。

它的核心影响是让服务器向攻击者指定的内部或外部地址发请求，主要风险是信息泄露和内部资源探测。

而 React Server Components 相关 RCE 则属于代码执行风险，攻击后果和修复范围不同。

所以排查时不要只看“Next.js 有漏洞”这个大标题，要把具体 CVE、影响版本、部署模式和修复版本对应起来。

哪些团队要优先处理

优先级最高的是这些环境：

自托管 Next.js 生产站点。
运行在云主机、容器、Kubernetes 或内网环境。
应用服务器可以访问云元数据服务。
应用服务器能访问内部管理后台、数据库、缓存或监控系统。
直接暴露 next start origin server。
使用老版本 next，且升级流程不清晰。

优先级相对较低的是：

完全部署在 Vercel 的应用。
已升级到修复版本的应用。
origin server 不直接暴露，且入口层已经阻断不需要的 WebSocket upgrade。
出站网络严格受控，无法访问敏感内网资源。

但“优先级较低”不等于可以不升级。Next.js 是高频暴露组件，框架版本长期落后会叠加更多风险。

给开发团队的检查清单

可以按下面清单处理：

确认所有仓库的 next 版本。
查出所有自托管部署，不只看 Vercel 项目。
标记使用 next start 或内置 Node.js server 的服务。
升级到 15.5.16、16.2.5 或更高版本。
重新构建并发布生产镜像。
在入口层阻断不需要的 WebSocket upgrade。
限制应用服务器访问云元数据和敏感内网段。
检查近期异常 upgrade 请求和出站访问。
轮换疑似暴露的凭据。
把 Next.js 安全更新纳入依赖更新流程。

总结

CVE-2026-44578 是一个需要认真处理的 Next.js 高危 SSRF 漏洞。

它不影响 Vercel 托管部署，但影响范围覆盖大量自托管 Next.js 应用：13.4.13 到 15.5.16 之前，以及 16.0.0 到 16.2.5 之前。漏洞触发点在 WebSocket upgrade 处理路径，攻击者可能让服务器代理访问内部或外部地址，进而暴露内网服务或云元数据端点。

最直接的修复方式是升级到 15.5.16 或 16.2.5。临时缓解则是不要直接暴露 origin server，阻断不需要的 WebSocket upgrade，并限制应用服务器的出站访问。

对运维团队来说，重点不是只看 CVE 分数，而是看你的 Next.js 服务所在网络能访问什么。SSRF 的真实风险，往往取决于服务器背后有哪些内网资源和云权限。

参考链接：