1. 推荐部署结构#
公网 80/443
│
▼
Nginx ───── 静态文件（如有）
│ 反向代理
▼
应用容器 :3000 ───── PostgreSQL :5432
（不直接暴露公网）2. Nginx 与 HTTPS#
配置域名、反向代理、请求头、访问日志与错误日志。 修改后先测试配置，再平滑重载。 用受信任证书启用 HTTPS，并配置自动续期与到期检查。 理解代理超时、上传大小限制、静态缓存与压缩。
3. Docker#
镜像、容器、端口映射、卷、网络、环境变量的区别。 Dockerfile 用于构建镜像；Compose 文件描述多个服务如何运行。 数据库数据放持久卷；删除容器前确认数据和备份。 不把密钥写入镜像或提交到仓库；不要以为容器等于安全边界。 健康检查、多阶段构建、非 root 用户、镜像版本固定。
4. 上线前安全底线#
- 操作系统和依赖更新到受支持版本；
- 使用普通部署用户，SSH 优先密钥认证；
- 防火墙只开放必要端口；数据库不直接对公网；
- 全站 HTTPS；Cookie 和代理信任设置正确；
- 密钥来自环境或专用密钥管理，不在 Git 中；
- 密码专用哈希、参数化 SQL、所有输入校验；
- 服务端对每个资源执行授权；
- 登录和高成本接口有限流；
- 错误响应不暴露内部信息；日志经过脱敏；
- 定期依赖审计，移除不用的包；
- 备份已加密/限制访问，并实际验证过恢复。
5. 可观测与维护#
最少关注四类信号：服务是否可用、错误率、响应时间、资源使用。日志要能串联一次请求；健康检查不应只返回固定的“OK”，还需区分“进程活着”和“关键依赖可用”。
发布流程#
- 测试通过并记录版本；
- 备份数据库，确认恢复办法；
- 应用数据库迁移；
- 发布应用并检查健康状态；
- 运行冒烟测试：登录、读取、写入；
- 观察日志和指标；
- 失败时按预先写好的方案回滚。
6. 备份原则#
采用 3-2-1 思路：至少 3 份数据、2 种介质、1 份异地。备份成功的日志不等于可恢复；每月至少做一次恢复演练，记录恢复用时和遗漏。对个人学习项目，也至少保存数据库导出、上传文件和部署配置。
最终验收#
- 新服务器能按文档重建环境。
- 域名通过 HTTPS 访问，HTTP 自动跳转。
- 应用与数据库重启后能自动恢复服务。
- 数据库没有直接暴露公网。
- 能从备份恢复到新数据库并核对关键数据。
- 能从日志定位一次 500 和一次 502 的原因。
- 有清晰的更新、发布、回滚步骤。