静态网站上云部署：从手工传文件到可回滚的发布流程

很多个人项目一开始都是手工部署：本地改完代码，打包上传到服务器，覆盖旧文件，刷新页面看一眼，没问题就收工。这套流程在项目只有一个页面、访问量很小的时候够用，但只要出过一次“覆盖后才发现新版有问题、旧版又找不回来”的事故，就会明白发布流程本身也值得认真设计。下面这套做法不需要引入复杂的 CI 工具，一台云服务器加 Nginx 就能跑起来，核心就三点：版本化、可回滚、可验证。

先把“当前线上版本”变成一个明确的东西

手工部署最大的隐患，是线上跑的到底是哪一份代码说不清楚。解决办法很简单：每次发布都在服务器上留一个带版本号的目录，而不是直接覆盖网站根目录。比如把每次的构建产物放到 /var/www/site/releases/20261029-01/ 这样的目录里，再用一个软链接 /var/www/site/current 指向它，Nginx 的根目录只指向这个软链接。这样一来，线上版本永远有名字，出了问题能立刻说出“现在跑的是哪一版”，排查时不用猜。

版本号的命名不用讲究，日期加序号就够，关键是每次发布都新开一个目录，绝不复用旧目录。这样做还有一个附带好处：磁盘上天然保留了最近几次的发布历史，回滚不需要重新打包、重新上传，改一个软链接就能完成。

发布步骤：先上新版，再切流量

一个可回滚的发布流程可以固定成四步，顺序不要乱：

第一步，上传新版到新的发布目录，并核对文件完整性。文件数量、关键页面的大小、首页里引用的资源路径，至少抽查这三项。上传工具传丢文件的情况并不罕见，靠刷新页面肉眼检查很容易漏掉一张图或一个样式文件。

第二步，在服务器本地先验证新版。不要直接切流量后才发现问题：可以用本机回环地址加一个临时端口，或者用 Nginx 的临时 location 先把新目录挂出来，自己 curl 一遍首页和几个关键页面，确认返回 200、标题和内容都对，再往下走。

第三步，切流量。切流量就是把 current 软链接从旧目录改到新目录，这一步本身是原子操作，瞬间完成，不会出现“一半文件是旧版、一半是新版”的中间态。切完之后立刻从公网访问一次，确认看到的是新版内容，标题、样式、交互都正常。

第四步，保留旧版，观察一段时间再清理。刚切完不要急着删旧目录，至少保留最近两到三个版本，观察十几分钟，确认没有报错、没有用户反馈异常，再清理更早的版本。清理时只删发布目录，不动软链接和 Nginx 配置，避免误删正在运行的版本。

回滚：改一个链接，不要重新部署

新版上线后如果发现严重问题，正确的回滚不是“赶紧把旧代码再传一遍”，而是把 current 软链接指回上一个版本，然后重新加载一次 Nginx 配置。整个过程不到一分钟，而且回滚的目标是之前已经验证过的、真实跑过的版本，可靠性远高于临时重新打包。回滚完成后，再慢慢查新版的问题，修好后按同样的四步重新发布，不要在慌乱中直接往线上改文件。

这个习惯还有一个好处：它逼着你把“线上改动”全部收敛到发布流程里。直接在服务器上改文件、改配置的临时操作，看起来省事，实际上会让线上状态和本地代码脱节，下一次正常发布时很容易把临时改动覆盖掉，或者把临时改动误当成正式版本带走。凡是线上要改的东西，都先改本地代码、走一次发布，哪怕只是改一行文字。

Nginx 配置上值得顺手做的三件事

第一，给静态资源加合理的缓存头。HTML 文件本身不缓存或只缓存很短时间，保证用户刷新就能看到新版；图片、样式、脚本这些带哈希文件名的资源可以缓存久一点，因为文件名变了就等于新资源，不会读到旧缓存。缓存策略写错的典型症状是“明明发布了新版，自己手机上还是旧页面”，先查缓存头再怀疑部署。

第二，开启 gzip 或 brotli 压缩。静态页面和文本资源压缩后体积常常能小一半以上，对移动端访问体验的提升很明显，而且这只是 Nginx 里几行配置，不需要改代码。

第三，配置访问日志和错误日志的轮转。日志不轮转，磁盘迟早会被撑满；日志完全关掉，出问题又无从查起。保留最近一段时间的日志，定期轮转归档，是成本最低的排障手段。发布前后各看一眼错误日志有没有新增的 404 或 500，是个很好的收尾动作。

一份最小的发布检查清单

• 新版已上传到独立的版本目录，文件数量和关键页面已抽查
• 服务器本地已验证新版页面返回正常
• 软链接已切换，公网访问确认是新版
• 旧版本保留至少两个，观察无异常后再清理
• 错误日志无新增异常，缓存策略符合预期

这套流程没有用到任何付费服务，也不依赖特定云厂商，换一台服务器、换一个 Nginx 版本照样适用。它解决的不是“怎么把文件传上去”，而是“传上去之后怎么确认它是对的、错了怎么立刻退回来”。对个人项目来说，这已经是性价比最高的部署升级：多花五分钟走流程，少花一小时救火。