Vercel暗坑深度解析：免费额度、域名绑定与构建部署避坑指南

收到，这个标题本身就很有意思——"Vercel暗坑 二"，说明这不是第一篇了。作为常年用Vercel部署个人项目和公司前端应用的人，看到这个标题就很有共鸣。Vercel确实是目前体验最顺滑的部署平台，但对于国内开发者，尤其是从"绑定国内域名"、"免费账号"这两个提问最多的话题切入，里面藏着大量官方文档不会写清楚、又很容易让人卡住半天甚至几天的细节。这篇就当作系列的续篇，把我在生产环境、个人项目里真实踩过的坑和排查过程完整拆开讲。

1. 免费账号不等于"随便用"，额度上限的真相要先摸清

1.1 免费版配额的官方数字与真实边界

Vercel的Hobby（免费）套餐对很多人来说是入坑的第一站，但"免费"两个字让不少人误以为没有上限。实际上，Hobby套餐的隐形天花板很明确，大致的配额如下：

注意，这里给出的数字是我实际使用中反复核对的官方标准，但Vercel的条款时不时调整，最严谨的做法还是去官方Pricing页面确认最新值。我之所以把"免费额度"列为第一个暗坑，是因为很多人的认知是"免费=无限"，而实际上，一个访问量稍微大一点的内容型项目，100GB带宽在被爬虫或恶意请求扫到的时候，几天就能烧干净。

我自己遇到过最典型的一次：一个以图片为主的博客项目，单张图片平均500KB，单次页面访问加载40张图，就是20MB。假设一天有200个真实访问者，就是4GB，一个月120GB，直接超限。更难受的是，Vercel超限后的表现不是降速，而是直接把站点停掉并展示Vercel的错误页，用户看到的就是"网站打不开"，非常被动。

1.2 构建时长消耗最快的几个场景

免费版100分钟构建时长，看着好像够用，但如果你用的是Next.js这类框架，情况完全不一样。每次push到GitHub触发生产构建，一个中等复杂度的Next.js项目，冷构建时间在2-5分钟左右。如果你一天提交10次，光构建就吃掉30-50分钟。再加上Preview环境每次PR也会触发独立构建，100分钟的额度在活跃开发期最多撑3-5天。

这里有一个实操建议：如果你的项目没有"每次提交都自动部署Preview"的强烈需求，可以去Vercel项目设置的 Git 选项卡里，只保留生产分支（比如main）的自动部署，把其他分支的自动部署关掉。这样做之后，我个人的构建时长消耗直接下降了60%以上。另外一个冷知识：Vercel的构建时长是每月1号重置的，如果你发现某个月超限了，冷静等待下个月自动恢复即可，不必急着升级付费。

1.3 免费账号的协作与安全限制

网上很多教程在推荐Vercel时，只说"免费、方便、自动部署"，很少提到团队协作的限制。Hobby版在Git集成上虽然支持GitHub/GitLab/Bitbucket，但有一些隐含限制：没有团队成员精细权限管理，所有能访问你Vercel账号的人都能操作项目；Preview部署并发数量有限，人多的时候构建会排队。如果你跟朋友合作一个项目，建议用专门的Vercel账号给项目，不要直接在主账号下添加协作者，否则很容易出现误操作删除环境变量、覆盖生产环境的情况。

2. 绑定国内域名，最容易翻车的4个细节

2.1 根域名A记录与www子域名CNAME的经典冲突

热搜词里"vercel绑定国内域名"出现频率极高，因为这里面的坑实在太多。以阿里云、腾讯云这类国内注册商为例，当你在Vercel的Domains面板添加域名时，它会给出一组DNS配置建议：

• 根域名（example.com）：设置A记录，指向 76.76.21.21（Vercel的任一可用IP）
• www子域名（www.example.com）：设置CNAME记录，指向 cname.vercel-dns.com

问题在于，很多新手只记住了"要配置CNAME"，却在根域名上直接配置CNAME。按照DNS标准，根域名（APEX域）不允许配置CNAME记录，因为根域必须包含其他必要的DNS记录（如NS、SOA等），CNAME会与之冲突。阿里云DNS面板也会明确提示不能这样配置，但依然有人选择强行添加，最后的结果就是域名解析异常，Vercel那边始终显示"Domain is not configured correctly"。

