企业官网建设流程全解析

系列写到这一篇，咱们终于要把“能跑”变成“能上线”，再把“能上线”变成“能交代”。前面几篇我带着你从零搭了前端页面、写了后端接口、设计并填充了数据库，代码仓库里已经有模有样。但说句实在话，只有等你把项目真正部署到一台云服务器上、用域名访问、让手机电脑都能顺畅打开的那一刻，这个项目才算结束。而这篇文章要干的正是这件事：先做一轮实战部署，把产品推上线，再聊聊“结束篇”——项目收尾、复盘归档、经验沉淀。适合谁看呢？如果你跟着系列做到了功能完成但还没上过线，或者你有一堆半成品项目不知道怎么收束，这篇就是给你写的。

1. 实战前夜：把开发态切换到发布态

很多人第一次上线翻车，不是因为代码写错了，而是把“开发环境能跑”和“生产环境能跑”当成了一回事。开发时我们习惯开着热更新、打印调试日志、用本地文件当数据库，这些便利在生产环境里全是隐患。所以真正的实战，第一关不是敲部署命令，而是先做一轮“状态切换”，让项目从一个开发作品变成一个可交付的产品。

1.1 先做减法：依赖、配置与本地产物

本地开发的依赖里，通常混着一堆只在调试时用的包。比如前端项目里的 mock 服务、后端的热重载工具、格式化插件，这些在生产环境既用不上，还会增加构建体积和安全暴露面。我一般在写收尾代码之前，先把package.json从头过一遍，凡是没有被业务代码直接 import 的东西，全部从 dependencies 里挪走，就算要在本地用，也只留在 devDependencies。MySQL、Redis 这类服务用容器跑，不要直接安装到系统里，避免依赖冲突。

同时要做的另一件事，是锁定版本。不管你们团队用 npm、yarn 还是 pnpm，一定要确认锁文件已经提交到仓库。我见过不止一次线上构建失败，最后发现是某个间接依赖在小版本更新里改了行为，而本地因为缓存还跑在旧版本。锁文件这个东西，平时没什么存在感，但你发布的时候它就是唯一能让本地和服务器构建结果完全一致的东西。

1.2 本地全链路预演：不要直接拿服务器当试验场

本地预演这一步，很多人会跳过，但我强烈建议你至少在发布前跑一遍完整的生产模式。对前端项目来说，就是执行构建命令，然后启动静态文件服务去访问 build 出来的产物，而不是继续用 dev server。这一步能暴露的问题出奇地多：资源路径用的是相对路径还是绝对路径、路由有没有配 history 模式导致刷新 404、图片有没有被正确压缩。光这三点，我每次都能在预演时抓到至少一两个。

后端也一样，用正式的启动命令跑起来，关闭调试模式，观察启动日志里有没有红色的警告。我习惯在本地预演时顺手做一次“冷启动测试”，就是清掉所有缓存、停掉数据库、从零开始执行初始化脚本，确保一台新机器照着文档也能把服务拉起来。这个测试成本很低，但价值极高，它能验证你的初始化流程是不是真的完备，而不是靠你脑子里的“我记得好像要先建个表”。

注意：生产模式的本地预演，一定要用独立的端口，不要沿用开发端口。因为不少框架在开发模式下会注入跨域头、放宽某些校验，这些在预演环境里可能掩盖真实问题。

2. 部署实战：一台Linux服务器上的完整动作

预演通过之后，才轮到真正的服务器部署。这一节我按“买好服务器之后从上到下”的操作顺序来讲，你跟着一步步做，不需要什么高深的运维基础，但每一步都别跳。

2.1 服务器初始化：用户、SSH与防火墙

拿到一台全新的云服务器，第一件事永远不是装环境，而是先创建一个普通用户，别用 root 直接干活。原因很朴素：root 权限太高，任何脚本执行错误都可能把系统搞坏，而且被暴力破解的风险也更大。创建一个 deploy 用户，然后用usermod -aG sudo deploy给管理员权限，日常操作都用这个用户。

接着配置 SSH 密钥登录，关闭密码登录。具体操作是ssh-keygen生成密钥对，把公钥追加到服务器的~/.ssh/authorized_keys里，然后编辑/etc/ssh/sshd_config，把PasswordAuthentication设为 no。这一步能挡住绝大多数脚本扫描。设置完成之前别急着断开当前连接，开一个终端放那儿保持会话，万一配置错了还能回去修改。

