企业官网建设流程全解析

做前端这些年，我把不少个人项目、小Demo、甚至帮朋友临时做的落地页都放在本地文件夹里。能跑，但别人访问不了，这其实称不上一个真正的网站。直到我把第一个项目通过 Netlify 推到线上，从提交代码到线上生效不到一分钟，那种感觉就像终于给作品集补上了最后一块拼图。这篇就是一份完整的从0到1使用 Netlify 做线上部署网站的实操记录，我会把账号准备、三种部署方式、自定义域名、HTTPS 配置和各种常见坑一次性讲清楚，适合刚学会做静态页面但不知道怎么上线的同学，也适合想从 GitHub Pages 或传统云服务器迁过来的开发者。

1. Netlify 是什么，为什么线上部署首选它

1.1 从“本地能跑”到“线上可访问”，中间到底缺什么

本地localhost跑得再欢，也只有你一个人看得到。一个真正能被别人访问的网站，至少需要这几样东西：一台公网可达的服务器、一个能对外提供资源的 Web 服务程序、一个用户能记住的域名或子域名、还有一张浏览器不报错的 HTTPS 证书。如果自己买云服务器，你得手动装 Nginx、配置防火墙、做证书续期、处理日志切割，网站访问量稍微上来一点还要考虑带宽和并发。对大多数前端项目来说，这套操作成本高、收益低。

Netlify 做的事情，就是把“托管静态资源、CDN 加速、自动构建、HTTPS 证书、域名解析、环境变量、回滚和预览部署”这一整套基础设施打包成服务。你只需要给它一个 Git 仓库，或者一个构建好的目录，剩下的它全帮你处理。用起来的感觉，就像把“部署”这个本来很重的工作，变成了点一下按钮的日常操作。

1.2 Netlify 的核心能力和适用人群

Netlify 本质上是一个面向现代 Web 项目的托管平台，定位是 Jamstack 和静态站点托管。它的核心能力包括：

• 静态资源托管与全球 CDN 分发，访问者会自动就近拉取文件
• 与 Git 仓库集成，Push 代码后自动触发构建和部署
• 每个分支、每次 Pull Request 都能生成独立的预览地址
• 自动申请和续期 HTTPS 证书，不用自己碰证书文件
• 支持_redirects和_headers自定义重定向与请求头
• 提供 Netlify Functions，可以跑一些轻量的服务端逻辑
• 支持环境变量、部署通知、站点回滚等工程化能力

适合用 Netlify 的场景非常多：个人博客、作品集网站、前端组件 Demo、文档站、营销落地页、活动页面，甚至一些 SaaS 网站的公开主页。只要你的站点大部分内容是可以预先生成好的静态文件，Netlify 就非常适合。

但这不意味着它是万能的。如果你的项目需要常驻 WebSocket 连接、需要服务端渲染实时动态内容、或者涉及复杂的数据库长事务和自定义运行环境，那还是老实考虑云服务器或容器平台。把工具用在合适的地方，才是效率最大的保证。

1.3 和 GitHub Pages、Vercel、云服务器的横向对比

很多人在选部署平台时会纠结，这里我直接给出一个横向对比：

我个人更偏向 Netlify 的原因主要有三点。第一，它的部署预览和回滚体验是所有平台里做得最直观的，合并代码前可以先通过预览链接做视觉确认，线上出了问题也能一键回退到任意历史部署。第二，构建配置不锁死框架，不管是 Vite、Vue、React、Hugo、Zola 还是纯 HTML，只要设置好命令和输出目录就行。第三，免费版对个人项目的月度配额在实际体验中比较耐用，我的一些小型个人站点放在上面几乎没产生过费用。

2. 部署前准备：账号、仓库与三种接入方式

2.1 注册账号与免费版额度说明

第一步是注册 Netlify 账号。建议直接用 GitHub 账号的 OAuth 登录，这样后面导入仓库时少一步授权，权限也更顺滑。注册完成后，你会进入控制台，左侧是站点列表，右侧是各种管理入口。

免费版包含的基础资源一般足够个人项目使用，包括自动 HTTPS、每月一定的构建分钟数、每月流量额度以及无限的个人项目数量。需要注意，Netlify 对免费版有公平使用政策，如果站点流量或带宽长期远超免费额度，平台会提示升级或限制访问。个人博客、作品集这类日常项目一般碰不到这个门槛，但如果你打算放视频文件或大体积安装包，建议换成对象存储，而不是硬塞在站点目录里。

2.2 保证项目已经准备好进入构建流程

无论是用 Git 集成还是命令行部署，项目本身需要满足一些基本条件。首先，确保项目根目录有明确的package.json，并且scripts里定义了构建命令，比如"build": "vite build"。其次，请把node_modules和构建产物目录加入.gitignore，这些内容应该由部署平台在云端重新生成，而不是塞进仓库。

