Void硬刚Next.js：Vite生态迎来一站式应用部署平台

用了这么多年 Vite 做项目，我几乎每年都会遇到同一个问题：开发阶段有多爽，上线阶段就有多折腾。构建快是真的快，但每次到了部署这一步，要么自己搭 Docker，要么去研究各种平台的配置规则，总感觉 Vite 生态缺了一个官方出口。所以当看到尤雨溪这边推出 Void 的消息时，我第一反应不是“又来一个部署平台”，而是“早该有人做这件事了”。Void 要补的，正是 Vite 项目从写代码到上线的最后一公里，目标就是成为 Vite 生态里的那个“Vercel”。

这篇文章我会从产品定位、技术设计、部署实操、排坑记录这几个角度展开，把标题里“硬刚 Next.js”这件事拆开来看。如果你手头正好在维护 Vite 项目，或者一直在纠结要不要为了部署体验切换到 Next.js，那么这篇内容应该能帮你省不少调研时间。

1. 从 Vite 到 Void：这次“硬刚”到底在刚什么

1.1 Next.js 赢的不只是框架，而是完整闭环

先说一个这些年越来越明显的判断：前端框架的竞争，打到最后已经不是 API 设计层面的竞争了。Next.js 这几年能坐稳位置，核心原因不在于它多写了几个服务端组件，而在于它和 Vercel 这套部署体系长在了一起。从本地开发、预览部署、环境变量管理到边缘函数分发，整套链路是顺的。用一句话概括：别人还在拼框架，Next.js 已经拼完“框架+平台”的闭环。

这一点我用 Vite 的时候体会特别深。Vite 做构建工具，体验无可挑剔，冷启动快、HMR 快、生态干净。但构建完之后的部署环节，始终没有一个官方形态。你可以自己接 Docker、自己搭 Nginx、自己折腾静态托管，但这每一步都需要额外投入。对个人项目还好，对团队来说，这种“最后一公里”的缺失，会直接拉高落地成本。

1.2 Vite 的优势和一直没解决的短板

这里我不是踩 Vite，而是要解释清楚为什么 Void 这个事有意义。Vite 的优势在于它的架构：基于原生 ES module 的开发服务器，依赖预构建用的 esbuild，生产构建现在正全面切到 Rolldown。这套组合让 Vite 在构建速度和开发体验上一直领先同类工具。

但生态强大并不等于闭环完整。Vite 官方提供的只是构建和 dev server，不包含托管、不包含发布流程、不包含运行时容器。这些年社区不断出现基于 Vite 的 SSG 框架（比如 VitePress）、路由约定框架（比如 vike），但每个框架都要各自处理部署。结果就是：框架层百花齐放，平台层一盘散沙。

这个局面带来的直接后果是，很多团队在选型时明明更认可 Vite 的开发体验，最后却因为部署和运维成本选择了体系更封闭但更完整的 Next.js。说到底，大家要的不是某个单一的构建工具，而是一条能顺畅走完全程的链路。

1.3 Void 想补的那个位置

所以当我看到 Void 的消息，第一反应是尤雨溪这次终于把目光从工具链移到了更上层的交付环节。名称上它继承了 VoidZero 的“Void”，目标也很直白：给 Vite 生态一个类似 Vercel 的原生部署平台。

这里要说清楚，Void 不是一个传统的“静态托管服务”，它瞄准的是应用托管：支持服务端渲染、支持边缘函数、支持按项目维度管理环境变量和权限。换句话说，它想做的事跟 Vercel 高度重合，但选择的技术底座是 Vite 加 Rolldown。

它不是要替代 Vite，而是让 Vite 项目的开发、构建、发布形成一条完整链路。对开发者来说，最直观的变化就是：不用再为了部署一个 Vite 应用，额外学习另一套 Docker 或 CI 的配置。这个切入点，恰好是 Vite 生态长久以来缺失的一环。

2. 拆解 Void 的产品形态

2.1 名字里的指向性

先从名字