防火墙规则也要尽早收紧，我的原则是“默认丢弃，按需放行”。以 ufw 为例，先执行ufw default deny，然后再放行 22、80、443 三个端口。别把数据库端口 3306 或 5432 暴露到公网，应用连数据库走内网地址就够了，否则你等于把数据库裸奔在公网上，这是新手最容易忽视的安全问题。

2.2 Nginx反向代理与HTTPS证书申请

项目跑起来之后，直接用 IP 加端口访问又丑又不安全，合格的实战部署必须做两层事：用 Nginx 做反向代理，让外网统一走 80/443；用 Let’s Encrypt 免费证书启用 HTTPS。后端服务监听 127.0.0.1:8080 就好，不直接对外暴露，所有请求都打到 Nginx 上，由它转发给对应的服务。

Nginx 站点的核心配置思路如下，你按需改域名和端口：

server { listen 80; server_name yourdomain.com; # 前端静态资源 location / { root /var/www/nav-site/dist; try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

HTTPS 证书我用 Certbot 申请，一条命令就能完成：先安装 certbot 和 nginx 插件，再执行certbot --nginx -d yourdomain.com，它会自动修改 Nginx 配置并加载证书。证书有效期 90 天，记得用certbot renew加定时任务自动续期。我一直把它配成每日凌晨执行一次，反正没到续期时间它不会做任何操作。

2.3 用systemd把后端进程变成“永不宕机”

后端服务直接前台跑在终端里，一关窗口就没了，这当然不行。Linux 下最优雅的方式是用 systemd 管理进程，优点是开机自启、崩溃自动重启、日志统一归集。写一个 service 文件，路径在/etc/systemd/system/nav-site.service，内容大致是这样：

[Unit] Description=Nav Site Backend Service After=network.target [Service] User=deploy WorkingDirectory=/opt/nav-site ExecStart=/usr/bin/node server.js Restart=always RestartSec=3 Environment=NODE_ENV=production EnvironmentFile=/etc/nav-site.env [Install] WantedBy=multi-user.target

写完后执行systemctl daemon-reload，接着systemctl enable --now nav-site启动并设置开机自启。环境变量用 EnvironmentFile 单独放，好处是换配置不用改代码，也避免了把密钥写进仓库。服务状态用systemctl status nav-site或journalctl -u nav-site -f查看，日志排错都靠它。

注意：如果后端进程启动后报“端口被占用”或“连不上数据库”，先不要急着改代码，用ss -lntp看端口状态，用ping 数据库地址看网络通不通。部署环境的问题里，网络不通的比例比我预想的高很多。

3. 实战调优：把“能跑”变成“好用”

部署上线只是把服务跑起来了，距离“好用”还差一轮优化。我自己的经验是，上线第一周别急着加功能，先盯着访问日志和监控指标把稳定性提上去，否则每次报错都要临时上服务器查，很被动。

3.1 静态资源缓存与压缩配置

静态资源是前端性能的大头，没配缓存之前，用户每次刷新都要向服务器重新拉一堆 JS、CSS，很浪费带宽。正确做法是给带 hash 的文件设置长时间缓存，给 index.html 设置 no-cache。因为带 hash 的文件名一变就代表内容变了，不会被旧缓存拖累。

在 Nginx 里我是这样配的：

location /assets/ { expires 30d; add_header Cache-Control "public, immutable"; } location = /index.html { add_header Cache-Control "no-cache"; }

压缩也要开，Nginx 默认支持 gzip，加上几行配置就能压缩 html、js、css、json 这些文本资源。现在 Brotli 压缩率比 gzip 高 20% 左右，但 Nginx 需要额外模块，如果服务器是官方源装的 Nginx，先开 gzip 也足够。压缩之后，页面首屏的大小经常能小一半以上。

3.2 慢接口定位与数据库索引优化

上线之后，用户说“页面好卡”，你第一反应是什么？我现在的习惯是先查接口耗时，而不是猜前端原因。在开发时我就给接口加了简单的计时中间件，每个请求结束后把路径、状态码、耗时打到日志里。定位慢请求特别管用，直接grep "slow"就能找到耗时超过 500ms 的接口。

找出慢接口之后，八成问题出在数据库查询上。拿我们给导航站做的“统计点击量”接口举例，一开始表里没索引，点击量一涨，查询就变慢。解决方案就是用EXPLAIN看执行计划，发现是全表扫描，就在url_id字段上加个普通索引，查询时间从 300ms 掉到 20ms。对绝大多数中小项目而言，建好索引比换机器、上缓存都管用。

排查表给你一份，照着做基本能解决大部分性能问题：

3.3 日志轮转与定时备份的日常巡检

服务器跑久了，磁盘被日志塞满是个非常常见的事故。Node 进程如果不接日志切割，一个 error.log 能长到几个 G。Linux 自带 logrotate，我习惯给它写一个规则，按天切割、保留 7 份、压缩归档。放在/etc/logrotate.d/nav-site里：

/var/log/nav-site/*.log { daily rotate 7 compress missingok notifempty copytruncate }

数据库备份也得安排上。我的习惯是每天凌晨用 cron 执行一次备份脚本，把数据库文件打包传到另一台服务器的备份目录，同时保留最近 15 份。真出问题的时候，备份就是救命稻草。写个脚本很简单，关键是先跑一次验证脚本真的能恢复，别等事故来了才发现备份文件是坏的。

4. 结束篇：把项目归档成能再讲清楚的东西

很多人做完项目发完文章就扔一边了，过半年回头看，代码看不懂，部署步骤也忘光了。所谓的“结束篇”，不是把 repo 一关就完事，而是要把项目变成一个随时能捡起来说清楚的东西。

4.1 踩坑实录：几个值得写进事故报告的瞬间

我这次实战过程中踩了几个典型的坑，每一个都值得记下来。

第一个是时区问题。服务器默认时区是 UTC，我们的站点却是面向本地用户的，导致数据库里记录的上次更新时间比真实时间慢了 8 小时，用户看到的时间全是错的。排查半天才想起来是时区没设置。后来我把所有服务器统一设为 Asia/Shanghai，并且约定后端接口一律返回时间戳，由前端负责格式化，彻底避免时区歧义。

第二个是更新发布后用户看到的还是旧资源。原因就是前面说的 index.html 被缓存了，旧的资源引用关系失效，页面白屏。解决方式是把 index.html 设为 no-cache，顺带在发布脚本里加了一个强制刷新 CDN 缓存的步骤。从那以后我再也没有因为静态资源缓存问题接到过用户反馈。

第三个是文件权限问题。我把项目部署到/opt/nav-site，结果忘了给 deploy 用户写权限，导致日志文件根本写不进去，服务启动成功但业务全在报错。这种问题命令行不细看根本发现不了。后来我养成了一个习惯：每次部署完，看一眼ls -l确认用户组，再tail -f一下日志确认服务真的在正常输出，而不是只看进程列表。

4.2 复盘清单：代码之外的三件事

项目收尾时，我给自己定了一个复盘清单，分享出来你直接拿去用也可以。

第一件事是写 README。别小看这份文档，它是你项目说明书。我会在 README 里写清楚：项目是做什么的、目录结构如何、本地怎么启动、生产环境怎么部署、环境变量有哪些。写的时候有一个标准：每一个命令都必须是我在干净环境里实测过的，不许凭记忆写。这个习惯帮我排掉了很多“按文档部署失败”的问题。

第二件事是整理回滚方案。上线之后发生意外是常态，关键是怎么快速回到上一个稳定版本。我在发布目录里保留了上一个版本的完整目录，然后写了一个 rollback 脚本，执行后就是切换软链接、重启服务。虽然大多数时候用不上，但一旦用上，能节省半小时的心理斗争和手忙脚乱。

第三件事是技术选型反思。做完整个项目，我已经能明显感受到哪些技术是真的好用、哪些是过度设计。比如这次我选了 SQLite 而不是 MySQL，因为导航站数据量不大，用 SQLite 让备份、迁移都变得极其简单。事后证明决策正确。这种反思记录到文档里，等下次做新项目时就是最有价值的参考。

4.3 这个项目还能往哪走

收尾不等于项目终点，我会把“还能做什么”单独列一节写进项目文档里，给未来的自己留个路标。当前这个导航站，可以顺手接入全文搜索，可以给每个链接加访问趋势统计，可以做 PWA 版本让手机像原生 App 一样安装。这些都是成本不高的迭代点。

但这些功能，我不会在收尾这个时间点立刻去加。原因很简单：一个项目必须有“足够完整然后停下来”的时刻，否则会陷入无限开发的状态。你练手积累的经验，可以在下一个项目里用上，而不是继续在这个项目里无节制地堆叠。在项目最稳定的时候结束它，本身就是一种实战能力。

最后分享一个我个人的习惯：项目归档后，我会把部署方式和踩坑记录同步写进笔记软件，和线上服务之间留一个自己能看懂的操作手册。之后再过三个月、半年，再有人问起这个项目，我只需要翻一分钟笔记就能把来龙去脉说清楚。整理能力可能就是技术人员最容易被低估的软技能。这一轮“实战篇 + 结束篇”写到这里，希望你的项目也能稳稳上线、体面收尾。