后端Web框架SSR【免费下载链接】vinextVite plugin that reimplements the Next.js API surface — deploy anywhere项目地址https://gitcode.com/gh_mirrors/vi/vinext点击查看免费下载本指南以仓库中的pages-router-cloudflare示例为完整蓝本讲解如何使用 vinext一个重新实现 Next.js API 表面、可随处部署的 Vite 插件将经典的 Next.js Pages Router 应用运行在 Cloudflare Workers 上。读完本文你将掌握该示例的完整目录结构、本地开发/构建/预览命令链、vite.config.ts 与 wrangler.jsonc 的配置含义以及getServerSideProps、next/head、next/link、动态路由、API Routes、middleware、rewrites/redirects 等 Pages Router 特性在 Workers 运行时中的真实落点。示例概览最小可运行的 Pages Router Workers 组合examples/pages-router-cloudflare/README.md 将自身定位为运行在 Cloudflare Workers 上的最小 Next.js Pages Router 应用示例并明确列出它演示的能力getServerSideProps服务端数据获取next/head页面级head管理next/link客户端路由导航动态路由pages/posts/[id].tsxAPI Routespages/api/*.ts整个示例的目录结构如下所有页面、路由与配置都是可以直接运行的真实代码而不是占位骨架examples/pages-router-cloudflare/ ├── components/counter.tsx # 客户端交互组件 ├── lib/ # CommonJS 互操作验证文件 ├── pages/ │ ├── api/ # API Routeshello / revalidate / error-route 等 │ ├── posts/[id].tsx # 动态路由页面 │ ├── index.tsx # 首页getServerSideProps Head Link │ ├── about.tsx / ssr.tsx / nav-test.tsx ├── public/ # 静态资源 ├── instrumentation.ts # 运行时初始化与错误上报钩子 ├── middleware.ts # Edge Middleware ├── next.config.mjs # headers / redirects / rewrites ├── vite.config.ts # vinext Cloudflare Vite 插件 └── wrangler.jsonc # Workers 部署配置其中lib/目录下的cjs-local-identity.cjs、cjs-module-identity.js配合pages/cjs-dependency-globals.jsx页面用于验证 CommonJS 依赖在 Workers 运行时中的互操作性——这是跨运行时部署时常见的兼容性痛点。本地开发与构建完整的命令链README 给出了从安装依赖到生产构建预览的四步命令链这也是任何基于该模板启动新项目时的标准流程# 1. 安装依赖 pnpm install # 2. 启动开发服务器 pnpm dev # 3. 构建生产版本 pnpm build # 4. 预览生产构建产物 pnpm preview这四条命令的背后映射关系记录在示例的 package.json 中全部由 vinext 的 CLI 承载{ scripts: { dev: vinext dev, build: vinext build, start: vinext start, preview: vinext start } }其中preview与start都指向vinext start即在本地以生产模式启动 Worker 服务用于在部署前验证vinext build产出的真实构建结果。依赖方面示例直接采用vinext: workspace:*monorepo 内联版本并同时引入cloudflare/vite-plugin、wrangler、vite、react、react-dom以及vitejs/plugin-react说明这套开发链路本质上就是Vite 生态 Cloudflare Workers 生态的融合。vite.config.tsvinext 与 Cloudflare Vite 插件的组合方式示例的 vite.config.ts 非常精简却揭示了 vinext 运行模型的核心import { defineConfig } from vite; import vinext from vinext; import { cloudflare } from cloudflare/vite-plugin; export default defineConfig({ plugins: [ vinext(), cloudflare(), ], });两个插件按顺序挂载vinext()负责接管 Next.js 的 API 表面Pages Router 与 App Router 的路由、数据获取、编译管线等cloudflare()则来自官方 cloudflare/vite-plugin负责提供 Workers 运行时环境、绑定Bindings与本地模拟。这种vinext 提供 Next.js 语义 Cloudflare 插件提供 Workers 运行时的分工是 vinext 支持随处部署的关键设计业务代码保持 Next.js 写法运行环境由对应的平台插件决定。wrangler.jsoncWorkers 部署配置的要点examples/pages-router-cloudflare/wrangler.jsonc 是部署侧的核心配置值得逐项解读{ $schema: node_modules/wrangler/config-schema.json, name: pages-router-cloudflare, compatibility_date: 2026-02-12, compatibility_flags: [nodejs_compat], main: vinext/server/fetch-handler, preview_urls: true, assets: { directory: dist/client, not_found_handling: none, binding: ASSETS } }main指向vinext/server/fetch-handler即 vinext 生成的 Worker 入口模块——所有页面请求都会汇聚到这个统一的 fetch handler 中由 vinext 内部完成路由分发。assets静态资源目录指向dist/clientvinext build的产物目录并通过ASSETSbinding 暴露给 Workernot_found_handling: none表示 404 交由 Worker 逻辑处理而不是由静态资源服务直接兜底。compatibility_flags开启nodejs_compat为 Next.js 生态中常见的 Node.js API 提供 workerd 兼容层。compatibility_date声明 Workers 运行时兼容日期锁定行为语义。Pages Router 页面实战特性在 Workers 上的真实写法首页getServerSideProps next/head next/linkpages/index.tsx 把 README 声称的三个演示特性集中在一个页面里import type { GetServerSidePropsResult } from next; import Head from next/head; import Link from next/link; import { Counter } from ../components/counter; export async function getServerSideProps(): PromiseGetServerSidePropsResultHomeProps { return { props: { timestamp: new Date().toISOString(), }, }; } export default function Home({ timestamp }: HomeProps) { return ( Head titleCloudflare Pages Router/title /Head h1Hello from Pages Router on Workers!/h1 pRendered at: {timestamp}/p Counter / nav Link href/aboutAbout/Link{ | } Link href/ssrSSR Page/Link /nav / ); }代码中的注释点明了 Pages Router 的一个重要实践时间戳这类动态值必须来自getServerSideProps以避免水合hydration不一致——该值会被序列化进__NEXT_DATA__在客户端水合时复用。这正是 Pages Router 数据流在 Workers 上的标准行为服务端渲染时执行getServerSideProps结果随 HTML 一起下发。页面还嵌入了Counter客户端组件见 components/counter.tsx用useState演示了水合后的客户端交互。服务端渲染页与运行时探测pages/ssr.tsx 展示了如何探测运行时环境runtime: typeof navigator ! undefined ? navigator.userAgent : unknown,在 workerd 环境中navigator是可用的 Web 标准全局对象因此通过typeof navigator ! undefined可以确认代码确实运行在 Workers 的 Web 运行时中——这也是 vinext 兼容 Web 标准 API 的直接证据。页面用data-testid标记关键输出便于 e2e 测试断言对应仓库 tests/e2e 中的 Pages Router 测试套件。动态路由posts/[id].tsxpages/posts/[id].tsx 演示了 Pages Router 的动态路由段在 Workers 上的处理方式——getServerSideProps的上下文参数直接携带路由参数export async function getServerSideProps( ctx: GetServerSidePropsContext, ): PromiseGetServerSidePropsResultPostProps { const id ctx.params?.id as string; return { props: { id, title: Post ${id}, }, }; }ctx.params.id即 URL 路径中[id]段的实际取值访问/posts/anything时id会被解析为anything页面内通过data-testid输出标题与 ID供测试验证动态段解析正确性。API Routes从 hello 到按需缓存失效API Routes 是 Pages Router 的另一个核心能力。pages/api/hello.ts 展示了最标准的写法——直接使用NextApiRequest/NextApiResponse类型通过res.json()返回 JSONimport type { NextApiRequest, NextApiResponse } from next; export default function handler(_req: NextApiRequest, res: NextApiResponse) { res.json({ message: Hello from Pages Router API on Workers!, runtime: typeof navigator ! undefined ? navigator.userAgent : unknown, }); }更有实战价值的是 pages/api/revalidate.ts它演示了 Pages Router 的按需缓存失效On-demand Revalidation在 Workers 上的用法await res.revalidate(path, { unstable_onlyGenerated: req.query.onlyGenerated 1, });res.revalidate()支持传入unstable_onlyGenerated选项配合仓库中的revalidate-target.tsx、nested-revalidate.ts、revalidation-host-sentinel.ts等页面/路由构成了完整的请求触发 → 缓存失效 → 重新生成验证链路对应tests/e2e中的 ISR 与 revalidate 相关测试如 isr-cache.test.ts、isr-decision.test.ts。请求生命周期next.config 与 middleware 的协同Pages Router 应用在请求到达页面之前会依次经过next.config.mjs定义的 headers / redirects / rewrites 以及middleware.ts。示例用这两个文件把请求管线的各个阶段完整串了起来。next.config.mjs 演示了三类路由改写export default { async headers() { return [ { source: /about, headers: [{ key: X-Page-Header, value: about-page }], }, ]; }, async redirects() { return [ { source: /redirect-before-middleware-rewrite, destination: /about, permanent: false, }, ]; }, async rewrites() { return { beforeFiles: [], afterFiles: [ { source: /nav-test, destination: /about }, { source: /rewrite-about, destination: /about }, ], fallback: [], }; }, };其中 rewrites 区分了beforeFiles先于文件系统路由、afterFiles后于文件系统路由和fallback三个优先级阶段。示例页面 pages/nav-test.tsx 的注释专门说明了这一点Filesystem route wins before afterFiles——即/nav-test作为真实文件路由存在时会优先于afterFiles阶段的 rewrite 命中而fallback阶段还会根据环境变量VINEXT_E2E_REVALIDATION_PROXY条件性地注入外部代理 rewrite用于 e2e 测试。middleware.ts 则展示了 Edge Middleware 在 Workers 上的完整能力按matcher匹配请求、通过NextResponse.next()继续请求、NextResponse.rewrite()改写、NextResponse.redirect()重定向、甚至直接以自定义状态码返回响应export function middleware(request: NextRequest) { // 直接响应418 if (request.nextUrl.pathname /redirect-before-middleware-response) { return new Response(middleware response, { status: 418 }); } const response NextResponse.next(); response.headers.set(x-mw-ran, true); response.headers.set(x-mw-pathname, request.nextUrl.pathname); return response; } export const config { matcher: [/api/:path*, /about, /ssr, /_next/static/middleware-rewrite.js], };middleware 会给命中的请求统一附加x-mw-ran响应头供测试断言middleware 确实执行了。结合next.config.mjs中同名路径的 headers/redirects 配置仓库的 e2e 测试可以验证headers → redirects → middleware → rewrite → 页面这一完整管线的执行顺序。运行时初始化instrumentation.ts示例还包含 instrumentation.ts演示了 Next.js 的运行时钩子在 Workers 上的映射export async function register(): Promisevoid { markRegisterCalled(); } export async function onRequestError( error: Error, request: { path: string; method: string; headers: Recordstring, string }, context: { routerKind: string; routePath: string; routeType: string }, ): Promisevoid { recordRequestError({ ... }); }register()在 Worker 启动阶段执行一次用于埋点、初始化探针等onRequestError()在请求出错时回调携带路由类型routerKind/routeType、路径与方法信息是接入可观测性如 Sentry的挂载点。对应地仓库 docs/tracing.mdx 对 vinext 的追踪与错误上报体系有更完整的说明。从示例到生产部署Cloudflare Workers 部署流程示例的wrangler.jsonc已经为部署做好了准备。仓库官方文档 docs/deploying/cloudflare.mdx 给出了标准的三步部署流程与本文示例直接配套1. 初始化项目首次新建项目时使用示例仓库本身已配置完毕pnpm dlx vinext init --platformcloudflare初始化器会创建或更新vite.config.ts与wrangler.jsonc并可选择启用缓存与图片优化。2. 认证pnpm dlx wrangler login将 Cloudflare 账号 ID 写入wrangler.jsonc或设置CLOUDFLARE_ACCOUNT_ID环境变量CI 环境中则使用CLOUDFLARE_API_TOKEN替代浏览器登录。3. 部署pnpm dlx vinext/cloudflare deploy pnpm dlx vinext/cloudflare deploy --env staging # 多环境 pnpm dlx vinext/cloudflare deploy --preview # 预览环境部署命令会校验初始化配置、构建所有 Vite 环境含本示例的dist/client静态产物并发布 Worker。部署后如需使用 Workers Bindings如 D1 数据库、KV、R2可在任意 Server Component、Route Handler 或 Server Action 中直接import { env } from cloudflare:workers访问绑定在wrangler.jsonc中按 Cloudflare 标准方式声明即可——这也是 vinext 原生 Cloudflare 集成的核心卖点之一。小结一个示例覆盖的完整能力面这个最小示例实际上串起了 Pages Router 应用在 Workers 上运行的完整能力面能力维度示例落点数据获取getServerSideProps首页、SSR 页、动态路由页路由与导航next/link、动态路由[id]、next/head服务端接口API Routeshello、revalidate按需失效请求管线next.config.mjs的 headers/redirects/rewrites 与middleware.ts运行时钩子instrumentation.ts的 register / onRequestError构建与部署vite.config.tsvinext cloudflare 插件、wrangler.jsonc无论你是想评估 vinext 对既有 Pages Router 代码的兼容程度还是准备把存量 Next.js 项目迁移到 Workers迁移指南见 docs/getting-started/migrating.mdx都可以从 examples/pages-router-cloudflare 这个示例出发pnpm install pnpm dev起本地开发pnpm build pnpm preview验证生产构建最后按上文部署流程发布到 Cloudflare Workers。赞分享后端Web框架SSR【免费下载链接】vinextVite plugin that reimplements the Next.js API surface — deploy anywhere项目地址https://gitcode.com/gh_mirrors/vi/vinext点击查看免费下载相关推荐在 Cloudflare Workers 上运行 Next.js App Routervinext 实战示例全解析在 Cloudflare Workers 上运行 Next.js App Routervinext 实战示例全解析 导读 examples/app route后端Web框架SSR5分钟快速上手Fan ControlWindows电脑风扇控制的终极解决方案5分钟快速上手Fan ControlWindows电脑风扇控制的终极解决方案 Fan Control是一款专为Windows系统设计的免费风扇控制软件让你完后端AI Agent人工智能流程编排WebSocketVike 官方示例实战在 Cloudflare Workers 上运行 React SSR 应用Vike 官方示例实战在 Cloudflare Workers 上运行 React SSR 应用 本篇指南基于 Vike 仓库中的官方示例 examples/前端后端Web框架SSR上一篇bttn.css动画效果实现原理cubic-bezier函数的魔力下一篇Angular错误监控awesome-angular日志工具推荐创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 Cloudflare Workers 上运行 Next.js Pages Router：vinext 最小示例从零跑通
后端Web框架SSR【免费下载链接】vinextVite plugin that reimplements the Next.js API surface — deploy anywhere项目地址https://gitcode.com/gh_mirrors/vi/vinext点击查看免费下载本指南以仓库中的pages-router-cloudflare示例为完整蓝本讲解如何使用 vinext一个重新实现 Next.js API 表面、可随处部署的 Vite 插件将经典的 Next.js Pages Router 应用运行在 Cloudflare Workers 上。读完本文你将掌握该示例的完整目录结构、本地开发/构建/预览命令链、vite.config.ts 与 wrangler.jsonc 的配置含义以及getServerSideProps、next/head、next/link、动态路由、API Routes、middleware、rewrites/redirects 等 Pages Router 特性在 Workers 运行时中的真实落点。示例概览最小可运行的 Pages Router Workers 组合examples/pages-router-cloudflare/README.md 将自身定位为运行在 Cloudflare Workers 上的最小 Next.js Pages Router 应用示例并明确列出它演示的能力getServerSideProps服务端数据获取next/head页面级head管理next/link客户端路由导航动态路由pages/posts/[id].tsxAPI Routespages/api/*.ts整个示例的目录结构如下所有页面、路由与配置都是可以直接运行的真实代码而不是占位骨架examples/pages-router-cloudflare/ ├── components/counter.tsx # 客户端交互组件 ├── lib/ # CommonJS 互操作验证文件 ├── pages/ │ ├── api/ # API Routeshello / revalidate / error-route 等 │ ├── posts/[id].tsx # 动态路由页面 │ ├── index.tsx # 首页getServerSideProps Head Link │ ├── about.tsx / ssr.tsx / nav-test.tsx ├── public/ # 静态资源 ├── instrumentation.ts # 运行时初始化与错误上报钩子 ├── middleware.ts # Edge Middleware ├── next.config.mjs # headers / redirects / rewrites ├── vite.config.ts # vinext Cloudflare Vite 插件 └── wrangler.jsonc # Workers 部署配置其中lib/目录下的cjs-local-identity.cjs、cjs-module-identity.js配合pages/cjs-dependency-globals.jsx页面用于验证 CommonJS 依赖在 Workers 运行时中的互操作性——这是跨运行时部署时常见的兼容性痛点。本地开发与构建完整的命令链README 给出了从安装依赖到生产构建预览的四步命令链这也是任何基于该模板启动新项目时的标准流程# 1. 安装依赖 pnpm install # 2. 启动开发服务器 pnpm dev # 3. 构建生产版本 pnpm build # 4. 预览生产构建产物 pnpm preview这四条命令的背后映射关系记录在示例的 package.json 中全部由 vinext 的 CLI 承载{ scripts: { dev: vinext dev, build: vinext build, start: vinext start, preview: vinext start } }其中preview与start都指向vinext start即在本地以生产模式启动 Worker 服务用于在部署前验证vinext build产出的真实构建结果。依赖方面示例直接采用vinext: workspace:*monorepo 内联版本并同时引入cloudflare/vite-plugin、wrangler、vite、react、react-dom以及vitejs/plugin-react说明这套开发链路本质上就是Vite 生态 Cloudflare Workers 生态的融合。vite.config.tsvinext 与 Cloudflare Vite 插件的组合方式示例的 vite.config.ts 非常精简却揭示了 vinext 运行模型的核心import { defineConfig } from vite; import vinext from vinext; import { cloudflare } from cloudflare/vite-plugin; export default defineConfig({ plugins: [ vinext(), cloudflare(), ], });两个插件按顺序挂载vinext()负责接管 Next.js 的 API 表面Pages Router 与 App Router 的路由、数据获取、编译管线等cloudflare()则来自官方 cloudflare/vite-plugin负责提供 Workers 运行时环境、绑定Bindings与本地模拟。这种vinext 提供 Next.js 语义 Cloudflare 插件提供 Workers 运行时的分工是 vinext 支持随处部署的关键设计业务代码保持 Next.js 写法运行环境由对应的平台插件决定。wrangler.jsoncWorkers 部署配置的要点examples/pages-router-cloudflare/wrangler.jsonc 是部署侧的核心配置值得逐项解读{ $schema: node_modules/wrangler/config-schema.json, name: pages-router-cloudflare, compatibility_date: 2026-02-12, compatibility_flags: [nodejs_compat], main: vinext/server/fetch-handler, preview_urls: true, assets: { directory: dist/client, not_found_handling: none, binding: ASSETS } }main指向vinext/server/fetch-handler即 vinext 生成的 Worker 入口模块——所有页面请求都会汇聚到这个统一的 fetch handler 中由 vinext 内部完成路由分发。assets静态资源目录指向dist/clientvinext build的产物目录并通过ASSETSbinding 暴露给 Workernot_found_handling: none表示 404 交由 Worker 逻辑处理而不是由静态资源服务直接兜底。compatibility_flags开启nodejs_compat为 Next.js 生态中常见的 Node.js API 提供 workerd 兼容层。compatibility_date声明 Workers 运行时兼容日期锁定行为语义。Pages Router 页面实战特性在 Workers 上的真实写法首页getServerSideProps next/head next/linkpages/index.tsx 把 README 声称的三个演示特性集中在一个页面里import type { GetServerSidePropsResult } from next; import Head from next/head; import Link from next/link; import { Counter } from ../components/counter; export async function getServerSideProps(): PromiseGetServerSidePropsResultHomeProps { return { props: { timestamp: new Date().toISOString(), }, }; } export default function Home({ timestamp }: HomeProps) { return ( Head titleCloudflare Pages Router/title /Head h1Hello from Pages Router on Workers!/h1 pRendered at: {timestamp}/p Counter / nav Link href/aboutAbout/Link{ | } Link href/ssrSSR Page/Link /nav / ); }代码中的注释点明了 Pages Router 的一个重要实践时间戳这类动态值必须来自getServerSideProps以避免水合hydration不一致——该值会被序列化进__NEXT_DATA__在客户端水合时复用。这正是 Pages Router 数据流在 Workers 上的标准行为服务端渲染时执行getServerSideProps结果随 HTML 一起下发。页面还嵌入了Counter客户端组件见 components/counter.tsx用useState演示了水合后的客户端交互。服务端渲染页与运行时探测pages/ssr.tsx 展示了如何探测运行时环境runtime: typeof navigator ! undefined ? navigator.userAgent : unknown,在 workerd 环境中navigator是可用的 Web 标准全局对象因此通过typeof navigator ! undefined可以确认代码确实运行在 Workers 的 Web 运行时中——这也是 vinext 兼容 Web 标准 API 的直接证据。页面用data-testid标记关键输出便于 e2e 测试断言对应仓库 tests/e2e 中的 Pages Router 测试套件。动态路由posts/[id].tsxpages/posts/[id].tsx 演示了 Pages Router 的动态路由段在 Workers 上的处理方式——getServerSideProps的上下文参数直接携带路由参数export async function getServerSideProps( ctx: GetServerSidePropsContext, ): PromiseGetServerSidePropsResultPostProps { const id ctx.params?.id as string; return { props: { id, title: Post ${id}, }, }; }ctx.params.id即 URL 路径中[id]段的实际取值访问/posts/anything时id会被解析为anything页面内通过data-testid输出标题与 ID供测试验证动态段解析正确性。API Routes从 hello 到按需缓存失效API Routes 是 Pages Router 的另一个核心能力。pages/api/hello.ts 展示了最标准的写法——直接使用NextApiRequest/NextApiResponse类型通过res.json()返回 JSONimport type { NextApiRequest, NextApiResponse } from next; export default function handler(_req: NextApiRequest, res: NextApiResponse) { res.json({ message: Hello from Pages Router API on Workers!, runtime: typeof navigator ! undefined ? navigator.userAgent : unknown, }); }更有实战价值的是 pages/api/revalidate.ts它演示了 Pages Router 的按需缓存失效On-demand Revalidation在 Workers 上的用法await res.revalidate(path, { unstable_onlyGenerated: req.query.onlyGenerated 1, });res.revalidate()支持传入unstable_onlyGenerated选项配合仓库中的revalidate-target.tsx、nested-revalidate.ts、revalidation-host-sentinel.ts等页面/路由构成了完整的请求触发 → 缓存失效 → 重新生成验证链路对应tests/e2e中的 ISR 与 revalidate 相关测试如 isr-cache.test.ts、isr-decision.test.ts。请求生命周期next.config 与 middleware 的协同Pages Router 应用在请求到达页面之前会依次经过next.config.mjs定义的 headers / redirects / rewrites 以及middleware.ts。示例用这两个文件把请求管线的各个阶段完整串了起来。next.config.mjs 演示了三类路由改写export default { async headers() { return [ { source: /about, headers: [{ key: X-Page-Header, value: about-page }], }, ]; }, async redirects() { return [ { source: /redirect-before-middleware-rewrite, destination: /about, permanent: false, }, ]; }, async rewrites() { return { beforeFiles: [], afterFiles: [ { source: /nav-test, destination: /about }, { source: /rewrite-about, destination: /about }, ], fallback: [], }; }, };其中 rewrites 区分了beforeFiles先于文件系统路由、afterFiles后于文件系统路由和fallback三个优先级阶段。示例页面 pages/nav-test.tsx 的注释专门说明了这一点Filesystem route wins before afterFiles——即/nav-test作为真实文件路由存在时会优先于afterFiles阶段的 rewrite 命中而fallback阶段还会根据环境变量VINEXT_E2E_REVALIDATION_PROXY条件性地注入外部代理 rewrite用于 e2e 测试。middleware.ts 则展示了 Edge Middleware 在 Workers 上的完整能力按matcher匹配请求、通过NextResponse.next()继续请求、NextResponse.rewrite()改写、NextResponse.redirect()重定向、甚至直接以自定义状态码返回响应export function middleware(request: NextRequest) { // 直接响应418 if (request.nextUrl.pathname /redirect-before-middleware-response) { return new Response(middleware response, { status: 418 }); } const response NextResponse.next(); response.headers.set(x-mw-ran, true); response.headers.set(x-mw-pathname, request.nextUrl.pathname); return response; } export const config { matcher: [/api/:path*, /about, /ssr, /_next/static/middleware-rewrite.js], };middleware 会给命中的请求统一附加x-mw-ran响应头供测试断言middleware 确实执行了。结合next.config.mjs中同名路径的 headers/redirects 配置仓库的 e2e 测试可以验证headers → redirects → middleware → rewrite → 页面这一完整管线的执行顺序。运行时初始化instrumentation.ts示例还包含 instrumentation.ts演示了 Next.js 的运行时钩子在 Workers 上的映射export async function register(): Promisevoid { markRegisterCalled(); } export async function onRequestError( error: Error, request: { path: string; method: string; headers: Recordstring, string }, context: { routerKind: string; routePath: string; routeType: string }, ): Promisevoid { recordRequestError({ ... }); }register()在 Worker 启动阶段执行一次用于埋点、初始化探针等onRequestError()在请求出错时回调携带路由类型routerKind/routeType、路径与方法信息是接入可观测性如 Sentry的挂载点。对应地仓库 docs/tracing.mdx 对 vinext 的追踪与错误上报体系有更完整的说明。从示例到生产部署Cloudflare Workers 部署流程示例的wrangler.jsonc已经为部署做好了准备。仓库官方文档 docs/deploying/cloudflare.mdx 给出了标准的三步部署流程与本文示例直接配套1. 初始化项目首次新建项目时使用示例仓库本身已配置完毕pnpm dlx vinext init --platformcloudflare初始化器会创建或更新vite.config.ts与wrangler.jsonc并可选择启用缓存与图片优化。2. 认证pnpm dlx wrangler login将 Cloudflare 账号 ID 写入wrangler.jsonc或设置CLOUDFLARE_ACCOUNT_ID环境变量CI 环境中则使用CLOUDFLARE_API_TOKEN替代浏览器登录。3. 部署pnpm dlx vinext/cloudflare deploy pnpm dlx vinext/cloudflare deploy --env staging # 多环境 pnpm dlx vinext/cloudflare deploy --preview # 预览环境部署命令会校验初始化配置、构建所有 Vite 环境含本示例的dist/client静态产物并发布 Worker。部署后如需使用 Workers Bindings如 D1 数据库、KV、R2可在任意 Server Component、Route Handler 或 Server Action 中直接import { env } from cloudflare:workers访问绑定在wrangler.jsonc中按 Cloudflare 标准方式声明即可——这也是 vinext 原生 Cloudflare 集成的核心卖点之一。小结一个示例覆盖的完整能力面这个最小示例实际上串起了 Pages Router 应用在 Workers 上运行的完整能力面能力维度示例落点数据获取getServerSideProps首页、SSR 页、动态路由页路由与导航next/link、动态路由[id]、next/head服务端接口API Routeshello、revalidate按需失效请求管线next.config.mjs的 headers/redirects/rewrites 与middleware.ts运行时钩子instrumentation.ts的 register / onRequestError构建与部署vite.config.tsvinext cloudflare 插件、wrangler.jsonc无论你是想评估 vinext 对既有 Pages Router 代码的兼容程度还是准备把存量 Next.js 项目迁移到 Workers迁移指南见 docs/getting-started/migrating.mdx都可以从 examples/pages-router-cloudflare 这个示例出发pnpm install pnpm dev起本地开发pnpm build pnpm preview验证生产构建最后按上文部署流程发布到 Cloudflare Workers。赞分享后端Web框架SSR【免费下载链接】vinextVite plugin that reimplements the Next.js API surface — deploy anywhere项目地址https://gitcode.com/gh_mirrors/vi/vinext点击查看免费下载相关推荐在 Cloudflare Workers 上运行 Next.js App Routervinext 实战示例全解析在 Cloudflare Workers 上运行 Next.js App Routervinext 实战示例全解析 导读 examples/app route后端Web框架SSR5分钟快速上手Fan ControlWindows电脑风扇控制的终极解决方案5分钟快速上手Fan ControlWindows电脑风扇控制的终极解决方案 Fan Control是一款专为Windows系统设计的免费风扇控制软件让你完后端AI Agent人工智能流程编排WebSocketVike 官方示例实战在 Cloudflare Workers 上运行 React SSR 应用Vike 官方示例实战在 Cloudflare Workers 上运行 React SSR 应用 本篇指南基于 Vike 仓库中的官方示例 examples/前端后端Web框架SSR上一篇bttn.css动画效果实现原理cubic-bezier函数的魔力下一篇Angular错误监控awesome-angular日志工具推荐创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考