这里有个常见的认知偏差：很多人以为部署就是把源代码推上去，平台会自动帮你把网站跑起来。实际上，Netlify 的构建流程是在云端新建一个干净环境，然后执行你指定的构建命令。如果你提交的仓库缺少锁文件、或者构建命令写错，构建阶段就会直接失败。锁文件这东西特别重要，package-lock.json或yarn.lock能保证云端安装的依赖版本和你本地开发时一致，避免“本地好好的，线上崩了”的情况。

2.3 三种部署方式怎么选

Netlify 提供三种接入方式，根据场景灵活选择即可：

实际使用中，我的习惯是“正式项目用 Git 集成，临时演示用 Drop，自动化脚本用 CLI”。下方第 3 章会分别演示三种方式的完整流程，你可以按自己的场景选着看。

3. 从0到1完整部署实操：三种方式逐个走一遍

3.1 方法一：Git 集成，推荐的长期方案

先讲最推荐的 Git 集成方式，这也是所有人刚接触 Netlify 时最值得先掌握的。我用一个常见的 Vite 项目来演示，前提是你在 GitHub 或 GitLab 上已经有仓库。

第一步，在 Netlify 控制台点击Add new site，选择Import an existing project。第二步，选择你存放代码的 Git 平台，比如 GitHub，按提示授权并选择仓库。第三步，Netlify 会自动检测部分框架，如果检测不到，你就需要手动填写三项关键配置：

• Build command（构建命令）：npm run build
• Publish directory（发布目录）：dist
• 构建环境 Node 版本：建议与本地一致，比如 18

这里解释一下为什么 Vite 项目要填这两项。npm run build会执行打包，把源代码编译成浏览器可直接运行的 HTML、CSS、JS，产物默认输出到dist目录。Netlify 拿到的是dist里面的内容，而不是整个仓库，所以发布目录必须指向构建输出位置。如果你用的是 Vue CLI，发布目录通常是dist；用 React 的 Create React App，是build；用 Hugo，是public。填错了，部署大概率会出现 404。

第四步，点击Deploy site，等待构建日志跑完，控制台会显示部署成功的消息，同时给你一个默认的二级域名，格式类似random-name-123456.netlify.app。点击链接，如果看到你的页面，说明已经成功上线。第五步，回到站点控制台的Site settings，修改站点名称，这个名称会直接影响默认域名前缀，最好改成和项目相关的名字。

要让这个流程真正变成持续部署，还需要确保 Git 集成的自动发布选项是开启的。默认情况下，Push 到生产分支会自动部署到线上，Pull Request 的每次更新会自动生成一个独立的预览地址，这相当于给你的代码评审配了一个真实环境。这也是 Git 集成相比 Drop 和 CLI 最大的优势。

3.2 方法二：Netlify Drop，零配置的极速体验

如果你不想注册 Git 平台，或者只是临时给别人演示一个效果，Netlify Drop 是最快的方式。打开app.netlify.com/drop页面，把构建产物的文件夹直接拖进浏览器窗口，等几秒钟，系统就会自动上传并生成一个临时站点链接，这个链接可以直接发给任何人。

这里有一个特别容易踩的坑：很多人把整个项目目录拖上去，但项目是源码状态，没有index.html，也没有构建后的资源，结果打开预览看到的是文件夹列表，或者直接 404。正确做法是在本地先执行npm run build，拿到dist目录后再把dist拖进去。换句话说，Drop 上传的是“最终能直接运行的静态文件”，而不是“源代码”。

Netlify Drop 生成的站点没有绑定 Git 仓库，所以不会自动更新，适合一次性演示。如果你后续需要把它变成正式持续部署的项目，可以在站点面板中选择连接 Git 仓库，它会引导你把当前站点与项目关联起来。

3.3 方法三：Netlify CLI，把部署写进脚本

命令行方式适合需要批量操作或集成到自动化流程的场景。先安装 CLI 工具，一行命令即可：

npm install -g netlify-cli

登录账号：

netlify login

在项目根目录初始化：

netlify init

它会询问你创建新站点还是关联已有站点，并自动读取你的构建命令和发布目录。之后执行草稿部署，生成一个可供预览的临时地址：

netlify deploy --build

确认预览没问题后，正式发布到线上：

netlify deploy --prod

注意，netlify deploy不会覆盖线上环境，它只是在云端生成一个预览站；只有带--prod参数才会更新生产环境。这种分离设计在发布流程中很实用，相当于自带了一个“先预览后上线”的阀门。

CLI 还有一个功能我很常用：netlify dev。它会在本地启动一个完全模拟 Netlify 环境的开发服务器，除了静态资源，还支持本地调试 Netlify Functions，这样可以提前发现和线上环境相关的配置问题。

