服务端5月30日 20:53
Vercel 是什么？核心功能适合哪些项目？Vercel 是面向现代前端和全栈应用的部署平台。典型流程是代码推到 GitHub、GitLab 或 Bitbucket 后，Vercel 自动构建、生成预览地址，并把生产版本发布到全球边缘网络。它不是让你登录机器、装 Nginx、配证书的传统服务器，而是把构建、部署、CDN、SSL、预览环境和 Serverless 能力打包成一套工作流。
## 追问
### Vercel 解决的核心问题是什么？
它解决分支预览、证书域名、环境变量和自动部署这些前端团队常见痛点。提交 PR 就有预览地址，产品和测试可以直接验收真实页面。
### Vercel 只适合 Next.js 吗？
不是，React、Vue、SvelteKit、Nuxt、Astro 都能部署。只是 Next.js 在 Vercel 上支持最完整，SSR、ISR、Route Handler、Middleware 的坑更少。
### Serverless Functions 能替代后端吗？
能替代表单、Webhook、鉴权代理、简单聚合这类轻量接口。不适合长任务、持续连接、复杂队列消费和高状态依赖服务。
### 什么时候不适合用 Vercel？
如果系统依赖长时间运行后台服务、固定出口 IP、复杂内网或大量文件处理，就要谨慎。Vercel 更适合作为前端层和轻量 API 层。
### 团队协作最大价值是什么？
Preview Deployment 最明显。每个 PR 都能被真实访问，设计和产品不必只看截图或等测试环境排期。标签
Vercel
Vercel是一个基于云的静态网站托管和部署平台，旨在帮助开发者快速、安全地将静态网站部署到全球各地。Vercel提供了一组易于使用的CLI工具和API，可以支持从GitHub、GitLab、Bitbucket等代码托管服务中自动构建和部署静态网站。Vercel的托管服务基于CDN和HTTP/2技术，可以为全球用户提供快速和可靠的访问体验，并且支持自定义域名、SSL证书等高级特性。Vercel还提供了实时协作、预览、分支部署等功能，以帮助开发者更有效地管理和部署静态网站。由于Vercel的易用性、高性能和可扩展性，它已经成为一个备受欢迎的静态网站托管和部署平台，并被许多企业和开发者使用。
服务端5月30日 20:53
Vercel 环境变量怎么配置才安全？Vercel 环境变量管理的核心，是把 Production、Preview、Development 三类环境隔离开。生产变量只给线上部署用，预览变量给分支和 PR，用来接测试库和沙箱服务，本地变量通过 `vercel env pull` 拉到 `.env.local`。真正容易出事故的不是不会添加变量，而是变量放错环境、前端误暴露密钥、改完变量后忘记重新部署。
## 追问
### Production、Preview、Development 怎么取舍？
Production 放真实数据库、正式支付密钥和线上 API。Preview 应该接测试库、沙箱支付和临时回调地址，避免 PR 预览页误操作生产数据。
### 为什么变量改了页面还是旧配置？
构建期读取的变量已经写进产物，改 Dashboard 不会改变旧部署。关键变量改完后要重新部署，或者确认代码是在运行时读取变量。
### 前端变量为什么容易泄露？
Next.js 中带 `NEXT_PUBLIC_` 前缀的变量会打进浏览器端代码。数据库密码、私有 Token、Webhook Secret 绝不能加这个前缀。
### vercel.json 适合管什么？
适合放构建命令、输出目录、重定向、headers、函数资源限制，不适合直接写敏感值。配置越多，迁移和排错成本越高。
### 本地和线上变量不一致怎么排查？
先执行 `vercel env pull .env.local`，再确认变量名大小写、环境选择、部署时间和本地服务是否重启。
## 写段命令
```bash
vercel env add MY_API_KEY production
vercel env add MY_API_KEY preview
vercel env pull .env.local
```服务端5月30日 20:38
为什么 Next.js 部署到 Vercel 通常更省心？Next.js 部署到 Vercel 省心，核心原因是框架能力和平台能力基本对齐。Vercel 能自动识别 Next.js 项目，处理构建命令、路由、静态资源、图片优化、ISR 缓存、API Routes 和中间件。开发者把代码推到 Git 后，就能得到 Production 和 Preview 两套部署链路。
## 追问
### Vercel 是 Next.js 的唯一最佳选择吗？
不是唯一，但通常是体验最顺的选择，尤其是使用 App Router、ISR、图片优化和预览部署时。其他平台也能部署，只是可能要手动适配。
### ISR 在 Vercel 上有什么优势？
Vercel 能把 ISR 的缓存、后台再生成和 CDN 分发串起来。需要注意 revalidate 时间不能乱设，太短会增加回源压力。
### API Routes 都应该放在 Vercel 吗？
轻量接口、鉴权回调和页面数据聚合适合；长任务、复杂事务、文件处理和高频数据库写入不一定适合。
### Preview Deployment 的价值是什么？
每个 PR 都能生成独立预览地址，改 UI、验 SEO、看接口环境更快。坑在于 Preview 环境变量和数据库要隔离。服务端5月30日 20:38
Vercel 自定义域名和 SSL 怎么配置才不踩坑？在 Vercel 配自定义域名，流程是进入项目 Settings 的 Domains，添加根域名或子域名，再按提示到 DNS 服务商添加记录。根域名通常指向 Vercel 的 A 记录，www、blog、app 这类子域名一般用 CNAME 指向 `cname.vercel-dns.com`。DNS 生效后，Vercel 会自动签发和续期 SSL 证书。
## 追问
### 根域名和 www 怎么选？
两者都可以，但要选一个主域名，另一个做 301 跳转，避免搜索引擎看到重复页面。
### SSL 一直 Pending 怎么排查？
先检查 DNS 记录是否和 Vercel 提示一致，再看是否有 CAA 记录阻止证书机构签发。Cloudflare 还要确认代理和 SSL 模式。
### Cloudflare 能和 Vercel 一起用吗？
可以，但不要两边都做过多缓存和重写。常见做法是 Cloudflare 管 DNS 和安全策略，应用部署交给 Vercel。
### 上线前最容易漏什么？
常漏 301 跳转、旧 URL、Cookie Domain、OAuth 回调地址和搜索控制台验证。域名切换前逐项检查。服务端5月30日 20:38
Vercel Serverless Functions 适合什么场景，有哪些限制？Vercel Serverless Functions 适合把轻量后端逻辑放在前端项目旁边，例如表单提交、Webhook、登录回调、BFF 聚合接口、简单数据库读写。它不用维护服务器，随部署一起发布，流量低时几乎没有空转成本，流量上来时平台自动扩缩容。
## 追问
### Serverless 和 Edge Functions 有什么区别？
Serverless 更接近普通 Node.js 后端，生态兼容更好；Edge 更靠近用户、延迟低，但运行时 API 更受限。
### 冷启动会不会影响线上接口？
低频接口可能遇到冷启动。可以通过减少依赖体积、拆分函数、选择区域和缓存结果降低影响。
### 数据库连接为什么容易出问题？
Serverless 会并发创建函数实例，如果每个实例都新建连接，数据库连接数很快被打满。常见做法是连接池代理或 serverless 友好数据库。
### 哪些任务不该放进去？
视频处理、批量爬取、长轮询、定时大批量同步和复杂报表生成不合适，应放到队列或 worker。服务端5月30日 20:38
Vercel 定价怎么选，Hobby 和 Pro 什么时候够用？Vercel 定价的关键不是先看月费，而是看项目是否商业化、团队人数和资源用量。Hobby 适合个人项目、学习 Demo、开源展示站；Pro 适合客户项目、SaaS 官网、内容站和需要预览协作的团队；Enterprise 解决合规、SLA、组织权限、专属支持和复杂安全要求。
## 追问
### Hobby 计划可以放商业项目吗？
不建议。只要涉及客户交付、公司官网、付费产品或团队协作，就应该按 Pro 或 Enterprise 评估。
### Pro 最容易超的是哪几项？
常见是带宽、构建分钟、函数执行时长和图片优化次数。营销活动页或媒体站尤其要关注带宽。
### 什么时候需要 Enterprise？
需要 SAML/SSO、审计、SLA、合规采购、专属支持或更细组织权限时，Enterprise 才有明显价值。
### 如何控制成本？
静态资源尽量走 CDN 缓存，接口避免每次都走 Serverless；检查构建缓存、图片尺寸、ISR revalidate 和无效预览部署。服务端5月30日 20:38
Vercel 日志和错误排查应该怎么看？Vercel 的错误排查可以按三类看：构建错误看 Build Logs，接口和 Serverless Function 问题看 Runtime Logs，线上体验和性能问题看 Analytics、Speed Insights 或第三方监控。高效做法不是等报错后翻日志，而是在部署、运行时、告警和错误追踪之间建立完整链路。
## 追问
### Build Logs 和 Function Logs 有什么区别？
Build Logs 记录部署生成过程，适合查依赖、构建命令、类型错误和环境变量缺失。Function Logs 记录线上函数执行，适合查接口报错、超时和数据库连接。
### 为什么本地正常，Vercel 上失败？
最常见是 Node.js 版本不同、环境变量没配、大小写路径在本地不敏感但线上敏感。也可能是 Vercel 运行环境访问不到内网数据库。
### 日志里应该打印哪些信息？
打印请求 ID、接口名、耗时、状态、关键业务 ID 和错误 message。不要打印完整请求体、密钥、cookie、手机号等敏感数据。
### 函数超时怎么排查？
先看外部 API 慢、数据库查询慢，还是代码做了重计算。Vercel Functions 不适合长任务，必要时拆到队列或 worker。
## 写段代码
```js
try { return Response.json(await loadData()); }
catch (err) { console.error('loadData failed', { message: err.message }); return Response.json({ error: 'Internal error' }, { status: 500 }); }
```服务端5月30日 20:38
Vercel、Netlify 和 AWS Amplify 该怎么选？Vercel、Netlify 和 AWS Amplify 都能部署前端应用，但解决的问题不完全一样。Vercel 更适合 Next.js 和重视预览体验的团队；Netlify 更适合静态站点、多框架项目和表单类需求；AWS Amplify 更适合已经在 AWS 生态里、需要认证、存储、数据库一起管理的全栈项目。
## 追问
### Vercel 一定比 Netlify 快吗？
不一定。Next.js 项目在 Vercel 上通常更省心；普通静态站点放 Netlify 也可以很快。性能更多来自框架、缓存、图片处理和访问分布。
### 为什么说 Vercel 有平台锁定风险？
如果大量使用 Edge Middleware、ISR、图片优化和项目配置，迁移时要逐项找替代。锁定不是不能用，而是要知道哪些是平台能力。
### AWS Amplify 为什么成本难预测？
它背后可能同时使用构建、存储、数据库、认证、流量、日志等多个 AWS 服务，流量变化后账单更难估算。
### 小团队怎么选？
Next.js 先选 Vercel；官网、博客、文档选 Netlify；除非团队熟悉 AWS 或后端明确要用 AWS，否则不建议一开始上 Amplify。
### 迁移平台注意什么？
先列出环境变量、函数、边缘逻辑、图片优化、表单、认证和 DNS 依赖，灰度验证后再切全量流量。服务端5月30日 20:38
Vercel 多环境部署怎么配置才不容易出错？Vercel 做多环境部署，核心不是多建几个分支，而是把 Production、Preview、Development 的触发方式、环境变量和数据资源隔离清楚。main 对应生产，Pull Request 和功能分支对应 Preview，本地通过 `vercel dev` 对应 Development。这样团队能在合并前拿到真实预览地址，又不会让测试请求误连生产数据库。
## 追问
### 为什么不能只用一个 `.env` 文件？
一个文件短期省事，长期容易把测试密钥、生产数据库和本地回调混在一起。支付、登录、推送这类功能尤其危险。
### `NODE_ENV` 和 `VERCEL_ENV` 有什么区别？
`NODE_ENV` 更偏构建模式，Preview 也常是 production。`VERCEL_ENV` 才表示 production、preview 或 development，更适合环境路由。
### Preview 环境需要独立数据库吗？
只看静态页面可以不要；涉及登录、写入、回调或迁移时建议隔离。最低成本是测试库加命名空间，更稳是每个 PR 临时 schema。
### 多环境最常见的坑是什么？
变量改完不重新部署、Preview 误用生产 API、回调地址只配生产域名。排查时先看 Deployment Environment。
## 写段代码
```js
const apiBase = { production: process.env.API_URL, preview: process.env.PREVIEW_API_URL, development: 'http://localhost:3001' }[process.env.VERCEL_ENV || 'development'];
```服务端5月27日 21:53
如何优化 Vercel 应用的性能？核心答案：Vercel 应用的性能优化可以从四个维度入手——渲染策略选择、构建产物瘦身、缓存配置、以及 Edge 能力利用。
## 渲染策略：选对模式比什么都重要
Vercel 上最影响性能的决策是渲染方式。SSG（静态生成）最快，ISR 兼顾更新和速度，SSR 只在需要实时数据时使用。大多数页面应该优先 SSG + ISR：
```js
export async function getStaticProps() {
const data = await fetchData();
return { props: { data }, revalidate: 60 }; // ISR: 60秒后台重新生成
}
```
Next.js App Router 默认就是 Server Component，不要滥用 `'use client'`，每个客户端组件都会增加 JS 体积。
## 构建优化：砍掉不必要的 JS
**动态导入**：非首屏组件用 `dynamic()` 按需加载。
```js
const Chart = dynamic(() => import('./Chart'), { ssr: false });
```
**Tree Shaking**：用 `import { debounce } from 'lodash'` 而非 `import _ from 'lodash'`。用 `@next/bundle-analyzer` 定位大包。
**图片和字体**：`next/image` 自动输出 WebP/AVIF 并按设备尺寸裁剪；`next/font` 消除字体布局偏移（CLS）。
## 缓存：Vercel 上最容易被忽视的杠杆
在 `vercel.json` 中配置 Cache-Control 头：
```json
{
"headers": [{
"source": "/static/:path*",
"headers": [{ "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }]
}]
}
```
客户端用 SWR 做请求去重和后台刷新；服务端用 `@vercel/kv` 缓存计算结果。Vercel 默认对 HTML 响应设置 `max-age=0, must-revalidate`，静态资源则自动长期缓存。
## Edge Runtime：把计算推到离用户最近的地方
Edge Function 冷启动在毫秒级，适合认证、重定向、A/B 测试等轻量逻辑：
```js
export const runtime = 'edge';
export default function handler(req) {
return new Response('Hello from Edge');
}
```
Edge Middleware 可以在请求到达源站之前拦截，做地理路由或权限校验，减少回源延迟。但注意 Edge 环境不支持 Node.js API，Prisma 等库无法直接使用。
## 数据库连接：别让连接池成为瓶颈
Serverless 环境下每次请求可能创建新的数据库连接。用全局单例复用 Prisma Client：
```js
const globalForPrisma = globalThis;
export const prisma = globalForPrisma.prisma ?? new PrismaClient();
if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma;
```
高并发场景考虑连接池服务（如 Vercel Postgres 自带的 pgBouncer）。
---
**追问方向**：ISR 的 revalidate 时间怎么定？Edge Runtime 和 Serverless Function 的选型边界在哪？Vercel Analytics 的 Web Vitals 指标（LCP/FID/CLS）分别对应哪些优化手段？Fluid Compute 如何缓解冷启动？服务端5月27日 21:46
Vercel 的部署流程是怎样的？## Vercel 的部署流程是怎样的？
核心流程分五步：**代码拉取 → 依赖安装 → 构建 → 上传分发 → 域名配置**。最常用的是 Git 集成部署——推送代码到主分支触发生产部署，推送到其他分支或创建 PR 触发预览部署。
### 部署触发方式
**Git 集成（推荐）**：连接 GitHub / GitLab / Bitbucket 仓库后，代码推送自动触发构建和部署。首次需在 Dashboard 导入仓库、配置构建设置（框架和命令通常自动检测），点击 Deploy 完成。
**CLI 手动部署**：
```bash
npm i -g vercel
vercel login
vercel # 预览环境
vercel --prod # 生产环境
```
**API 部署**：通过 `@vercel/client` 的 `createDeployment` 实现程序化部署，适合 CI/CD 集成场景。
### 五个阶段详解
1. **代码拉取**：从 Git 仓库拉取最新代码，检查 `.gitignore` 排除无关文件，解析依赖关系
2. **依赖安装**：自动检测包管理器（npm / yarn / pnpm），执行安装，`node_modules` 会被缓存加速后续构建
3. **构建**：执行构建命令（默认 `npm run build`，可在 `vercel.json` 自定义），自动检测框架并应用优化（如 Next.js 的代码分割、静态生成），生成 HTML/CSS/JS 等静态资源
4. **部署上传**：构建产物上传至边缘网络，CDN 分发到全球节点，配置缓存策略
5. **域名配置**：自动签发并续期 SSL 证书（Let'''s Encrypt），配置 DNS 解析，支持自定义域名绑定
### 预览部署 vs 生产部署
| 维度 | 预览部署 | 生产部署 |
|------|---------|---------|
| 触发条件 | PR 或非主分支推送 | 主分支合并 / `vercel --prod` |
| URL 格式 | `project-branch.vercel.app` | `project.vercel.app` 或自定义域名 |
| 环境变量 | 使用 Preview 环境 | 使用 Production 环境 |
预览部署为每个 PR 生成独立 URL，适合代码审查和功能测试；生产部署使用更严格的构建检查。
### 常见追问
**Vercel 如何加速构建？** 三种机制：`node_modules` 缓存复用、增量构建（仅重建变更页面，复用未变更产物）、并行构建多项目。对于 Next.js 项目还支持 ISR（增量静态再生成），避免全量重建。
**部署失败常见原因？** 依赖版本冲突、环境变量缺失、构建命令错误、Serverless 函数内存不足。排查方式：查看构建日志定位失败步骤，确认 `package.json` 依赖版本一致，验证环境变量配置完整。
**部署后页面 404？** 检查 `outputDirectory` 配置是否与实际构建产物目录一致（如 Vite 默认 `dist`，Next.js 默认 `.next`），确认路由重写规则正确。
**如何区分环境变量？** Vercel 支持 Development / Preview / Production 三套独立环境变量，在项目 Settings → Environment Variables 中分别配置，CLI 通过 `vercel env pull` 拉取对应环境配置。
**`vercel.json` 常用配置项？** 可自定义 `buildCommand`、`outputDirectory`、`framework`、路由重写规则（`rewrites`）、重定向（`redirects`）和缓存头（`headers`）。服务端5月27日 21:46
Vercel 的 Edge Functions 和 Serverless Functions 有什么区别？## 核心区别
Edge Functions 运行在全球边缘节点的 V8 隔离实例上，冷启动 <50ms；Serverless Functions 运行在中心化服务器的 Node.js 运行时中，冷启动 500ms-3s。本质区别是**运行时环境**和**部署位置**：Edge 用轻量 V8 Runtime 换取极低延迟，Serverless 用完整 Node.js 换取功能全面。
## 关键参数对比
| 维度 | Edge Functions | Serverless Functions |
|------|---------------|---------------------|
| 运行时 | Edge Runtime (V8) | Node.js |
| 冷启动 | <50ms | 500ms-3s |
| 执行时限 | 30s (Pro) | 60s (Pro)，企业版可达 900s |
| 内存 | 128 MB | 最高 3008 MB |
| 请求体大小 | 1 MB | 4.5 MB |
| 部署包 | <1 MB | 50 MB 压缩（解压 250 MB）|
| 文件系统 | 不支持 | 只读访问 |
| Node.js API | 受限（无 fs/child_process）| 完整支持 |
| 数据库连接 | 不支持连接池，需 HTTP 驱动 | 支持 Prisma/ORM 连接池 |
| 部署位置 | 全球边缘节点自动就近 | 指定区域 |
## Edge Functions 适用场景
路由重写、A/B 测试、地理路由、认证鉴权、缓存控制——特点是逻辑轻、响应要求快：
```javascript
// middleware.js
import { NextResponse } from "next/server";
export const runtime = "edge";
export function middleware(request) {
const token = request.cookies.get("auth-token");
if (!token) {
return NextResponse.redirect(new URL("/login", request.url));
}
// 地理路由
if (request.geo?.country === "CN") {
return NextResponse.rewrite(new URL("/zh", request.url));
}
return NextResponse.next();
}
```
## Serverless Functions 适用场景
复杂业务逻辑、数据库操作、文件处理、长时间计算——需要完整 Node.js 生态：
```javascript
// pages/api/data.js
import { PrismaClient } from "@prisma/client";
const prisma = new PrismaClient();
export default async function handler(req, res) {
const users = await prisma.user.findMany({
include: { posts: true },
});
res.status(200).json({ users });
}
export const config = {
maxDuration: 30,
memory: 2048,
};
```
## 混合使用：Edge 挡在前面
实际项目中常用 Edge 做认证和路由，请求通过后再交给 Serverless 处理业务。这样既利用了 Edge 的低延迟拦截，又不丢失 Serverless 的完整功能。
## 面试追问
- **Edge Runtime 具体不支持哪些 API？** `fs`、`child_process`、`crypto.createCipheriv`（仅支持 Web Crypto）、`net`/`tls` 模块均不可用；`fetch`、`Request`、`Response`、`URL` 等 Web API 完整可用。
- **Prisma 能在 Edge 上跑吗？** Prisma Accelerate（HTTP 驱动）可以，但传统 Prisma Client（TCP 连接池）不行。同理，需 TCP 连接的数据库驱动都无法在 Edge 使用。
- **Edge 的 128MB 内存够用吗？** 路由/认证/缓存场景足够，但不要在 Edge 中做 JSON 大对象解析或图片处理，超出会 OOM。服务端5月27日 21:43
如何在 Vercel 上实现 CI/CD 流程？## Vercel CI/CD 的核心机制是什么？
Vercel 采用 Git-push-to-deploy 模型——推送代码即触发构建和部署，无需手动配置流水线。它支持 GitHub、GitLab、Bitbucket 三种 Git 提供商，部署触发条件包括：推送代码到分支、创建/合并 Pull Request、推送标签。
三种部署环境各有分工：Production 对应主域名，使用生产环境变量；Preview 为每个分支或 PR 生成唯一 URL，方便团队评审；Development 用于本地开发，通过 Vercel CLI 访问。
## 如何配置 Vercel 的自动部署？
在 Vercel Dashboard 中 Import Git Repository，授权后选择仓库并配置构建设置即可。vercel.json 中可自定义 buildCommand、outputDirectory、installCommand 等字段。
环境变量按环境隔离管理：在 Dashboard 的 Settings > Environment Variables 中添加，或用 vercel env add API_KEY production 通过 CLI 设置。代码中通过 process.env.API_KEY 访问。
关键点：环境变量区分 Production、Preview、Development 三种作用域，部署时自动注入对应环境的变量。
## Vercel 如何实现零停机部署？
Vercel 的零停机部署依赖两个核心机制：
Skew Protection（倾斜保护）：新版本部署上线后，旧版本的客户端请求仍能正确路由到对应的服务端资源，避免因客户端缓存导致的版本不匹配错误。
原子切换：Vercel 不是逐步替换实例，而是在新构建完成后一次性切换流量。旧部署保持可用直到所有活跃请求完成，确保没有请求被中断。
回滚也很快：vercel rollback 或在 Dashboard 中一键回退到任意历史部署。
## Preview 部署在团队协作中有什么价值？
每个 PR 自动生成一个独立的预览 URL，评审者可以直接在浏览器中查看变更效果，无需本地拉取代码。这意味着：
- 设计师和产品经理可以参与评审，不依赖开发环境
- 多个 PR 的预览环境互相隔离，不会相互干扰
- 预览部署使用 Preview 环境变量，可以连接测试数据库等独立资源
在 vercel.json 中可以控制哪些分支触发部署：git.deploymentEnabled 字段可以禁用特定分支模式的自动部署。
## 如何在 Vercel CI 中集成测试？
单元测试：在 package.json 的 postinstall 脚本中运行测试，或通过 buildCommand 前置测试命令。但注意构建超时限制，Hobby 计划最长 10 分钟，Pro 计划最长 45 分钟。
E2E 测试：用 Playwright 等工具对 Preview URL 运行集成测试。关键步骤是拿到预览部署的 URL 后再执行测试，而非测试本地开发服务器。
外部 CI 集成：在 GitHub Actions 中用 vercel build 在本地构建，再用 vercel deploy --prebuilt 部署已构建产物。这种方式把测试、Lint 等步骤放在 Vercel 构建之外，避免构建超时。
## Vercel 的构建缓存如何工作？
Vercel 自动缓存 node_modules 和构建产物。对于 Next.js 项目，增量静态再生（ISR）在构建时只重新生成变化的页面，而非全站重建。
在 Monorepo 场景下，Turborepo 的远程缓存可以跨团队成员和 CI 运行共享构建产物——未修改的包直接复用缓存，跳过重新构建。这能把 CI 时间从分钟级降到秒级。
配置方式：在 vercel.json 的 build.env 中设置缓存 key，或通过 Turborepo 的 turbo.json 配置缓存策略。
## 面试追问：持续交付和持续部署有什么区别？
持续交付（Continuous Delivery）要求所有变更通过自动化测试，但部署到生产环境需要手动审批。持续部署（Continuous Deployment）则完全移除手动环节，通过所有检查的代码直接上线。
在 Vercel 上，默认行为接近持续部署——合并到主分支自动部署到 Production。如果需要审批环节，可以用 Vercel 的 Deployment Protection 或在 Git 侧配置分支保护规则，要求 PR 审批后才能合并。
## 面试追问：如何处理部署失败？
首先通过 vercel logs deployment-url 查看部署日志定位原因。常见失败原因包括：依赖版本冲突、环境变量缺失、构建超时。
处理流程：立即回滚到上一个稳定部署，然后在 Preview 环境中修复问题，验证通过后再合并。Vercel 的部署历史完整保留，任意历史版本都可以一键回滚。