正确做法是优先按照Vercel面板的"推荐配置"来，面板显示要A记录就用A记录。如果你一定要给根域名配置CNAME（比如想通过某些DNS服务商的CNAME Flattening功能），那需要先确保你的DNS服务商支持这种"根域名CNAME展开"能力，国内不少服务商是不支持的，与其折腾，不如直接按A记录走。

2.2 TXT验证记录不生效的排查思路

在Vercel添加域名的流程中，有时候会要求你新增一条TXT记录来验证域名所有权。这个环节看起来简单，但国内开发者在这里卡住的比例相当高。常见的失败场景包括：

• 复制TXT记录值时，把前后空格也复制了进去，导致DNS记录内容有误
• Vercel要求填写的主机记录是 @ 或 _vercel，而在国内DNS服务商的面板上，根域名的填写方式可能是留空、使用 @ 或者使用 example.com，每个服务商的约定不同
• DNS服务商对TXT记录有缓存，短时间反复修改后，查询到的是旧值

排查TXT记录是否生效，不要只看Vercel面板，更稳妥的方式是在本地终端用 dig 命令查：

bash复制# 以 example.com 为例，查询TXT记录
dig TXT example.com +short

# 查询指定前缀的记录
dig TXT _vercel.example.com +short

如果 dig 查询已经返回了正确的TXT值，但Vercel依然提示验证失败，大概率是你在Vercel面板填写的域名格式有问题，尝试把 www.example.com 改成 example.com，或者反过来。这个问题在处理了三次之后我才真正摸透，关键点在于：Vercel的验证请求是针对"你添加的那个域名"的，不是你"心里认为的域名"。

2.3 国内DNS服务商的解析生效时间差异

当你完成了A记录或CNAME配置后，接下来面对的就是"解析生效时间"这个玄学问题。国外大厂DNS（比如Cloudflare）通常秒级生效，但国内阿里云、腾讯云、甚至一些更小众的注册商自带DNS，解析在全国范围内的完全生效可能需要几十分钟到几小时。这不是Vercel的问题，是国内DNS基础设施的天然差异。

所以，当你配置完DNS后，不要急着去Vercel面板点"Refresh"，更不要反复改动NS记录。我的经验是：配置完成后，先等20分钟，再用本地 dig 命令确认本地DNS能看到新记录，接着用在线工具（比如国内的ITDOG）去全国多个节点查询解析结果。如果所有节点都已经返回正确IP，Vercel面板一般会在几分钟内自动刷新。

2.4 域名过期与SSL证书自动续期的隐性联动

这是一个非常隐蔽的坑。Vercel使用的SSL证书是Let's Encrypt自动签发和续期的，自动续期的前提是域名解析正常可达。假如你的域名因为忘记续费或者其他原因，在一段时间内解析中断，Vercel自动续期就会失败。等域名恢复访问后，你会惊讶地发现：HTTPS证书还是过期的，而且Vercel不会立刻自动重新签发。

这时候不需要发工单，自己就能解决：进入Vercel项目下的Domains页面，把出问题的域名删掉，再重新添加，Vercel会触发一次重新部署和SSL证书签发流程，几分钟后证书就会恢复。这个操作会短暂导致域名无法访问，但通常控制在1-2分钟内，整体影响是可接受的。

3. 部署与构建阶段的隐藏坑，本地跑通不代表线上能过

3.1 项目大小限制与文件数量陷阱

Vercel对部署的单个文件大小有硬性限制，虽然没有在首页显著位置标注，但构建失败日志里会出现类似"File size exceeds limit"的提示。我遇到的一个具体情况是：项目里放了一个十几MB的PDF演示文件，本地一切正常，push到Vercel后构建直接失败。排查半天才发现是文件大小超限。

另一个容易被忽略的是文件数量。如果你的项目包含密密麻麻的小图标、小图片，文件数量多到一定程度后，Git仓库会变大，Vercel构建时的文件遍历和上传耗时都会显著增加。解决办法很简单：把大型静态资源迁移到对象存储（比如国内云厂商的OSS）或者第三方图床，项目里只保留优化后的缩略图，既加快构建速度，也节省带宽。

3.2 环境变量分环境配置，别只设一个Production

Vercel的环境变量是区分Production（生产）、Preview（预览）、Development（开发）三种环境的。很多新手只设置了Production的环境变量，导致GitHub提交PR触发Preview构建时，构建脚本因为缺失环境变量直接失败。