3.4 部署完成后应当立刻处理的基础配置

不管用哪种方式部署成功，我建议你第一时间做三件事。

第一件事，在站点控制台的Domain management里确认默认域名状态正常，并且顺手开启 HTTPS。虽然 Netlify 会自动为默认域名签发证书，但多地 DNS 生效需要一点时间，早确认早安心。第二件事，在项目根目录添加netlify.toml，把构建和环境配置用配置文件固化下来，这样以后多人协作或者重新导入项目，不用再依赖在网页上手动点选。一个 Vue 项目的示例配置如下：

[build] command = "npm run build" publish = "dist" [build.environment] NODE_VERSION = "18"

第三件事，配置部署通知。在Build & deploy的部署通知设置里，可以添加部署成功或失败的邮件通知，也可以挂一个 Webhook 到你的即时通讯机器人，这样团队在代码合并后能立刻知道站点是否发布成功。这个习惯能帮你早点发现构建环境真的和本地不一致的情况，而不是等用户访问才察觉。

4. 自定义域名、HTTPS 与 DNS 细节

4.1 域名接入的两种方式：托管 DNS 还是外部 DNS

默认的xxx.netlify.app域名适合测试，正式项目肯定要用自己的域名。接入自定义域名有两种路径，先理解再选择。

第一种是把域名商处的 NS 记录改为指向 Netlify，由 Netlify 完全托管 DNS。操作位置在域名注册商那里，将域名的 NS 记录替换为 Netlify 提供的两个地址。这种方式的好处是后续添加子域名、配置邮箱验证、自动签发证书都很省心，因为域名解析和站点配置在同一个平台里管理，少了很多等待和误会。

第二种是保留原来的 DNS 服务商，只添加一条解析记录指向 Netlify。比如外部 DNS 面板里给裸域加 A 记录，给 www 子域加 CNAME 记录。这种方式控制权更集中，但你需要自己去处理解析生效、证书签发和后续改记录的问题，对 DNS 不太熟的人容易在这里卡住。

我的建议是，如果域名是给人展示用的正式站点，直接把 DNS 托管到 Netlify，省心很多。如果域名还挂着邮箱服务、接口子域等一堆别的记录，那保留外部 DNS 更稳妥，避免迁移过程中影响其他服务。

4.2 A 记录、CNAME 记录与裸域、WWW 的处理

在Domain management中点击Add custom domain，输入你的裸域，比如example.com，Netlify 会提示你需要添加哪些解析记录。一般情况下，裸域需要配置 A 记录，指向 Netlify 的负载均衡 IP；www.example.com则用 CNAME 记录指向你的 Netlify 默认域名。

这里要特别注意：Netlify 面板会列出当前分配给站点的负载均衡 IP，不同站点的 IP 可能是不同的，必须以面板显示为准。前几年网上很多教程直接写死一组 IP，现在不少已经过时了，照抄别人的记录很可能解析失败。配置完成后不要急着等，在本地用dig或nslookup命令验证一下：

nslookup example.com

如果返回的 IP 和面板展示的一致，说明解析已经生效。如果本地能看到、但线上用户访问慢，可以留意一下是不是运营商 DNS 缓存导致的延时，稍等一段时间通常会自动恢复。

裸域和 www 域名建议同时接入，并设置好其中一个是主域名，另一个做 301 跳转。Netlify 在域名管理里会提供这个开关，不用自己在_redirects里写规则。

4.3 HTTPS 证书自动签发机制与常见卡点

Netlify 的 HTTPS 证书是自动申请和续期的，使用的是公开 CA 体系。你不需要生成私钥、上传 CSR 或者手动替换证书文件，只需要保证域名解析已经指向 Netlify，平台会自行验证域名所有权并进行证书签发。

实际操作中，证书签发一般要等几分钟到几个小时，偶尔会遇到一直显示 Pending 的情况。我踩过的坑主要有三种。第一种是外部 DNS 里解析记录写错了，比如 CNAME 指向了不存在的域名，导致验证请求无法到达 Netlify。第二种是域名之前挂在别的平台，旧的 CDN 或者反向代理还在响应请求，Netlify 检测到域名正被其他服务使用，会迟迟不下发证书。第三种是证书签发窗口与解析生效窗口有交错，解析刚改完但全球 DNS 还没完全同步，平台验证时发现记录不稳定，便会进入等待重试周期。

遇到 Pending 不要反复删除重加域名，先确认解析、再等一段时间。另外，别忘了设置强制 HTTPS，把 HTTP 流量 301 到 HTTPS，这样用户输入不带协议的地址也能得到加密访问。

5. 常见问题与排查技巧实录

5.1 构建失败：日志比报错更重要

