Void它的目标很直接：让一个 Vite 项目不仅仅能跑在本地，还能更顺畅地走到生产环境。

在过去几年里，Vite 已经成为很多前端项目的默认开发工具。无论是开发体验还是构建速度，它都逐渐取代了传统工具链，成为现代前端开发的重要基础设施。

但如果把视角从“本地开发”往外延伸一点，会发现一个很明显的断层：Vite 解决了开发体验，但没有解决应用上线的问题。

从本地项目到真正上线，开发者通常还需要自己处理一整套基础设施，例如：

• 部署环境

• 数据库

• 对象存储

• 身份认证

• 队列与定时任务

这些能力往往来自不同的平台，需要自己去配置和拼接。

Void 想解决的，其实就是这一段缺失的环节。

从 Vite 项目到云端应用

Void 的核心形态其实很简单：一个 Vite 插件 + 一套云端能力。

开发者只需要在项目中启用插件：

import void from "void"

export default {
  plugins: [void()]
}

然后执行一条命令：

void deploy

应用就会被直接部署到 Cloudflare 的 Edge 网络。

整个过程不需要手动创建基础设施，也不需要进入云平台控制台。数据库、存储、队列等资源都会在部署时自动配置。

换句话说，Void 想把部署这件事变成：和启动 dev server 一样简单的一条命令。

自动提供一整套后端能力

Void 不只是一个部署工具，它更像是一套自动配置的后端基础设施。

在项目中引入不同模块，就可以直接使用对应服务。例如：

数据库：

import { db } from "void/db"

默认使用 Cloudflare D1。本地开发时会通过 Miniflare 模拟 Cloudflare 运行环境，因此本地和线上行为基本保持一致。

KV 存储：

import { kv } from "void/kv"

对象存储：

import { storage } from "void/storage"

AI 推理：

import { ai } from "void/ai"

以及认证、队列、定时任务等功能。

很多能力甚至只需要创建一个目录，例如：

queues/
crons/

部署时就会自动注册。

这种设计的核心思路其实很清晰：开发者只需要关注应用代码，基础设施由平台自动完成。

端到端类型安全

Void 另一个重要设计是端到端类型安全。

它默认使用 Drizzle ORM 作为数据库层。开发者只需要定义数据库 schema，Void 就可以：

• 自动生成类型

• 自动生成 migration

• 在部署时自动执行迁移

同时前端和后端之间的数据结构也可以基于 schema 自动推导类型，从而保证整个调用链路的类型一致。

这种模式其实已经成为现代全栈开发的一种趋势，例如 tRPC 或 Prisma 等工具都在尝试类似方向。

不止是部署平台

Void 虽然可以理解为部署平台，但它的设计其实更像是一套平台 SDK。

因为它不仅可以用于普通 Vite 项目，也可以和各种基于 Vite 的框架一起使用。

例如：

• Nuxt

• SvelteKit

• TanStack Start

只要这些框架最终运行在 Vite 之上，就可以接入 Void 的能力。

这意味着这些框架可以在不改变开发模式的情况下获得：

• 数据库

• 存储

• 认证

• AI

• 队列

• 部署

整套后端能力。

Void 甚至可以自己当框架

如果不使用其他框架，其实也可以直接使用 Void 提供的页面系统。

例如创建：

pages/

每个文件都会自动成为一个页面。组件可以使用：

• vue

• JSX / TSX

• Solid

同时也支持 Markdown 页面以及 Islands 组件模式。

在渲染模式上，Void 也支持多种方式：

• SSR

• SSG

• ISR

本地开发与云环境一致

Void 还试图解决另一个常见问题：本地环境与线上环境不一致。

在本地开发时，Void 会模拟 Cloudflare 的运行环境，包括：

• D1

• KV

• Storage

甚至 AI 调用也可以通过代理连接到云端模型。

因此开发者在本地测试的行为，与最终部署到 Edge 时基本一致。

一个完整的 CLI 工具链

Void 的很多能力都通过 CLI 提供，例如：

• 部署

• 数据库迁移

• 数据库 seed

• 查看部署状态

• 查看日志

CLI 甚至内置了一个 MCP Server，可以让 AI Agent 直接访问项目文档或部署日志。

例如生成数据库模型：

void gen model posts title:string content:string

就可以自动生成 schema。

Cloudflare 的“深度绑定”

不过 Void 还有一个非常明确的前提。

尤雨溪在介绍时也非常坦率地说明：Void 会与 Cloudflare 深度绑定，这种绑定正是开发体验成立的前提。

很多能力其实直接来自 Cloudflare 的生态，例如：

• Workers

• D1

• KV

• R2

• Workers AI

如果没有这些基础设施，Void 很难做到现在这种自动化程度。

当然，他也特别强调了一点：Vite 本身依然是平台无关的。

如果不想使用 Void，开发者仍然可以把 Vite 和其他后端框架组合，例如：

• Nitro

• Adonis

• 自己的 Node 后端

Void 只是提供了一种新的选择。

Void vs Vercel

如果从产品形态来看，很多人第一反应会把 Void 和 Vercel 放在一起比较。

原因很简单，两者其实都在做一件事情——把一个开发框架和一个部署平台深度绑定。

在 Vercel 的体系里，核心组合是：Next.js + Vercel 平台（Vercel 基于 AWS）。Next.js 负责应用开发，而 Vercel 提供：

• 部署

• CDN

• Serverless

• Edge Functions

• 数据服务

这套组合最大的优势就是极度优化的开发体验。很多 Next.js 的能力在 Vercel 上几乎是开箱即用。

Void 的思路其实非常类似。

它把 Vite 作为开发工具核心，然后通过 Void 提供：

• 数据库

• 存储

• AI

• 队列

• 一键部署

开发者只需要写代码，其余基础设施由平台自动完成。

但两者之间也有一个明显区别：Vercel 使用的是自己的云平台，而 Void 完全构建在 Cloudflare 生态之上。

换句话说，Void 更像是：Cloudflare 能力的一层开发者抽象。

这也解释了为什么尤雨溪会直接说：这种平台绑定正是开发体验成立的前提。

如果说 Vercel 是 Next.js 的官方平台，那么 Void 很可能会成为 Vite 生态里的那个版本。

Vite 生态的新一步

从更大的角度来看，Void 其实反映了一种趋势：前端工具链正在逐渐向“应用平台”演进。

过去几年类似的模式已经出现过，例如 Next.js + Vercel。

而 Void 的特别之处在于，它是从 Vite 生态内部长出来的。

如果这个方向发展顺利，未来的开发流程可能会变得非常简单：写一个 Vite 应用，然后通过一条命令部署到 Edge，数据库、存储、认证等能力都自动提供。

这正是 Void 想实现的目标。

本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！

链接: https://fly63.com/article/detial/13413