这类问题的排查很直观：去Vercel项目设置的Environment Variables页面，检查三种环境是否都勾选了需要的变量。如果某个变量只在某些环境需要，可以在勾选时分别控制。我个人习惯是：核心变量三个环境全开，敏感变量只在Production开放，预览环境使用单独的测试Key。这样既安全又不会因为漏配而构建失败。

3.3 大小写敏感的文件系统差异

Windows本地开发的文件系统默认大小写不敏感，macOS默认也不敏感（除非主动设置），但Vercel的构建环境是Linux，文件系统大小写敏感。这意味着你在Windows上开发时，import HomePage from './HomePage' 和 import HomePage from './homepage' 都能跑，但推到Vercel之后，路径大小写不匹配就会直接构建失败。

这类问题我在帮助朋友排查时见过太多次，错误信息往往就是 Module not found: Can't resolve './xxx'。解决思路：先在本地把项目里所有import路径统一成与实际文件名完全一致的大小写，本地验证后再推送。更保险的方式是在Windows上开启Git的core.ignorecase设置为false（git config core.ignorecase false），这样Git能在提交前提示大小写差异。

3.4 框架预设与自定义构建命令的冲突

Vercel有很强的框架自动检测能力，能识别Next.js、Nuxt、Vite等项目并自动配置构建命令。但如果你在项目中同时包含了多个框架的特征文件（比如根目录同时有 next.config.js 和 vite.config.js），Vercel的自动检测可能会选错预设，导致构建失败或者产物异常。

解决办法是：在项目根目录的 vercel.json 里手动声明框架预设。例如：

json复制{
  "framework": "nextjs"
}

或者对于纯静态项目：

json复制{
  "framework": null,
  "buildCommand": "npm run build",
  "outputDirectory": "dist"
}

明确指定构建命令和输出目录后，Vercel就不会再靠猜，大幅减少"本地正常、线上诡异"的问题。

4. 访问体验与静态资源，部署成功只是开始

4.1 国内访问速度的真实体感

Vercel的边缘网络很强，全球有多个节点，但国内访问的延迟表现并不稳定。这里的"不稳定"指的是：不同地区、不同运营商（电信、联通、移动）的路径质量差异很大，有人打开是秒开，有人要转圈好几秒。这属于网络基础设施层面的客观差异，不是Vercel本身出了问题。

对国内用户来说，如果站点访客主要在国内，直接把Vercel域名暴露给用户并不理想。一个相对稳妥的做法是：把访客流量用一层国内访问更顺畅的CDN或反代接住，回源到Vercel。至于具体怎么选、怎么配，需要结合自己的业务和成本考量。这里不展开任何灰色手段，只是从一个前端开发者的视角说：能通过正规CDN和解析优化解决的，优先用正规方案。

4.2 Next.js图片优化功能在免费套餐下的代价

Next.js自带的 next/image 组件非常方便，会自动做图片压缩、格式转换和CDN缓存。但这个动态优化能力是消耗Serverless函数计算资源的。在Hobby免费套餐下，如果图片请求量大，这部分资源很快会被吃掉。

我的实操建议是：如果站点图片数量大、访问量有增长趋势，可以关闭Next.js的动态图片优化，改为构建时静态压缩图片（用sharp等工具），或者直接把图片托管到专业的图床/CDN服务。这样虽然多了一步构建期的图片处理，但线上请求不会再消耗函数计算额度，访问速度反而更稳定。

另外，Vercel的缓存有时候很"顽固"。你更新了JS/CSS文件，但用户浏览器还是拿到旧版本。这多半是浏览器缓存或边缘缓存未正确失效。解决办法是：在构建时给静态资源文件名加上hash（Vercel对Next.js默认会做），并在 vercel.json 中配置合理的缓存头。

json复制{
  "headers": [
    {
      "source": "/assets/(.*)",
      "headers": [
        {
          "key": "Cache-Control",
          "value": "public, max-age=31536000, immutable"
        }
      ]
    }
  ]
}

4.3 强制HTTPS与301跳转的死循环

Vercel默认会给绑定域名自动签发SSL证书，并支持强制HTTPS。但如果你的项目里同时配置了自定义重定向规则（比如把所有非www域名跳转到www），而DNS记录又没配对好，可能会出现301跳转死循环：用户访问 http://example.com，先被Vercel重定向到 https://example.com，然后又被你的业务逻辑重定向到 http://www.example.com，最后又回到 https://www.example.com。整个链路如果某一环配置冲突，浏览器就会报"重定向次数过多"。