构建失败是新手遇到最多的问题，表现形式基本是部署进度停在Build阶段，然后出现大红字Build script returned non-zero exit code。出现这类报错，第一件事是看构建日志，里面会准确告诉你是在安装依赖时挂的、执行构建命令时挂的、还是找不到发布目录。

最常见的原因有三个。第一，Node 版本不一致。本地用的 Node 20，但 Netlify 云端默认可能是 16，某些依赖在低版本 Node 上安装会失败。解决方案是在项目根目录加.nvmrc文件，内容写18或你本地验证过的版本，Netlify 会自动读取并切换 Node 版本，或者在netlify.toml的[build.environment]里设置NODE_VERSION。第二，构建命令里的路径写错，比如 Windows 下用了反斜杠，或者脚本里依赖了本机才有的全局工具。第三，发布目录不存在，可能你把构建产物写到了build目录，却在配置里填了dist。

排查思路可以这样：先在本地跑一遍netlify build，它能完整模拟云端构建流程，大部分问题在本地就能复现；如果本地没问题，再回去看云端日志里依赖安装阶段有没有网络或缓存导致的异常。

5.2 SPA 路由刷新 404 与重定向配置

使用 Vue Router 或 React Router 的 history 模式时，有一个经典问题：用户访问首页没问题，但刷新某个子路由页面时，服务器返回 404。原因是你在服务器上不存在/about这个物理文件，浏览器请求直接落到了静态文件服务上，自然找不到。

Netlify 解决这个问题靠的是自定义重定向规则。你可以在发布目录的根目录放一个名为_redirects的文件，内容只有一行：

/* /index.html 200

意思是所有路径都返回index.html并保持 200 状态码，由前端路由接管后续跳转。也可以把同样的规则写进netlify.toml：

[[redirects]] from = "/*" to = "/index.html" status = 200

这里有个隐蔽的坑：如果你用 Vite 等框架，_redirects文件必须放在public目录，因为最终构建时它会被原样拷贝到发布目录根下。我曾经把它放在src目录里，本地预览正常，部署成功后刷新就一直 404，排查了很久才意识到文件根本没被构建工具从src复制进dist，自然也就不存在了。

5.3 环境变量与敏感信息管理

部署平台上的环境变量是一个经常被误解的功能。你在站点的Environment variables里定义的变量，会在构建阶段注入到构建进程中，前端代码里的process.env.XXX或import.meta.env.XXX会在打包时替换成具体值。这意味着，任何打进前端代码的环境变量，最终都是公开的。比如接口地址、CDN 路径、Google Analytics ID 这类的可以放前端，但密钥、Token、数据库连接串绝对不能放。

如果一定要在前端访问某些敏感配置，正确的做法是用 Netlify Functions 包一层代理。前端请求你自己的函数地址，函数里读取私密环境变量，再请求外部服务，把结果返回给前端。这样密钥保留在服务端，永远不会暴露在浏览器网络面板里。

本地开发时，用netlify dev会自动加载站点面板上配置的环境变量；如果本地有一些临时变量，用.env文件管理，记得把它加进.gitignore，避免提交。

5.4 缓存、大文件与回滚的那些事

Netlify 的每次部署都是原子性的，新文件集准备完成后无缝切换到生产环境，理论上不会出现新旧文件混用的情况。但是 CDN 缓存有时候会给你一点小惊喜，比如图片和 JS 资源在部署后仍在访问旧版本。遇到这种情况，可以在站点控制台的 Deploys 页面点击Clear cache and deploy site，强制清理缓存重新部署一次。

大文件是静态托管平台的老问题。免费版对单个文件大小有限制，具体数值以官方文档为准，超过限制的部署会直接失败。如果确实要放安装包或者视频，建议使用对象存储加 CDN 的方式，在<script>或链接里引用外部地址，而不是放进站点构建目录。

回滚功能是我用得最多的运维功能之一。在Deploys页面，每个历史部署旁边都有一个Publish deploy按钮，点击后线上环境会立即切换回该版本。注意，这本质上是把历史产物重新发布一遍，并不是真的“撤销”到从前，所以回滚之后自动部署仍然会继续工作，下次 Push 新代码依然会覆盖回滚版本。

5.5 部署问题速查表

最后分享一个我自己的习惯：不管项目大小，我会在首次部署前就把_redirects、_headers、netlify.toml这三样基础文件放进项目，而不是等上线出了问题再补救。配置文件的沉淀比在网页面板里做一次成功的点击更有价值，换一个项目、换一台电脑、换一位同事，都能保持一致的部署行为。从 0 到 1 的本质，是先理解了网站从本地到线上的完整路径，然后让这套路径变成可复制、可维护的默认流程，最终你不再为“部署”这件事焦虑，而是把注意力放回功能和内容本身。