很多团队在本地开发环境跑得好好的项目，一到部署上线就出问题——域名解析生效慢、HTTPS证书报错、静态资源404。这些现象背后，往往不是代码本身的问题，而是对上线链路的理解不够完整。在福州网站开发的实践中，部署环节的故障排查平均占到项目交付周期的30%以上。

域名解析：不只是加一条A记录

域名解析的本质是DNS递归查询。当用户在浏览器输入域名，本地DNS服务器会逐级向上查询，最终拿到A记录指向的IP。常见误区是只添加A记录而忽略了CNAME与MX的优先级冲突。若同时存在CNAME和A记录指向同一主机名，部分DNS服务商会返回异常结果。

建议将TTL设置为300秒而非默认的3600秒，尤其在迁移服务器时，低TTL能让解析变更快速生效，减少用户访问中断。

部署上线阶段的典型问题

• 证书链不完整：Nginx配置ssl_certificate时只传了站点证书，缺少中间CA证书，导致部分安卓设备报“不安全”。
• 静态资源路径大小写敏感：本地macOS不区分大小写，Linux服务器区分，构建产物引用路径大小写不一致直接404。
• 端口未放行：云服务器安全组只开了22和80，443未放行，HTTPS握手直接超时。

这些问题在网站搭建流程中反复出现，本质上是环境差异没有被纳入CI/CD流水线的检查项。建议在部署脚本中加入证书链校验和路径大小写扫描两个步骤。

从部署到持续交付的对比

手动FTP上传与Git钩子自动部署的差异，在项目初期不明显。但当迭代频率超过每周两次，手动方式的回滚成本急剧上升。以app开发团队常采用的Docker+Compose方案为例，镜像版本标签管理比直接改服务器文件可靠得多——出问题时切换回上一个tag即可，耗时不超过30秒。

如果团队规模在5人以下，不必急着上K8s。一台2C4G的云主机配合Nginx反向代理和PM2进程守护，足以支撑日均PV 5万以内的业务。关键是做好日志切割和磁盘监控，避免日志写满导致服务不可用。

部署上线不是一次性的动作，而是需要持续观测的环节。建议至少配置一个HTTP可用性探针和一个磁盘使用率告警，这两项能覆盖80%的线上突发故障。