前端部署这件事，过去我们习惯把构建产物扔到对象存储或者 Nginx 静态目录里，用户请求要跨越半个地球才能拿到资源。Deno Deploy 的思路不太一样：它把你的代码直接调度到距离用户最近的边缘节点执行，配合 Vue 3 轻量的构建产物，可以做到全球范围内毫秒级的响应。这篇文章从工程化角度完整讲一遍 Vue 3 项目部署到 Deno Deploy 的流程、原理和踩坑点。
Deno Deploy 的运行原理与传统部署有什么不同
Deno Deploy 基于 V8 Isolate 技术实现，每个请求会被分配到一个独立的隔离环境中执行，冷启动时间通常在几毫秒级别，远快于传统容器的秒级启动。它不提供完整的 Linux 虚拟机，而是一个精简的 Serverless 运行时，这意味着你不能依赖进程常驻内存的状态，也不能使用任意的原生 Node 扩展。
对于 Vue 3 项目来说，这个限制其实影响很小。SPA 应用的构建产物本质上是一堆静态文件，我们只需要在边缘节点上跑一个轻量的文件服务中间层，把请求映射到对应的 HTML、JS、CSS 文件即可。Deno Deploy 内置了 serve 和 serveDir 这类标准库 API，写一个静态文件服务器只需要十几行代码。
另外要注意的是，Deno Deploy 的免费额度已经包含了每天百万级的请求数和边缘 KV 存储，对个人项目和中小型前端应用来说基本够用，不需要提前做容量规划。
Vite 构建加文件服务：最小可用的部署方案
第一步当然是构建。Vue 3 官方脚手架默认就是 Vite，直接执行构建命令即可产出 dist 目录：
npm run build # 产物默认输出到 dist 目录 ls dist # index.html assets/ favicon.ico
接下来在项目根目录创建一个入口文件，比如 serve.ts，使用 Deno 标准库的文件服务能力托管这个目录。关键点在于使用 import map 引入标准库，避免版本漂移：
import { serveDir } from "https://deno.land/std@0.224.0/http/file_server.ts";
// SPA 路由兜底：找不到文件时回退到 index.html
Deno.serve((req: Request) => {
return serveDir(req, {
fsRoot: "dist",
showIndex: true,
});
});
上面是最简版本，但 SPA 有一个经典问题：用户直接访问 /about 这类前端路由时，文件服务会返回 404。我们需要加一层兜底逻辑，把非静态资源请求统一回退到 index.html：
import { serveDir } from "https://deno.land/std@0.224.0/http/file_server.ts";
Deno.serve(async (req: Request) => {
const res = await serveDir(req, { fsRoot: "dist", showIndex: true });
// 找不到对应文件时，返回 SPA 入口页面
if (res.status === 404) {
const html = await Deno.readFile("dist/index.html");
return new Response(html, {
headers: { "content-type": "text/html; charset=utf-8" },
});
}
return res;
});
本地验证只需要执行 deno run --allow-net --allow-read serve.ts，浏览器打开 http://localhost:8000 确认页面和前端路由都正常，就可以准备上线了。
两种上线方式：CLI 直推与 GitHub 自动部署
第一种是命令行直推。先在 Deno Deploy 控制台创建一个项目，拿到部署令牌后执行：
# 注意带上 dist 目录和入口文件 deno deploy --project=my-vue-app --entrypoint=serve.ts --include=dist,serve.ts
执行完成后终端会输出一个可访问的域名，几秒钟内代码就已经分布到全球三十多个边缘节点了。这种方式适合快速验证，但每次都要手动执行命令，不推荐长期使用。
第二种是 GitHub 集成，也是工程化实践的首选。在控制台关联仓库后，每次推送到主分支会自动触发构建和部署。这里有一个关键细节：Deno Deploy 的构建环境默认使用 Deno，而我们的项目是 npm 生态的 Vue 3 工程，所以需要提供一个 build.ts 或者在控制台配置自定义构建命令，指定先跑 npm ci && npm run build，再以 serve.ts 作为入口。如果对 npm 兼容性有顾虑，也可以在本地构建好 dist 后提交到仓库，构建环节就能完全跳过。
两种方式的取舍很明显：CLI 直推简单直接，适合 demo；GitHub 集成配合 CI 才能保证团队协作时代码与线上环境的一致性，还支持预览部署，每个 PR 都会生成独立的临时域名方便验收。
SSR 可行性与常见坑位
有人会问，Vue 3 能不能在 Deno Deploy 上做 SSR？答案是可行的，但需要一些适配工作。Deno 从 1.28 开始支持 npm 包，可以直接引入 vue 和 @vue/server-renderer：
import Vue from "npm:vue@3.4";
import { renderToString } from "npm:@vue/server-renderer@3.4";
Deno.serve(async () => {
const app = Vue.createApp({
data: () => ({ msg: "Hello from Deno Deploy SSR" }),
template: "<div>{{ msg }}</div>",
});
const html = await renderToString(app);
return new Response(html, {
headers: { "content-type": "text/html; charset=utf-8" },
});
});
不过要提醒几点。首先，Deno Deploy 不支持文件系统写入，vite build 无法在线上执行，SSR 相关的构建必须在本地或 CI 完成。其次，Nuxt 3 这类重 SSR 框架对 Node API 的依赖较深，在 Deno Deploy 上运行需要开 Node 兼容模式，个别插件可能报错，遇到问题优先考虑降级到预渲染方案，用 vite-plugin-ssr 或 vite-ssg 生成静态页面反而更稳。
最后总结几个高频坑：一是资源路径问题，如果 Vite 配置了 base: './'，在某些路由深度下资源会加载失败，建议保持默认的 / 绝对路径；二是缓存策略，serveDir 默认不带长缓存头，带哈希的静态资源建议手动加上 cache-control: public, max-age=31536000, immutable，能明显提升二次访问速度；三是自定义域名绑定，需要在控制台添加域名后到 DNS 服务商配置 CNAME 记录，生效通常需要几分钟到几小时不等。把这些细节处理好，一个 Vue 3 应用就能以几乎零成本的方式跑在全球边缘上了。
Vue 3Deno Deploy边缘部署修改时间：2026-09-09 12:13:26