我一直觉得静态网站部署这事儿被很多人想复杂了。早些年做个网页想上线给人看得买服务器、配环境、装Nginx折腾一晚上可能连个首页都打不开。现在情况完全变了只要你愿意折腾十分钟就能把站点挂到公网上还是HTTPS、全球CDN加速最关键的是——一分钱不花。这篇文章我就把这些年实测过的免费静态网站部署平台摊开来聊从平台选型、核心原理到部署实操、避坑经验一次说透。1. 静态网站部署这件事本质是什么1.1 为什么静态站也需要“部署”先说清楚“静态网站”是什么。一个网站如果它的页面内容在请求发出之前就已经是固定好的HTML、CSS、JavaScript文件用户访问时浏览器直接下载渲染不需要服务器现场拼装内容那它就是静态网站。典型代表就是个人博客、产品落地页、文档站点、作品集。很多人有个误解既然全是静态文件那是不是丢到任意一台有网的环境就能跑理论上确实是直接双击HTML也能打开。但这里有两个问题——一是你自己电脑不能24小时开着给别人访问二是“能被访问”和“访问得又快又稳”是两回事。静态网站部署平台解决的就是“托管文件 全球分发 自动化更新 安全访问”这一整套事。你只需要把代码推上去平台自动完成构建、分发、证书配置用户拿到的是一个稳定、快速、带锁的站点。1.2 部署平台到底在帮你做什么拿你手机上装App来类比。你没有从源码自己编译App而是去应用商店下载安装。商店帮你做好了签名、分发、更新、兼容性适配。静态部署平台就相当于网站界的“应用商店”不过它更狠连装都不用装直接把你的文件同步到全球各地的节点上。具体拆解一个合格的静态部署平台至少要干四件事第一文件托管。这是地基。你的HTML、CSS、JS、图片得有个地方存并且能被公网稳定访问。第二CDN加速。用户从北京访问文件最好从北京附近的机房出来而不是绕道美国。免费平台提供的全球CDN内容分发网络本质上就是把你网站的文件缓存到全球各地的边缘节点上谁访问离谁近就从谁那里拿。第三自动构建与持续部署。你本地改了代码git push推到远端平台自动拉取、安装依赖、执行构建命令、把产物发布到线上。整个链路全自动不需要你手动上传。第四HTTPS证书。现在浏览器对非HTTPS的站点极不友好平台方自动帮你申请和续期证书你什么都不用管。这四个能力决定了你部署一个静态站不是“把文件传上去”这么简单而是走一条全自动的生产流水线。2. 主流免费平台横评一次看清各自的底牌市面上的免费部署平台细数下来不少于十个但真正值得花时间去研究的其实就那么几个。我按“托管仓库型”和“专业部署型”分两类聊最后给一个对比表格方便存档。2.1 大厂托管型GitHub Pages 与 GitLab Pages先聊GitHub Pages这应该是绝大多数人的第一个静态网站托管平台。它的逻辑很简单你的代码仓库里要么放静态文件本身要么放源码GitHub在后台帮你构建然后把产物发布到一个统一域名下。免费用户就可以创建公开仓库的Pages站点URL格式一般是用户名.github.io/仓库名。GitHub Pages最大的优势有三点零成本、与代码仓库无缝集成、稳定性极强。毕竟是微软家的服务跑个人项目或小流量站点非常省心。缺点是它的构建能力偏基础不支持服务端逻辑带宽和构建次数也有限制而且国内访问速度有时候不稳定这一点后面会细说。GitLab Pages和GitHub Pages思路一致依托于GitLab仓库体系。它的特点是对私有仓库的Pages支持更宽松不过GitLab在国内的知名度、生态成熟度相比GitHub弱一些如果你本来不用GitLab写代码没必要专门为了部署功能迁过来。2.2 专业部署型Vercel、Netlify 与 Cloudflare Pages这三个是我目前主力使用的平台也是全球公认的静态部署“三驾马车”。Vercel前端圈子里几乎没人不知道。它的核心优势在于对前端框架的深度优化尤其是Next.js简直就是自家亲儿子。你甚至不需要写任何构建配置平台自动识别项目类型、自动安装依赖、自动执行构建命令。Vercel的全球边缘网络部署做得非常出色访问速度在海外节点表现优秀国内直连在部分地区时好时坏但配合自定义域名后整体可接受。Free套餐每月100GB带宽、100GB构建时长对个人项目完全够用。Netlify算是老牌选手功能和Vercel高度对齐但有两个独特的地方。一是它的“Netlify Forms”支持在纯静态站点上接收表单提交不需要写后端二是它较早实现了分支部署和回滚预览团队协作时体验很好。Netlify免费额度与Vercel相当构建次数限制每月300分钟。Cloudflare Pages如果你对“免费”二字比较敏感Cloudflare Pages会是最极致的答案。它提供无限带宽无限请求数全球网络节点数量最多国内访问速度在免费方案里算第一梯队。而且Cloudflare在安全防护和DNS解析上本身就是王牌你可以把域名解析、CDN加速、WAF防护、Pages托管全部放到同一个面板里管理。唯一的缺点是对复杂构建场景的支持稍弱冷启动构建偶尔较慢但以静态站场景来说问题不大。2.3 面向国内场景的选择与注意点国内访问速度是绕不开的问题。如果你主要目标访客在国内用境外平台Vercel、Netlify、Cloudflare Pages虽然能用但直连速度受网络环境影响较大哪怕加了CDN也不稳定。这时候有两条路。一条路是用国内平台。比如Gitee Pages在代码托管基础上提供Pages服务国内访问速度极快。但Gitee Pages的核心问题是审核与流程约束较多需要实名认证且审核周期不稳定适合能接受流程的开发者。另一条路是境外平台加国内CDN加速比如Cloudflare Pages绑定自定义域名后再接一层国内CDN或走优选网络但这是进阶玩法链路复杂度高不适合新手入门。2.4 平台横向对比速查表对比维度GitHub PagesVercelNetlifyCloudflare Pages免费额度100GB/月带宽100GB/月带宽100GB/月带宽无限带宽、无限请求构建能力基础强框架识别最优强扩展多中等国内访问速度一般一般一般相对较好自定义域名支持支持HTTPS支持支持HTTPS支持支持HTTPS支持支持HTTPS自动部署需借助Actions或手动推送仓库集成全自动仓库集成全自动仓库集成全自动特色功能与GitHub生态深度绑定Next.js优先优化Forms表单、分支部署无限量额度、同生态CDN与DNS适合场景个人博客、文档前端项目、Next.js应用团队协作、有表单需求高流量、追求免费额度最大化表格一出来就直观了。我的看法是新手入门首选GitHub Pages熟悉流程生产环境或个人项目我推荐Cloudflare Pages或Vercel二选一看哪个用着顺手。后面我分别把两条主流路线实操一遍。3. 实操从零部署一个静态博客到线上3.1 部署前需要准备什么提前把材料备齐整个流程会顺畅很多。你需要准备一个GitHub账号——如果你打算体验自动化部署GitHub和Gitee都是常见的选择本地装好GitWindows用户建议直接装Git for WindowsmacOS用户用Homebrew装就行一个已经写好的静态站项目。这里可以是一个Hugo/Hexo博客也可以用Vite/Vue/React构建出来的SPA应用甚至是一个只有一个index.html的纯静态页面。只要项目能在本地跑起来后面部署就成功了一半。如果你用的是静态站生成器比如Hexo、Hugo本地会有一个public或dist目录存放最终产物。如果你用的是Vue、React这类框架构建产物一般在dist目录。后文的构建命令配置会根据不同项目类型动态调整。3.2 方案一GitHub Pages 手动部署先走最简单的路。在GitHub上新建一个仓库Repository比如叫my-blog。然后在本地项目根目录执行Git初始化命令把代码推送到仓库git init git add . git commit -m feat: initial commit git branch -M main git remote add origin https://github.com/你的用户名/my-blog.git git push -u origin main接着到GitHub仓库页面点击Settings → Pages在Source区域中选择分支部署模式。选择main分支根目录保持默认/点击Save。等一分钟后你的站点就出现在https://你的用户名.github.io/my-blog上了。这个方案的局限很明显它部署的是你仓库里的源码不会自动执行构建。如果你用的是Hexo这类框架仓库里其实是未编译的Markdown文件用户直接访问拿到的不是最终页面。所以GitHub Pages有两种玩法一是把构建好的public目录内容直接推到仓库里二是借助GitHub Actions提交代码后自动构建并发布。第二种更符合现代工作流我们放到3.4节详细展开。3.3 方案二Vercel 绑定仓库一键部署Vercel的体验是我用过所有平台中“最顺手”的几乎没有之一。打开 vercel.com 用GitHub账号授权登录点击New Project选择你要部署的仓库Vercel会自动识别项目类型。如果是Vite项目它会自动识别出构建命令npm run build输出目录自动填上dist如果是Next.js项目构建命令和输出目录都会被自动预设好。你只需要点击Deploy然后等待一两分钟。部署完成后Vercel会分配一个项目名.vercel.app的域名同时自动帮你配好HTTPS证书。这里我特别想说一点Vercel对新手极其友好它把所有复杂配置都藏在了自动化识别后面你甚至不需要看到配置文件的加载过程就完成了部署。如果你是用框架开发的项目比如Vue或React本地目录下会有package.json文件。Vercel读到这个文件会自动执行依赖安装和构建。这种“傻瓜式”部署体验对新接触部署的人来说是最值得推荐的入门路径。3.4 进阶用 GitHub Actions 实现提交即部署手动推送构建产物的方式不够优雅每次改完还要在本地执行构建命令、复制文件、再推送。而GitHub Actions版本库配合GitHub Pages可以做到你只管写代码、推代码剩下的交给流水线。在仓库根目录下创建.github/workflows/deploy.yml文件写入以下内容name: Deploy to GitHub Pages on: push: branches: [main] workflow_dispatch: permissions: contents: read pages: write id-token: write jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv4 - name: Setup Node uses: actions/setup-nodev4 with: node-version: 20 - name: Install dependencies run: npm install - name: Build project run: npm run build - name: Setup Pages uses: actions/configure-pagesv4 - name: Upload artifact uses: actions/upload-pages-artifactv3 with: path: ./dist deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pagesv4这个配置的核心逻辑分两步build任务负责拉取代码、安装依赖、执行构建、把dist目录的内容打包成部署产物deploy任务把这个产物发布到GitHub Pages服务上。整个流程在你每次往main分支推送代码后自动触发。需要注意两个细节。第一到仓库Settings → Pages把“Source”改成“GitHub Actions”否则流水线没有部署权限。第二不同项目的构建产物目录不一样。Vite是distVuePress是src/.vuepress/distNext.js配合静态导出是out。如果你发现部署后页面是空的大概率就是这一步的路径没配对。3.5 绑定自定义域名并开启HTTPS用默认域名总显得有些不够专业尤其是做个人品牌你肯定希望URL里是自己的域名。以Cloudflare Pages为例说明一下购买域名后把域名的DNS解析托管到Cloudflare也就是让这个域名的DNS服务器指向Cloudflare提供的两个地址。然后在Cloudflare Pages项目设置里点击Custom Domains输入你的域名Cloudflare会自动校验所有权并完成指向配置。绑定之后HTTPS证书是自动生成和续期的不需要额外付费也不需要自己手动去证书平台申请。同一条配置流程在Vercel里叫Domains在Netlify里叫Custom domains本质都一样。这里有一个操作禁忌需要提醒如果你绑定的自定义域名同时在旧平台上也配置过CNAME解析DNS切换期间会出现一段时间“访问时而成功、时而失败”的现象这是全球DNS缓存同步的固有延迟别慌一般等几天就稳定了。域名解析配置这块如果放在Cloudflare Pages上操作隐含一个坑默认情况下Cloudflare会开启橙色云朵代理模式也就是域名流量会先经过Cloudflare的网络再回源到Pages。如果Pages项目绑定的域名和DNS代理配置相互冲突可能报错“Domain cannot be proxied”。出现这种情况时把橙色的云朵改成灰色仅DNS模式确保Pages服务正常获取到DNS记录即可。这点不熟悉的人真的容易卡半小时。4. 踩坑实录静态部署最常遇见的12个问题这几年帮不少人排查过部署问题清单越攒越长。很多问题不是代码写错了而是对平台机制理解不到位。整理成速查表放在这里方便大家直接对照排查。4.1 代码与构建层面的坑问题表现根因与对策部署后页面空白首页打开白屏控制台报404资源的绝对路径问题。默认仓库型站点部署在子目录时比如username.github.io/repo/资源地址如果写成/assets/index.js浏览器会去根目录找导致404。解决方法是把构建配置里的base或publicPath改成相对路径或仓库名路径SPA路由刷新404点击跳转正常刷新子页面就404单页应用的路由是前端控制的刷新时浏览器向服务器请求该路径服务器没有这个文件就返回404。需要在平台配置重写规则把未知路径全部重写到index.html。Vercel中配置rewriteNetlify中配置_redirects文件构建内存不足日志提示JavaScript heap out of memory大型项目在免费计划的小内存环境里构建容易爆内存。可以在构建命令前加NODE_OPTIONS--max-old-space-size1024限制内存或者把构建命令里的类型检查、lint审查拆出去减少峰值内存占用依赖版本不一致本地构建正常线上报错平台构建环境的Node版本与你本地不一致。需要在项目根目录加.nvmrc文件里面写20让平台使用对应版本或者使用package.json中的engines字段第2个问题出现频率最高。很多用React Router或Vue Router写H5项目的同学做完本地一切正常一部署上线点首页没事一刷新子路由就404。这是因为平台的服务器没有“未知路径回退到首页”的逻辑。Vercel的解决办法很简单在项目根目录新增vercel.json{ rewrites: [{ source: /(.*), destination: /index.html }] }Netlify更简单在public目录下新建一个名为_redirects的文件写入/* /index.html 200这套逻辑对于静态单页应用是标配建议提前配好别等部署完才发现。4.2 平台与网络层面的坑问题表现根因与对策国内访问一会儿快一会儿慢加CDN后依然波动明显境外平台的节点都在海外直连受跨境线路影响。如果是Cloudflare可以尝试切换优选节点或者配合国内云厂商的对象存储做双层加速免费额度被耗尽月中就收到带宽超限邮件免费套餐都有带宽上限Vercel和Netlify是100GB/月。如果你的站点图片多、流量大及时查看后台用量把图片压缩或迁移到对象存储可以减少带宽消耗股东存储用量超限网站图片全部裂掉这一点非常隐蔽。很多免费平台把文件托管和部署环境共用存储额度但对象存储计费是独立的。如果你直接在仓库里塞了几百张高清图片构建产物体积暴增的同时会产生额外费用。用图床或对象存储分离图片是更稳妥的方案平台账号被限制突然收到封禁邮件免费计划是平台为了获客给的福利长时间运行高消耗项目很容易触发风控。要注意不要用免费平台作为文件存储网盘不要传违法或侵权内容也不要跑类似爬虫或定时脚本这类生成大量请求的任务第1个问题很值得展开聊。很多人在国内访问GitHub Pages速度慢总怀疑是平台不行其实本质是网络链路问题。GitHub Pages默认没有中国大陆境内的CDN节点文件从美国直接过来延迟自然高。有一个相对划算的优化思路是GitHub Pages的仓库同时绑定多个平台比如Vercel和Cloudflare Pages各自拉取同一仓库然后通过域名解析做分流。不过这个方案对新手过于复杂我的建议是——如果访客以国内为主部署时就优先考虑Cloudflare Pages实测在绝大多数网络环境下比Vercel直连更稳。4.3 域名与HTTPS层面的坑问题表现根因与对策自定义域名访问提示不安全浏览器地址栏出现红色警告证书签发需要时间通常几分钟到几小时。等提示消失前不要反复删掉重新绑定域名否则证书签发会被反复重置www域名和根域名只能访问其中一个输入www能打开不带www打不开或反过来需要在DNS解析里同时配置根域名的A记录或ALIAS记录以及www的CNAME记录。平台会自动生成证书一般默认同时覆盖两种域名DNS解析生效慢绑定域名后一直打不开DNS记录在全球同步需要时间最快几分钟、最慢48小时。国内环境可尝试在终端执行nslookup 你的域名查看解析是否已生效不要频繁修改记录否则TTL刷新会重新计时切换平台后证书校验失败从A平台迁到B平台绑定后提示证书错误根域名指向新平台后老平台上的证书依赖已失效新平台的证书签发又需要时间。此时检查DNS记录是否已全部切换到新平台尤其注意是否有残留的旧CNAME指向A平台这里分享一个我个人的判断经验只要DNS配置正确证书生成失败的概率很低。遇到绑定后提示证书错误先别动平台等15分钟后刷新看看。如果还是失败再检查DNS解析记录里有没有旧平台的残留记录。多平台并行期间最忌讳反复改DNS因为每一次改动都会让证书验证周期被迫延长。5. 怎么选给不同场景的部署方案建议5.1 个人博客与作品集这类站点的特点是流量不大但需要稳定、可持续维护。如果你本身博客内容托管在GitHub上首选是GitHub Pages加自定义域名。它的优势在于零额外成本、静态托管能力完全够用而且部署和更新链条简单。如果你更看重部署的自动化和多地域加速尤其你的读者分布在海外那么用Vercel部署同一套仓库会是更舒爽的选择。两个平台可以同时跑互不冲突。我的博客就是双线路部署代码仓库一份同时推到GitHub Pages和Vercel再通过CDN智能分流。5.2 前端项目与演示用站点这是个高频场景你做了一份前端页面比如一个后台系统原型、一个小程序H5活动页想快速发给朋友或客户在线预览。过去可能打开本地服务、装内网穿透工具现在完全不需要。新建一个Vite或React项目推到GitHub接入Vercel或Netlify全程不超过10分钟。我对演示型项目的建议是用Vercel的Preview Deployment功能每次提交代码Vercel会根据分支名称自动生成一个独立的预览域名特别适合团队协作中给客户审查设计稿或功能效果。这一点在远程办公场景里完全是刚需。5.3 追求免费极致的高流量站点这里我要认真推荐Cloudflare Pages。如果你运气好哪天文章突然爆了流量瞬间冲到几十万上百万免费额度会不会被击穿用Vercel、Netlify大概率每月100GB的免费带宽撑不了那么久而Cloudflare Pages面对这种流量压力完全不虚。它的无限流量策略本身就是面向高流量场景设计的个人网站放在这里最省心。唯一的问题是需要你想办法解决国内访问速度的问题可以用优选节点配合CNAME方式缓解。5.4 对“免费”二字要有的清醒认知免费平台给你免掉的是基础设施成本但不代表没有代价。代价之一是服务不承诺可用性任何免费平台都可能因为策略变化随时调整额度甚至关闭服务。你能做的是让项目结构保持“可迁离”状态——仓库是Git管理的、构建配置是开源的、DNS在自己手里。哪天这个平台不能用了推到另一个平台也就半小时的事。代价之二是构建资源有限制免费套餐的构建次数和并行任务有限不要在同一平台上部署大量项目否则平台可能限制你的构建并发或者暂停账号。我曾经在Netlify上挂了二十多个小项目某次大规模更新时触发并发限制全部部署进入队列状态才知道平台对免费用户的并发构筑有限制。所以我对“免费部署”的建议是优先选择一到两个平台深耕使用把配置归档成模板其他的平台作为备份方案随时可以切换迁移。这才是对付免费额度消失威胁的正确姿势。最后再分享一个我自己的使用习惯静态网站部署平台更新迭代很快隔三个月你就会发现平台新增了好几样好用的功能。建议每次发布新站点时都主动去研究一下平台后台的配置面板看看有没有新的重写规则、预览功能或缓存策略。很多性能问题和安全隐患其实就是少看了一眼配置项的事。免费的工具摆在那里好不好用完全看你愿不愿意花时间把它用明白。