排查这类问题，打开浏览器开发者工具的Network面板，查看请求的完整跳转链路，很快就能定位是哪一步在反复循环。通常的解决办法是：在域名解析和Vercel重定向设置中统一最终目标域名的格式，不要在Vercel面板和业务代码里同时设置两套跳转逻辑。

5. 高频问题的排查实录与恢复流程

5.1 一次典型的域名"Invalid Configuration"排查案例

有次帮一个朋友排查，他在阿里云绑定 blog.example.com 到Vercel项目，Vercel面板一直显示Invalid Configuration。我按顺序执行了这么几步：

1. 打开Vercel项目Domains页面，查看它要求的DNS记录类型和目标值，确认需要的是CNAME记录指向 cname.vercel-dns.com。
2. 登录阿里云DNS解析面板，确认 blog 这个主机记录已经添加了CNAME，目标值没有多余空格。
3. 在本地终端执行 dig blog.example.com CNAME +short，发现返回为空。
4. 换一台设备、换一个网络环境再查，发现依然为空，说明是DNS服务商一侧还没生效或配置有误。
5. 最终发现是阿里云面板上那个主机记录里，他填成了 blog.example.com，但实际上应该只填前缀 blog，导致记录完全错配。

这个问题并不高深，但足以说明一个道理：Vercel面板提示的内容，必须严格按照它的要求一字不差地去DNS服务商那边配置，少一个点、多一个后缀，都会导致失败。

5.2 带宽超限后的处理流程

当你发现访问站点时出现了Vercel的报错页面（看起来像"你当前访问的页面触发了配额限制"之类），先别慌，流程是：

1. 登录Vercel控制台，在项目设置的Usage页面确认当前周期的带宽消耗是否已经达到100%。
2. 确认流量是真实用户访问还是被机器人刷量。如果是被刷，优先检查是不是页面暴露了真实路径导致被人遍历下载资源。
3. 立即对静态资源做一次缓存优化，给图片、CSS、JS加上长缓存头，减少重复出站流量。
4. 如果业务紧急且预算允许，考虑升级到Pro套餐，换取更大的带宽配额。
5. 等下一个自然月周期重置，免费额度会自动恢复。

整个流程里，最忌讳的是什么都不查就盲目升级付费。先搞清楚流量来源，才能对症下药。

5.3 从Vercel迁移到其他平台前的检查清单

有些人因为各种原因（成本、访问速度、平台策略）决定把项目从Vercel迁走。迁移前，我建议对照这份清单逐项确认，避免漏掉关键配置：

迁移本身不难，难的是把所有隐性配置一个不落地搬过去。我自己吃过一次亏：迁站后忘了重配Security Headers，导致网站在安全扫描中丢了不少分。

6. 给新人的几条实用建议

如果你刚开始用Vercel，或正准备把个人项目部署上去，我从这几年的使用经验里提炼了几条特别值得记住的建议。

第一，项目根目录一定要建 vercel.json，哪怕里面一开始只有空配置。后续你迟早需要调整缓存头、重定向或者函数路由，有了这个文件，改动可以跟随代码走，而不是去控制台点来点去。

第二，不要在本地跑过一次 vercel dev 正常就以为万事大吉。Vercel的云端构建环境和本地差距不小，尤其是Node版本、系统依赖、文件权限这些细节。建议至少把 engines 字段写进 package.json，锁定Node大版本：

json复制{
  "engines": {
    "node": "20.x"
  }
}

第三，环境变量的管理要有纪律。不要把所有环境共用一套Key，更不要把敏感信息写进前端源码。Vercel提供的Serverless环境变量只对服务端代码可见，Next.js中只有以 NEXT_PUBLIC_ 开头的变量会暴露到浏览器，这两者一定要分清楚。

第四，遇到问题先去看部署日志。很多"诡异问题"在日志里其实写得明明白白，只是一看到红字就慌了。静下心来从第一条报错开始往后读，80%的问题能自己解决。

最后，也是我最想说的一点：Vercel是个很好用的平台，但它不是万能的。如果你做的站点目标受众绝大部分在国内，那么在选择技术栈时就要提前考虑部署位置、CDN回源、静态资源分布这些问题。提前想清楚这些，比等到线上出了问题再去查"为什么这么慢"要省心得多。用过一段时间之后你会发现，把部署平台的工作原理摸透，比单纯会点几个按钮，价值要大得多。希望这篇系列的第二篇能帮你少踩几个我踩过的坑。