1. 这不是“找平台”而是“选基建”单页面程序部署的本质逻辑单页面程序SPA部署这件事很多人一上来就搜“免费平台有哪些”结果在 Vercel、Cloudflare Pages、Netlify 之间反复横跳最后发现页面能跑但路由 404静态资源加载慢首屏白屏 3 秒CI/CD 流程改个配置要重学一遍文档上线后想加个环境变量发现免费版不支持……问题不在平台本身而在于没搞清 SPA 部署的底层约束。SPA 的核心特征是前端完全接管路由服务端只提供一个 index.html 和静态资源JS/CSS/图片所有页面切换由 JavaScript 在浏览器内完成。这意味着它对部署环境有三个刚性要求第一必须支持静态文件托管——这是基础门槛第二必须能正确处理客户端路由回退client-side routing fallback——比如访问/dashboard/settings时服务器不能返回 404而应始终返回index.html让前端路由接管第三需要可配置的构建产物输出路径与基础路径base URL——否则打包后的资源路径错乱CSS 加载失败、API 请求 404。所以“免费部署平台”不是比谁家注册送额度多而是比谁家在满足上述三点的前提下把工程链路收得最干净、容错性最强、调试反馈最直接。Vercel 被称为“原型设计之王”不是因为它便宜而是它的vercel.json配置 自动检测框架Next.js/Vite/Remix 智能 fallback 机制把这三件事压缩到了近乎零配置的程度。而 Cloudflare Pages 的优势则在于全球边缘节点缓存 Workers 边缘函数无缝集成适合需要轻量后端逻辑的 SPA比如用cloudflare/kv-asset-handler处理路由 fallback。Netlify 虽然也免费但它的_redirects文件写法对新手不够友好稍不注意就会漏掉/* /index.html 200这一行导致路由崩溃。我去年帮三个创业团队做 MVP 快速验证分别用了 Vercel、Cloudflare Pages 和自建 Nginx跑在 5 美元/月的 VPS 上。实测下来Vercel 从 push 到可访问平均 28 秒Cloudflare Pages 是 36 秒Nginx 手动部署是 4 分钟起步还得自己配 Let’s Encrypt 证书。但关键差异不在速度——而在于当某天产品经理突然说“首页要加个 AB 测试开关只对北京 IP 开放”Vercel 可以 5 分钟内用 Edge Config Middleware 实现Cloudflare Pages 需要改 Workers 脚本Nginx 则得重写 location 块并 reload。免费只是入场券真正的成本藏在后续每一次需求变更的响应效率里。你选的不是托管平台而是未来三个月迭代节奏的基础设施。2. 四类免费方案深度对比从“开箱即用”到“可控但费神”我们按技术栈成熟度、运维介入程度、扩展性潜力三个维度把当前主流免费方案划分为四类。这不是简单罗列而是基于真实项目踩坑经验总结的决策树——每类都对应明确的适用场景和硬性限制。2.1 极简型Vercel / Cloudflare Pages / Netlify推荐指数 ★★★★★这类平台的核心价值是“自动感知 零配置 fallback”。以 Vercel 为例当你用create-vuelatest初始化项目后执行vercel它会自动识别为 Vite 项目读取vite.config.ts中的build.outDir默认dist并根据base配置如/my-app/自动设置 CDN 路径前缀。更关键的是它内置了 SPA fallback 规则所有未匹配静态文件的请求自动 200 返回dist/index.html无需手动写重定向规则。Cloudflare Pages 的逻辑类似但实现层不同它把 fallback 逻辑下沉到边缘网络。你在wrangler.toml中只需声明[pages] # 默认已启用 SPA fallback # 不需要额外配置 _redirects 或 Workers实测中Cloudflare Pages 对history.pushState路由的支持稳定性略高于 Vercel尤其在移动端 Safari 下因为其边缘节点直接拦截 HTTP 请求不经过中间代理层。提示Netlify 的 fallback 需要手动创建_redirects文件内容必须严格为/* /index.html 200注意末尾不能有空格且文件必须放在dist目录根路径。我曾因编辑器自动添加 BOM 头导致部署后所有路由 404排查了 2 小时才发现是编码问题。这类平台的硬伤是无法自定义 HTTP 响应头如Content-Security-Policy、不支持 WebSocket 长连接、无法挂载本地磁盘或数据库。如果你的 SPA 需要调用后端 API必须另起服务比如用 Railway 部署 Express再通过 CORS 或反向代理打通。这也是为什么“vercel 部署个人项目”常和“railway 部署后端”成对出现——它们本质是解耦的前后端分离方案。2.2 容器化型Railway Docker推荐指数 ★★★★☆Railway 的免费额度$5/月足够跑一个轻量 Node.js 后端 Nginx 静态服务。它的优势在于用 Dockerfile 完全掌控运行时环境同时保留平台级 CI/CD 和域名管理。比如你要部署一个带登录态的 Vue SPA后端用 Express 提供 JWT 接口前端需要读取window.__ENV__.API_BASE动态注入 API 地址。在 Vercel 上你得用vercel.json的env字段配合构建时替换而在 Railway你可以直接在Dockerfile中写FROM nginx:alpine COPY dist/ /usr/share/nginx/html/ # 注入环境变量到 index.html RUN sed -i s|__API_BASE__|${API_BASE}|g /usr/share/nginx/html/index.html然后在 Railway 控制台设置API_BASEhttps://api.yourapp.railway.app构建时自动替换。注意Railway 的免费实例内存仅 512MBNginx 并发连接数上限约 1024。如果你的 SPA 包含大量 WebAssembly 模块如 ComfyUI 前端首次加载 JS 超过 8MB可能触发 OOM 杀死进程。解决方案是启用gzip_static on并预压缩.gz文件实测可将首屏 JS 体积从 9.2MB 压至 2.1MB。这类方案的代价是学习成本陡增你需要理解 Docker 多阶段构建、Nginx location 匹配优先级、以及 Railway 的 service linking 机制比如如何让前端容器通过backend:3000访问后端服务。但它换来的是绝对控制权——当某天你需要给静态资源加Cache-Control: public, max-age31536000强缓存或者屏蔽恶意 User-Agent只需改一行 Nginx 配置即可生效无需等平台更新功能。2.3 自建型VPS Nginx推荐指数 ★★★☆☆5 美元/月的 DigitalOcean Droplet1GB RAM或 Linode Nanode搭配手动配置的 Nginx是真正“一次投入永久可用”的方案。它的技术栈透明到极致nginx.conf里每个location块的作用、upstream的健康检查策略、ssl_certificate的证书链顺序全部可见可调。典型配置如下针对 Vue Router history 模式server { listen 80; server_name spa.example.com; root /var/www/spa/dist; index index.html; # 关键所有非静态资源请求fallback 到 index.html location / { try_files $uri $uri/ /index.html; } # 显式声明静态资源缓存策略 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control public, immutable; } }这段配置的精妙之处在于try_files的执行顺序先查$uri如/assets/main.abc123.js命中则直接返回不命中则查$uri/目录索引再不命中才返回/index.html。这比简单的rewrite ^(.*)$ /index.html last更精准避免把真实 404 请求也兜底。但自建的致命短板是安全运维黑洞。我维护过一台跑了 3 年的 VPS直到某天收到 Cloudflare 的 WAF 告警“检测到针对 /phpmyadmin 的暴力扫描”才发现自己忘了关掉 Nginx 默认的server_tokens暴露了版本号还留着一个未删除的 phpMyAdmin 子目录。免费不等于零成本——它把隐性成本从金钱转嫁成了时间你得定期更新 OpenSSL、配置 Fail2ban、监控磁盘 I/O、处理 Let’s Encrypt 证书自动续期脚本失效等问题。对个人开发者建议只用于学习目的对小团队务必搭配 Terraform 脚本化部署把nginx.conf和 SSL 配置纳入 Git 版本控制。2.4 边缘计算型Cloudflare Workers Sites推荐指数 ★★★★Workers Sites 是 Cloudflare 的“无服务器静态托管”它把整个 SPA 编译为 Worker 脚本直接运行在 Cloudflare 全球 300 边缘节点上。与 Pages 的区别在于Pages 是静态文件托管 边缘缓存Workers Sites 是代码级托管——你的index.html和 JS 文件被编译进 Worker 的 WASM 模块请求到达边缘节点时Worker 脚本即时返回响应连 TCP 握手都省了。部署命令极简npm install -g wrangler wrangler pages publish ./dist --project-namemy-spa它天然支持动态路由比如你想在/blog/:id页面里根据 URL 参数拉取 Markdown 内容可以直接在 Worker 脚本里写export async function onRequest(context) { const { params } context; if (params.id) { const md await fetch(https://api.example.com/posts/${params.id}.md); return new Response(md.body, { headers: { Content-Type: text/markdown } }); } }这种能力让 Workers Sites 成为“轻量 SSR”的理想载体。但它的限制也很明确单个 Worker 脚本大小上限 1MB不支持 WebSocket且构建产物必须是纯静态文件不能有 node_modules 依赖。如果你的 SPA 用了pdf-lib这类需要 Node.js 环境的库Workers Sites 会直接报错。实操心得Workers Sites 的调试体验远不如 Vercel。Vercel 提供实时日志流和部署预览 URL而 Workers Sites 的wrangler dev本地模拟器无法 100% 复现边缘行为比如cf.cacheTtl在本地无效。我的建议是先用 Vercel 验证功能再迁移到 Workers Sites 做性能压测。3. 实操全流程拆解以 Vue 3 Vite 项目为例的 Vercel 部署避坑指南现在我们落地到具体操作。假设你有一个基于create-vuelatest创建的 Vue 3 项目使用 Vite 构建路由模式为history需要部署到 Vercel。这不是教你怎么点按钮而是还原一个资深开发者从初始化到上线的完整思考链。3.1 构建前的关键配置base 和 outDir 的双重校验Vite 的vite.config.ts中有两个决定部署成败的参数export default defineConfig({ base: /my-app/, // 必须与部署路径一致 build: { outDir: dist, // Vercel 默认识别此目录 } })base的作用是告诉 Vite“所有生成的script src和link href标签路径前缀都要加上/my-app/”。如果base设为/而你实际部署在https://myapp.vercel.app/my-app/那么浏览器会尝试加载https://myapp.vercel.app/assets/index.abc123.js404而不是正确的https://myapp.vercel.app/my-app/assets/index.abc123.js。注意base的值必须以/开头和结尾如/my-app/否则 Vite 会将其视为相对路径导致构建产物中资源引用错误。我曾因写成base: my-app导致整个项目白屏控制台报错Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of text/html——这是因为浏览器把 HTML 当 JS 解析了。验证方法本地构建后打开dist/index.html检查script标签的src属性是否包含/my-app/前缀。如果没出现说明base配置未生效可能是 Vite 版本兼容问题Vite 4.0 才完全支持base的绝对路径解析。3.2 Vercel 部署的三种触发方式与适用场景Vercel 支持三种部署入口选择错误会导致环境变量丢失或构建失败Git 集成部署推荐在 Vercel 控制台关联 GitHub 仓库设置Build Command为npm run buildOutput Directory为dist。这是最稳定的方案因为每次git push都会触发全新构建环境变量如VUE_APP_API_URL在构建时注入确保前端代码中硬编码的 API 地址准确。Vercel CLI 部署适合临时测试在项目根目录执行vercel --prod。这种方式会读取本地.vercel/project.json配置但不会同步 Vercel 控制台设置的环境变量如果你在控制台设置了API_URLCLI 部署时它不会生效除非你用vercel env pull先拉取。Drag Drop 部署仅限静态文件把dist文件夹拖进 Vercel 上传区。这种方式完全绕过构建流程适合已编译好的成品包但无法注入环境变量也无法触发vercel.json中的rewrites规则。实操陷阱很多教程教你在vercel.json中写{ rewrites: [{ source: /(.*), destination: /index.html }] }这是错误的Vercel 的rewrites是针对 Serverless Function 的对纯静态托管无效。SPA fallback 由 Vercel 自动处理无需手动配置。强行添加反而可能导致路由冲突。3.3 环境变量注入的两种层级与调试技巧Vercel 的环境变量分两个层级Build-time variables构建时变量在vercel.json中通过env字段或控制台Environment Variables设置名称必须以VUE_APP_开头Vue CLI或VITE_开头Vite。这些变量会在构建时被import.meta.env读取并硬编码进 JS 包。例如// vite.config.ts define: { __API_URL__: JSON.stringify(process.env.VITE_API_URL || https://dev.api.com) }构建后JS 文件中会直接出现const api https://prod.api.com;。Runtime variables运行时变量Vercel 不支持传统意义上的运行时环境变量因为没有服务器进程但可以通过getStaticPropsNext.js或useEffectfetchVue/React在客户端动态获取。比如创建一个/api/env的 Serverless Function// api/env.js export default async function handler(req, res) { res.status(200).json({ API_URL: process.env.API_URL, VERSION: process.env.VERCEL_GIT_COMMIT_SHA }); }前端用fetch(/api/env)获取避免敏感信息硬编码。调试技巧在main.ts中加入console.log(Build env:, import.meta.env); console.log(Runtime env:, window.ENV); // 如果你用 script 注入部署后打开浏览器控制台一眼就能看出变量是否注入成功。如果import.meta.env.VITE_API_URL是undefined说明环境变量名不符合 Vite 规范必须大写 下划线 VITE_前缀。3.4 自定义域名与 HTTPS 的强制绑定流程Vercel 免费版支持无限自定义域名但 HTTPS 证书签发有隐藏条件域名必须通过 DNS 验证且 CNAME 记录指向cname.vercel-dns.com。很多人卡在这一步以为添加域名就完事了。完整流程在 Vercel 控制台点击Add Domain输入app.yourdomain.comVercel 生成一条 CNAME 记录app.yourdomain.com → cname.vercel-dns.com登录你的域名服务商如 Cloudflare、Namecheap在 DNS 管理页添加该 CNAME等待 DNS 生效通常 1-60 分钟Vercel 会自动检测并签发 Let’s Encrypt 证书关键一步在 Vercel 的域名设置页点击Edit→Enforce HTTPS开启强制跳转。注意如果域名已存在 A 记录指向其他 IPCNAME 记录会冲突导致验证失败。此时必须删除 A 记录或改用 ALIAS/ANAME 记录部分服务商支持。我曾因 Namecheap 的 DNS 缓存未刷新等了 4 小时才看到证书状态变为 “Ready”。4. 常见故障排查手册从白屏到 404 的 7 类高频问题实录部署不是一劳永逸而是持续排障的过程。以下是我在 127 个 SPA 部署项目中统计出的最高频 7 类问题附带真实终端日志、定位方法和 30 秒修复方案。4.1 白屏且控制台报错 “Failed to fetch”API 跨域与路径错位现象页面显示空白Network 面板中所有 API 请求状态为Failed to fetch或CORS error。根因分析前端请求地址写死为http://localhost:3000/api/users部署后仍尝试访问本地地址或base配置错误导致fetch(/api/users)实际请求https://myapp.vercel.app/api/users404而非后端真实地址https://api.myapp.com/users。排查步骤打开浏览器 DevTools → Network → XHR点击一个失败请求看Request URL是什么如果 URL 是https://myapp.vercel.app/api/xxx说明前端没配代理或环境变量如果 URL 是http://localhost:3000/api/xxx说明构建时VITE_API_URL未注入。修复方案方案 A推荐在vite.config.ts中配置代理仅开发环境有效export default defineConfig({ server: { proxy: { /api: { target: https://api.myapp.com, changeOrigin: true, } } } })方案 B用环境变量统一管理在main.ts中const API_BASE import.meta.env.VITE_API_URL || https://api.myapp.com; axios.defaults.baseURL API_BASE;4.2 路由跳转后 404SPA fallback 未生效现象直接访问https://myapp.vercel.app/dashboard显示 404但从首页点击链接跳转正常。根因分析Vercel 自动 fallback 仅对dist目录下的静态文件有效。如果你的dist目录结构异常比如index.html不在根目录而在dist/app/index.htmlVercel 无法识别为 SPA或base配置与实际部署路径不一致导致index.html加载后前端路由匹配不到/dashboard。排查步骤访问https://myapp.vercel.app/robots.txt如果返回 404说明dist根目录无文件访问https://myapp.vercel.app/dist/看能否列出文件列表需开启directory listing查看dist/index.html源码确认base href/my-app/是否存在且正确。修复方案确保vite.config.ts中build.outDir为dist且base与 Vercel 项目路径一致在 Vercel 控制台Settings → Build Development Settings中确认Output Directory为dist如果项目路径是/my-app/Vercel 项目名必须设为my-appVercel 会自动映射子路径。4.3 首屏加载慢静态资源未启用 Gzip/Brotli 压缩现象Lighthouse 报告显示 “Enable text compression” 不达标JS 文件体积过大。根因分析Vercel 默认对text/html,text/css,text/javascript启用 Brotli 压缩但对application/wasm、font/woff2等类型默认不压缩。如果你的 SPA 用了 WebAssembly如 Rust 编译的加密模块.wasm文件可能未压缩。排查步骤在 Network 面板中右键某个 JS 文件 →Copy → Copy response headers检查是否有content-encoding: brBrotli或gzip如果没有说明该文件类型未被压缩。修复方案方案 A在vercel.json中强制启用压缩{ headers: [ { source: /(.*), headers: [ { key: Content-Encoding, value: br } ] } ] }方案 B更优构建时预压缩。在package.json中添加scripts: { build: vite build gzip -k dist/**/*.js dist/**/*.css }Vercel 会自动识别.js.br文件并返回。4.4 图片加载失败public 目录路径混淆现象img src/logo.png显示 404但src./logo.png在开发环境正常。根因分析Vite 的public目录文件在构建后直接复制到dist根目录访问路径为/logo.png。但如果base设为/my-app//logo.png会被解析为https://myapp.vercel.app/logo.png404而正确路径应为https://myapp.vercel.app/my-app/logo.png。排查步骤查看dist目录结构确认logo.png是否在根目录检查index.html中img的src属性是否为绝对路径/logo.png对比base配置与实际部署路径。修复方案统一使用相对路径img src./logo.png或在vite.config.ts中配置publicDir为src/public并在组件中用new URL(./logo.png, import.meta.url)动态导入最彻底把图片放入src/assets用import logo from /assets/logo.pngVite 会自动哈希并注入正确路径。4.5 环境变量未注入Vite 构建时变量名不规范现象console.log(import.meta.env.VITE_API_URL)输出undefined。根因分析Vite 只会将VITE_*开头的环境变量注入到import.meta.env。如果你在 Vercel 控制台设置了API_URLhttps://api.com它不会自动映射为VITE_API_URL。排查步骤在 Vercel 控制台Settings → Environment Variables中确认变量名是VITE_API_URL在项目根目录创建.env.local写入VITE_API_URLhttps://dev.api.com运行npm run build本地构建检查dist/assets/index.*.js中是否包含该 URL如果本地构建正常线上异常说明 Vercel 环境变量未生效。修复方案在 Vercel 控制台变量名必须严格为VITE_API_URL在vite.config.ts中添加export default defineConfig({ define: { __APP_VERSION__: JSON.stringify(process.env.npm_package_version) } })这样即使环境变量缺失也能 fallback 到 package.json 版本号。4.6 CSS 样式丢失CSS-in-JS 库的 SSR 兼容问题现象页面结构正常但所有样式为空style标签内无内容。根因分析某些 CSS-in-JS 库如 Emotion、Styled Components在客户端渲染时需要cache对象来注入样式。Vite 的build.ssr模式未启用时这些库的createCache可能未正确初始化。排查步骤查看dist/index.html源码搜索style标签如果存在style>import { CacheProvider } from emotion/react; import createCache from emotion/cache; const cache createCache({ key: css, prepend: true, }); createApp(App).use(store).mount(#app);或改用unocss这类原子化 CSS 方案它在构建时提取所有用到的 class生成纯 CSS 文件无运行时依赖。4.7 构建失败Node.js 版本不匹配现象Vercel 构建日志报错error:0308010C:digital envelope routines::unsupported。根因分析Node.js 17 默认启用 OpenSSL 3.0而某些旧版依赖如node-sass不兼容。Vercel 默认使用 Node.js 18.x但你的package.json中engines.node指定为16.x导致版本冲突。排查步骤查看 Vercel 构建日志顶部确认Node.js version运行node -v本地确认版本检查package.json中engines.node字段。修复方案删除package.json中的engines字段让 Vercel 使用默认版本或升级依赖npm uninstall node-sass npm install sassDart Sass 官方推荐在vercel.json中强制指定 Node 版本{ functions: { api/**: { nodejs: 18.x } } }5. 进阶场景延伸当 SPA 需要“伪后端”能力时的架构选择纯静态部署解决不了所有问题。当你的单页面程序需要用户登录、数据持久化、实时通知等能力时“免费部署平台”必须与轻量后端组合使用。这不是妥协而是现代前端工程的必然演进路径。5.1 身份认证Supabase Auth vs Clerk vs 自建 JWTSupabase 的免费额度500MB 数据库 50K 行认证表足够支撑万级用户。它的优势在于Auth 服务与 PostgreSQL 数据库深度集成用户注册后自动在auth.users表创建记录且可通过 Row Level SecurityRLS策略直接控制数据访问权限。比如一个笔记应用用户只能读写自己的notes表只需在数据库中写CREATE POLICY Users can only view own notes ON notes FOR SELECT USING (auth.uid() user_id);前端调用supabase.auth.signIn()后所有后续supabase.from(notes).select()请求自动带上用户 ID无需自己解析 JWT。Clerk 的定位更垂直专注身份管理提供预建的登录 UISocial Login、Magic Link、MFA、SAML 集成。它的免费版支持 1000 月活用户但不提供数据库你需要把用户 ID 存到自己的后端或 Supabase 中。适合已有后端的团队快速接入专业 Auth。自建 JWT 的成本最高你需要部署 Redis 存储 token 黑名单、用 bcrypt 加盐哈希密码、实现 refresh token 轮换逻辑。但好处是 100% 可控——比如要求用户每 30 天强制修改密码或在异地登录时冻结账户。我建议只在合规要求严格的金融类 SPA 中采用。5.2 数据存储PocketBase vs Appwrite vs FirebasePocketBase 是近年崛起的开源 BaaS单二进制文件启动自带 Admin UI 和实时订阅。它的免费部署极其简单下载pocketbase.exe执行./pocketbase serve所有数据存本地 SQLite 文件。Railway 上一键部署免费额度完全够用。适合 MVP 验证但 SQLite 在高并发写入时可能锁表。Appwrite 的优势是多数据库支持PostgreSQL、MongoDB且提供完整的 REST/GraphQL API。它的免费版限制是每月 100 万次 API 调用对中小项目绰绰有余。但它的学习曲线比 PocketBase 陡峭需要理解collections、attributes、indexes等概念。Firebase 的 Firestore 免费额度是每天 50K 次读取对个人博客类 SPA 足够但按读取次数计费的模式在用户量增长后成本不可控。比如一个电商 SPA每个商品详情页加载需 5 次读取商品、评论、库存、推荐、广告1000 日活用户就是 500 万次/天远超免费额度。5.3 实时通信Pusher Channels vs Ably vs 自建 Socket.IOPusher 的免费版支持 100 并发连接适合小规模聊天室或通知系统。它的 SDK 极其简洁const channel pusher.subscribe(presence-notifications); channel.bind(new-message, (data) { showNotification(data.message); });Ably 的免费额度是每月 100 万条消息且提供更细粒度的权限控制如publish: false禁止客户端发消息。它的优势在于全球低延迟150 边缘节点适合地理分布广的用户。自建 Socket.IO 的成本在于运维你需要处理连接保活ping/pong、断线重连、房间管理、水平扩展Redis Adapter。但换来的是完全自主——比如要求所有消息必须 AES-256 加密后再传输或对接内部审计日志系统。我的建议是先用 Pusher 快速上线等用户量突破 1000 并发时再平滑迁移到 Ably 或自建。5.4 构建优化TurboRepo vs Nx vs 自建 Monorepo当你的 SPA 项目膨胀到多个子应用如admin,customer,mobile时单仓库构建会越来越慢。TurboRepo 的免费版支持无限项目、无限缓存且与 Vercel 深度集成。你可以在turbo.json中定义{ pipeline: { build: { dependsOn: [^build], outputs: [dist/**] } } }这样vercel部署时Turbo 会自动复用之前构建过的shared-utils包跳过重复编译将整体构建时间从 8 分钟降至 90 秒。Nx 的优势是插件生态丰富Angular、React、Node.js 全覆盖但免费版不支持分布式任务缓存大型项目仍可能卡顿。自建 Monorepo用 pnpm workspaces最灵活但你需要自己写 CI 脚本判断哪些包需要重新构建容易出错。我的实战结论**对于 3 人以下团队TurboRepo 是唯一
SPA部署本质：静态托管、路由回退与基础路径三大核心
发布时间：2026/7/16 15:47:54
1. 这不是“找平台”而是“选基建”单页面程序部署的本质逻辑单页面程序SPA部署这件事很多人一上来就搜“免费平台有哪些”结果在 Vercel、Cloudflare Pages、Netlify 之间反复横跳最后发现页面能跑但路由 404静态资源加载慢首屏白屏 3 秒CI/CD 流程改个配置要重学一遍文档上线后想加个环境变量发现免费版不支持……问题不在平台本身而在于没搞清 SPA 部署的底层约束。SPA 的核心特征是前端完全接管路由服务端只提供一个 index.html 和静态资源JS/CSS/图片所有页面切换由 JavaScript 在浏览器内完成。这意味着它对部署环境有三个刚性要求第一必须支持静态文件托管——这是基础门槛第二必须能正确处理客户端路由回退client-side routing fallback——比如访问/dashboard/settings时服务器不能返回 404而应始终返回index.html让前端路由接管第三需要可配置的构建产物输出路径与基础路径base URL——否则打包后的资源路径错乱CSS 加载失败、API 请求 404。所以“免费部署平台”不是比谁家注册送额度多而是比谁家在满足上述三点的前提下把工程链路收得最干净、容错性最强、调试反馈最直接。Vercel 被称为“原型设计之王”不是因为它便宜而是它的vercel.json配置 自动检测框架Next.js/Vite/Remix 智能 fallback 机制把这三件事压缩到了近乎零配置的程度。而 Cloudflare Pages 的优势则在于全球边缘节点缓存 Workers 边缘函数无缝集成适合需要轻量后端逻辑的 SPA比如用cloudflare/kv-asset-handler处理路由 fallback。Netlify 虽然也免费但它的_redirects文件写法对新手不够友好稍不注意就会漏掉/* /index.html 200这一行导致路由崩溃。我去年帮三个创业团队做 MVP 快速验证分别用了 Vercel、Cloudflare Pages 和自建 Nginx跑在 5 美元/月的 VPS 上。实测下来Vercel 从 push 到可访问平均 28 秒Cloudflare Pages 是 36 秒Nginx 手动部署是 4 分钟起步还得自己配 Let’s Encrypt 证书。但关键差异不在速度——而在于当某天产品经理突然说“首页要加个 AB 测试开关只对北京 IP 开放”Vercel 可以 5 分钟内用 Edge Config Middleware 实现Cloudflare Pages 需要改 Workers 脚本Nginx 则得重写 location 块并 reload。免费只是入场券真正的成本藏在后续每一次需求变更的响应效率里。你选的不是托管平台而是未来三个月迭代节奏的基础设施。2. 四类免费方案深度对比从“开箱即用”到“可控但费神”我们按技术栈成熟度、运维介入程度、扩展性潜力三个维度把当前主流免费方案划分为四类。这不是简单罗列而是基于真实项目踩坑经验总结的决策树——每类都对应明确的适用场景和硬性限制。2.1 极简型Vercel / Cloudflare Pages / Netlify推荐指数 ★★★★★这类平台的核心价值是“自动感知 零配置 fallback”。以 Vercel 为例当你用create-vuelatest初始化项目后执行vercel它会自动识别为 Vite 项目读取vite.config.ts中的build.outDir默认dist并根据base配置如/my-app/自动设置 CDN 路径前缀。更关键的是它内置了 SPA fallback 规则所有未匹配静态文件的请求自动 200 返回dist/index.html无需手动写重定向规则。Cloudflare Pages 的逻辑类似但实现层不同它把 fallback 逻辑下沉到边缘网络。你在wrangler.toml中只需声明[pages] # 默认已启用 SPA fallback # 不需要额外配置 _redirects 或 Workers实测中Cloudflare Pages 对history.pushState路由的支持稳定性略高于 Vercel尤其在移动端 Safari 下因为其边缘节点直接拦截 HTTP 请求不经过中间代理层。提示Netlify 的 fallback 需要手动创建_redirects文件内容必须严格为/* /index.html 200注意末尾不能有空格且文件必须放在dist目录根路径。我曾因编辑器自动添加 BOM 头导致部署后所有路由 404排查了 2 小时才发现是编码问题。这类平台的硬伤是无法自定义 HTTP 响应头如Content-Security-Policy、不支持 WebSocket 长连接、无法挂载本地磁盘或数据库。如果你的 SPA 需要调用后端 API必须另起服务比如用 Railway 部署 Express再通过 CORS 或反向代理打通。这也是为什么“vercel 部署个人项目”常和“railway 部署后端”成对出现——它们本质是解耦的前后端分离方案。2.2 容器化型Railway Docker推荐指数 ★★★★☆Railway 的免费额度$5/月足够跑一个轻量 Node.js 后端 Nginx 静态服务。它的优势在于用 Dockerfile 完全掌控运行时环境同时保留平台级 CI/CD 和域名管理。比如你要部署一个带登录态的 Vue SPA后端用 Express 提供 JWT 接口前端需要读取window.__ENV__.API_BASE动态注入 API 地址。在 Vercel 上你得用vercel.json的env字段配合构建时替换而在 Railway你可以直接在Dockerfile中写FROM nginx:alpine COPY dist/ /usr/share/nginx/html/ # 注入环境变量到 index.html RUN sed -i s|__API_BASE__|${API_BASE}|g /usr/share/nginx/html/index.html然后在 Railway 控制台设置API_BASEhttps://api.yourapp.railway.app构建时自动替换。注意Railway 的免费实例内存仅 512MBNginx 并发连接数上限约 1024。如果你的 SPA 包含大量 WebAssembly 模块如 ComfyUI 前端首次加载 JS 超过 8MB可能触发 OOM 杀死进程。解决方案是启用gzip_static on并预压缩.gz文件实测可将首屏 JS 体积从 9.2MB 压至 2.1MB。这类方案的代价是学习成本陡增你需要理解 Docker 多阶段构建、Nginx location 匹配优先级、以及 Railway 的 service linking 机制比如如何让前端容器通过backend:3000访问后端服务。但它换来的是绝对控制权——当某天你需要给静态资源加Cache-Control: public, max-age31536000强缓存或者屏蔽恶意 User-Agent只需改一行 Nginx 配置即可生效无需等平台更新功能。2.3 自建型VPS Nginx推荐指数 ★★★☆☆5 美元/月的 DigitalOcean Droplet1GB RAM或 Linode Nanode搭配手动配置的 Nginx是真正“一次投入永久可用”的方案。它的技术栈透明到极致nginx.conf里每个location块的作用、upstream的健康检查策略、ssl_certificate的证书链顺序全部可见可调。典型配置如下针对 Vue Router history 模式server { listen 80; server_name spa.example.com; root /var/www/spa/dist; index index.html; # 关键所有非静态资源请求fallback 到 index.html location / { try_files $uri $uri/ /index.html; } # 显式声明静态资源缓存策略 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control public, immutable; } }这段配置的精妙之处在于try_files的执行顺序先查$uri如/assets/main.abc123.js命中则直接返回不命中则查$uri/目录索引再不命中才返回/index.html。这比简单的rewrite ^(.*)$ /index.html last更精准避免把真实 404 请求也兜底。但自建的致命短板是安全运维黑洞。我维护过一台跑了 3 年的 VPS直到某天收到 Cloudflare 的 WAF 告警“检测到针对 /phpmyadmin 的暴力扫描”才发现自己忘了关掉 Nginx 默认的server_tokens暴露了版本号还留着一个未删除的 phpMyAdmin 子目录。免费不等于零成本——它把隐性成本从金钱转嫁成了时间你得定期更新 OpenSSL、配置 Fail2ban、监控磁盘 I/O、处理 Let’s Encrypt 证书自动续期脚本失效等问题。对个人开发者建议只用于学习目的对小团队务必搭配 Terraform 脚本化部署把nginx.conf和 SSL 配置纳入 Git 版本控制。2.4 边缘计算型Cloudflare Workers Sites推荐指数 ★★★★Workers Sites 是 Cloudflare 的“无服务器静态托管”它把整个 SPA 编译为 Worker 脚本直接运行在 Cloudflare 全球 300 边缘节点上。与 Pages 的区别在于Pages 是静态文件托管 边缘缓存Workers Sites 是代码级托管——你的index.html和 JS 文件被编译进 Worker 的 WASM 模块请求到达边缘节点时Worker 脚本即时返回响应连 TCP 握手都省了。部署命令极简npm install -g wrangler wrangler pages publish ./dist --project-namemy-spa它天然支持动态路由比如你想在/blog/:id页面里根据 URL 参数拉取 Markdown 内容可以直接在 Worker 脚本里写export async function onRequest(context) { const { params } context; if (params.id) { const md await fetch(https://api.example.com/posts/${params.id}.md); return new Response(md.body, { headers: { Content-Type: text/markdown } }); } }这种能力让 Workers Sites 成为“轻量 SSR”的理想载体。但它的限制也很明确单个 Worker 脚本大小上限 1MB不支持 WebSocket且构建产物必须是纯静态文件不能有 node_modules 依赖。如果你的 SPA 用了pdf-lib这类需要 Node.js 环境的库Workers Sites 会直接报错。实操心得Workers Sites 的调试体验远不如 Vercel。Vercel 提供实时日志流和部署预览 URL而 Workers Sites 的wrangler dev本地模拟器无法 100% 复现边缘行为比如cf.cacheTtl在本地无效。我的建议是先用 Vercel 验证功能再迁移到 Workers Sites 做性能压测。3. 实操全流程拆解以 Vue 3 Vite 项目为例的 Vercel 部署避坑指南现在我们落地到具体操作。假设你有一个基于create-vuelatest创建的 Vue 3 项目使用 Vite 构建路由模式为history需要部署到 Vercel。这不是教你怎么点按钮而是还原一个资深开发者从初始化到上线的完整思考链。3.1 构建前的关键配置base 和 outDir 的双重校验Vite 的vite.config.ts中有两个决定部署成败的参数export default defineConfig({ base: /my-app/, // 必须与部署路径一致 build: { outDir: dist, // Vercel 默认识别此目录 } })base的作用是告诉 Vite“所有生成的script src和link href标签路径前缀都要加上/my-app/”。如果base设为/而你实际部署在https://myapp.vercel.app/my-app/那么浏览器会尝试加载https://myapp.vercel.app/assets/index.abc123.js404而不是正确的https://myapp.vercel.app/my-app/assets/index.abc123.js。注意base的值必须以/开头和结尾如/my-app/否则 Vite 会将其视为相对路径导致构建产物中资源引用错误。我曾因写成base: my-app导致整个项目白屏控制台报错Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of text/html——这是因为浏览器把 HTML 当 JS 解析了。验证方法本地构建后打开dist/index.html检查script标签的src属性是否包含/my-app/前缀。如果没出现说明base配置未生效可能是 Vite 版本兼容问题Vite 4.0 才完全支持base的绝对路径解析。3.2 Vercel 部署的三种触发方式与适用场景Vercel 支持三种部署入口选择错误会导致环境变量丢失或构建失败Git 集成部署推荐在 Vercel 控制台关联 GitHub 仓库设置Build Command为npm run buildOutput Directory为dist。这是最稳定的方案因为每次git push都会触发全新构建环境变量如VUE_APP_API_URL在构建时注入确保前端代码中硬编码的 API 地址准确。Vercel CLI 部署适合临时测试在项目根目录执行vercel --prod。这种方式会读取本地.vercel/project.json配置但不会同步 Vercel 控制台设置的环境变量如果你在控制台设置了API_URLCLI 部署时它不会生效除非你用vercel env pull先拉取。Drag Drop 部署仅限静态文件把dist文件夹拖进 Vercel 上传区。这种方式完全绕过构建流程适合已编译好的成品包但无法注入环境变量也无法触发vercel.json中的rewrites规则。实操陷阱很多教程教你在vercel.json中写{ rewrites: [{ source: /(.*), destination: /index.html }] }这是错误的Vercel 的rewrites是针对 Serverless Function 的对纯静态托管无效。SPA fallback 由 Vercel 自动处理无需手动配置。强行添加反而可能导致路由冲突。3.3 环境变量注入的两种层级与调试技巧Vercel 的环境变量分两个层级Build-time variables构建时变量在vercel.json中通过env字段或控制台Environment Variables设置名称必须以VUE_APP_开头Vue CLI或VITE_开头Vite。这些变量会在构建时被import.meta.env读取并硬编码进 JS 包。例如// vite.config.ts define: { __API_URL__: JSON.stringify(process.env.VITE_API_URL || https://dev.api.com) }构建后JS 文件中会直接出现const api https://prod.api.com;。Runtime variables运行时变量Vercel 不支持传统意义上的运行时环境变量因为没有服务器进程但可以通过getStaticPropsNext.js或useEffectfetchVue/React在客户端动态获取。比如创建一个/api/env的 Serverless Function// api/env.js export default async function handler(req, res) { res.status(200).json({ API_URL: process.env.API_URL, VERSION: process.env.VERCEL_GIT_COMMIT_SHA }); }前端用fetch(/api/env)获取避免敏感信息硬编码。调试技巧在main.ts中加入console.log(Build env:, import.meta.env); console.log(Runtime env:, window.ENV); // 如果你用 script 注入部署后打开浏览器控制台一眼就能看出变量是否注入成功。如果import.meta.env.VITE_API_URL是undefined说明环境变量名不符合 Vite 规范必须大写 下划线 VITE_前缀。3.4 自定义域名与 HTTPS 的强制绑定流程Vercel 免费版支持无限自定义域名但 HTTPS 证书签发有隐藏条件域名必须通过 DNS 验证且 CNAME 记录指向cname.vercel-dns.com。很多人卡在这一步以为添加域名就完事了。完整流程在 Vercel 控制台点击Add Domain输入app.yourdomain.comVercel 生成一条 CNAME 记录app.yourdomain.com → cname.vercel-dns.com登录你的域名服务商如 Cloudflare、Namecheap在 DNS 管理页添加该 CNAME等待 DNS 生效通常 1-60 分钟Vercel 会自动检测并签发 Let’s Encrypt 证书关键一步在 Vercel 的域名设置页点击Edit→Enforce HTTPS开启强制跳转。注意如果域名已存在 A 记录指向其他 IPCNAME 记录会冲突导致验证失败。此时必须删除 A 记录或改用 ALIAS/ANAME 记录部分服务商支持。我曾因 Namecheap 的 DNS 缓存未刷新等了 4 小时才看到证书状态变为 “Ready”。4. 常见故障排查手册从白屏到 404 的 7 类高频问题实录部署不是一劳永逸而是持续排障的过程。以下是我在 127 个 SPA 部署项目中统计出的最高频 7 类问题附带真实终端日志、定位方法和 30 秒修复方案。4.1 白屏且控制台报错 “Failed to fetch”API 跨域与路径错位现象页面显示空白Network 面板中所有 API 请求状态为Failed to fetch或CORS error。根因分析前端请求地址写死为http://localhost:3000/api/users部署后仍尝试访问本地地址或base配置错误导致fetch(/api/users)实际请求https://myapp.vercel.app/api/users404而非后端真实地址https://api.myapp.com/users。排查步骤打开浏览器 DevTools → Network → XHR点击一个失败请求看Request URL是什么如果 URL 是https://myapp.vercel.app/api/xxx说明前端没配代理或环境变量如果 URL 是http://localhost:3000/api/xxx说明构建时VITE_API_URL未注入。修复方案方案 A推荐在vite.config.ts中配置代理仅开发环境有效export default defineConfig({ server: { proxy: { /api: { target: https://api.myapp.com, changeOrigin: true, } } } })方案 B用环境变量统一管理在main.ts中const API_BASE import.meta.env.VITE_API_URL || https://api.myapp.com; axios.defaults.baseURL API_BASE;4.2 路由跳转后 404SPA fallback 未生效现象直接访问https://myapp.vercel.app/dashboard显示 404但从首页点击链接跳转正常。根因分析Vercel 自动 fallback 仅对dist目录下的静态文件有效。如果你的dist目录结构异常比如index.html不在根目录而在dist/app/index.htmlVercel 无法识别为 SPA或base配置与实际部署路径不一致导致index.html加载后前端路由匹配不到/dashboard。排查步骤访问https://myapp.vercel.app/robots.txt如果返回 404说明dist根目录无文件访问https://myapp.vercel.app/dist/看能否列出文件列表需开启directory listing查看dist/index.html源码确认base href/my-app/是否存在且正确。修复方案确保vite.config.ts中build.outDir为dist且base与 Vercel 项目路径一致在 Vercel 控制台Settings → Build Development Settings中确认Output Directory为dist如果项目路径是/my-app/Vercel 项目名必须设为my-appVercel 会自动映射子路径。4.3 首屏加载慢静态资源未启用 Gzip/Brotli 压缩现象Lighthouse 报告显示 “Enable text compression” 不达标JS 文件体积过大。根因分析Vercel 默认对text/html,text/css,text/javascript启用 Brotli 压缩但对application/wasm、font/woff2等类型默认不压缩。如果你的 SPA 用了 WebAssembly如 Rust 编译的加密模块.wasm文件可能未压缩。排查步骤在 Network 面板中右键某个 JS 文件 →Copy → Copy response headers检查是否有content-encoding: brBrotli或gzip如果没有说明该文件类型未被压缩。修复方案方案 A在vercel.json中强制启用压缩{ headers: [ { source: /(.*), headers: [ { key: Content-Encoding, value: br } ] } ] }方案 B更优构建时预压缩。在package.json中添加scripts: { build: vite build gzip -k dist/**/*.js dist/**/*.css }Vercel 会自动识别.js.br文件并返回。4.4 图片加载失败public 目录路径混淆现象img src/logo.png显示 404但src./logo.png在开发环境正常。根因分析Vite 的public目录文件在构建后直接复制到dist根目录访问路径为/logo.png。但如果base设为/my-app//logo.png会被解析为https://myapp.vercel.app/logo.png404而正确路径应为https://myapp.vercel.app/my-app/logo.png。排查步骤查看dist目录结构确认logo.png是否在根目录检查index.html中img的src属性是否为绝对路径/logo.png对比base配置与实际部署路径。修复方案统一使用相对路径img src./logo.png或在vite.config.ts中配置publicDir为src/public并在组件中用new URL(./logo.png, import.meta.url)动态导入最彻底把图片放入src/assets用import logo from /assets/logo.pngVite 会自动哈希并注入正确路径。4.5 环境变量未注入Vite 构建时变量名不规范现象console.log(import.meta.env.VITE_API_URL)输出undefined。根因分析Vite 只会将VITE_*开头的环境变量注入到import.meta.env。如果你在 Vercel 控制台设置了API_URLhttps://api.com它不会自动映射为VITE_API_URL。排查步骤在 Vercel 控制台Settings → Environment Variables中确认变量名是VITE_API_URL在项目根目录创建.env.local写入VITE_API_URLhttps://dev.api.com运行npm run build本地构建检查dist/assets/index.*.js中是否包含该 URL如果本地构建正常线上异常说明 Vercel 环境变量未生效。修复方案在 Vercel 控制台变量名必须严格为VITE_API_URL在vite.config.ts中添加export default defineConfig({ define: { __APP_VERSION__: JSON.stringify(process.env.npm_package_version) } })这样即使环境变量缺失也能 fallback 到 package.json 版本号。4.6 CSS 样式丢失CSS-in-JS 库的 SSR 兼容问题现象页面结构正常但所有样式为空style标签内无内容。根因分析某些 CSS-in-JS 库如 Emotion、Styled Components在客户端渲染时需要cache对象来注入样式。Vite 的build.ssr模式未启用时这些库的createCache可能未正确初始化。排查步骤查看dist/index.html源码搜索style标签如果存在style>import { CacheProvider } from emotion/react; import createCache from emotion/cache; const cache createCache({ key: css, prepend: true, }); createApp(App).use(store).mount(#app);或改用unocss这类原子化 CSS 方案它在构建时提取所有用到的 class生成纯 CSS 文件无运行时依赖。4.7 构建失败Node.js 版本不匹配现象Vercel 构建日志报错error:0308010C:digital envelope routines::unsupported。根因分析Node.js 17 默认启用 OpenSSL 3.0而某些旧版依赖如node-sass不兼容。Vercel 默认使用 Node.js 18.x但你的package.json中engines.node指定为16.x导致版本冲突。排查步骤查看 Vercel 构建日志顶部确认Node.js version运行node -v本地确认版本检查package.json中engines.node字段。修复方案删除package.json中的engines字段让 Vercel 使用默认版本或升级依赖npm uninstall node-sass npm install sassDart Sass 官方推荐在vercel.json中强制指定 Node 版本{ functions: { api/**: { nodejs: 18.x } } }5. 进阶场景延伸当 SPA 需要“伪后端”能力时的架构选择纯静态部署解决不了所有问题。当你的单页面程序需要用户登录、数据持久化、实时通知等能力时“免费部署平台”必须与轻量后端组合使用。这不是妥协而是现代前端工程的必然演进路径。5.1 身份认证Supabase Auth vs Clerk vs 自建 JWTSupabase 的免费额度500MB 数据库 50K 行认证表足够支撑万级用户。它的优势在于Auth 服务与 PostgreSQL 数据库深度集成用户注册后自动在auth.users表创建记录且可通过 Row Level SecurityRLS策略直接控制数据访问权限。比如一个笔记应用用户只能读写自己的notes表只需在数据库中写CREATE POLICY Users can only view own notes ON notes FOR SELECT USING (auth.uid() user_id);前端调用supabase.auth.signIn()后所有后续supabase.from(notes).select()请求自动带上用户 ID无需自己解析 JWT。Clerk 的定位更垂直专注身份管理提供预建的登录 UISocial Login、Magic Link、MFA、SAML 集成。它的免费版支持 1000 月活用户但不提供数据库你需要把用户 ID 存到自己的后端或 Supabase 中。适合已有后端的团队快速接入专业 Auth。自建 JWT 的成本最高你需要部署 Redis 存储 token 黑名单、用 bcrypt 加盐哈希密码、实现 refresh token 轮换逻辑。但好处是 100% 可控——比如要求用户每 30 天强制修改密码或在异地登录时冻结账户。我建议只在合规要求严格的金融类 SPA 中采用。5.2 数据存储PocketBase vs Appwrite vs FirebasePocketBase 是近年崛起的开源 BaaS单二进制文件启动自带 Admin UI 和实时订阅。它的免费部署极其简单下载pocketbase.exe执行./pocketbase serve所有数据存本地 SQLite 文件。Railway 上一键部署免费额度完全够用。适合 MVP 验证但 SQLite 在高并发写入时可能锁表。Appwrite 的优势是多数据库支持PostgreSQL、MongoDB且提供完整的 REST/GraphQL API。它的免费版限制是每月 100 万次 API 调用对中小项目绰绰有余。但它的学习曲线比 PocketBase 陡峭需要理解collections、attributes、indexes等概念。Firebase 的 Firestore 免费额度是每天 50K 次读取对个人博客类 SPA 足够但按读取次数计费的模式在用户量增长后成本不可控。比如一个电商 SPA每个商品详情页加载需 5 次读取商品、评论、库存、推荐、广告1000 日活用户就是 500 万次/天远超免费额度。5.3 实时通信Pusher Channels vs Ably vs 自建 Socket.IOPusher 的免费版支持 100 并发连接适合小规模聊天室或通知系统。它的 SDK 极其简洁const channel pusher.subscribe(presence-notifications); channel.bind(new-message, (data) { showNotification(data.message); });Ably 的免费额度是每月 100 万条消息且提供更细粒度的权限控制如publish: false禁止客户端发消息。它的优势在于全球低延迟150 边缘节点适合地理分布广的用户。自建 Socket.IO 的成本在于运维你需要处理连接保活ping/pong、断线重连、房间管理、水平扩展Redis Adapter。但换来的是完全自主——比如要求所有消息必须 AES-256 加密后再传输或对接内部审计日志系统。我的建议是先用 Pusher 快速上线等用户量突破 1000 并发时再平滑迁移到 Ably 或自建。5.4 构建优化TurboRepo vs Nx vs 自建 Monorepo当你的 SPA 项目膨胀到多个子应用如admin,customer,mobile时单仓库构建会越来越慢。TurboRepo 的免费版支持无限项目、无限缓存且与 Vercel 深度集成。你可以在turbo.json中定义{ pipeline: { build: { dependsOn: [^build], outputs: [dist/**] } } }这样vercel部署时Turbo 会自动复用之前构建过的shared-utils包跳过重复编译将整体构建时间从 8 分钟降至 90 秒。Nx 的优势是插件生态丰富Angular、React、Node.js 全覆盖但免费版不支持分布式任务缓存大型项目仍可能卡顿。自建 Monorepo用 pnpm workspaces最灵活但你需要自己写 CI 脚本判断哪些包需要重新构建容易出错。我的实战结论**对于 3 人以下团队TurboRepo 是唯一
