环境部署

环境部署指南

环境部署是网站从代码变成服务的最后一道工序，也是最容易出错的一环。无论你是手动装 LNMP，还是用 Docker Compose 编排，下面这套资源都能帮你把“能跑”升级为“稳定可上线”。

AI 提示词模板

把下面的提示词喂给 AI 建站工具，可以一次性拿到从服务器初始化到上线的完整部署方案，减少来回补充上下文的时间：

请帮我部署网站生产环境。
- 网站类型：[静态站/PHP/Node.js/Python]
- 服务器 OS：[Ubuntu/CentOS/Debian]
- 数据库：[MySQL/PostgreSQL/SQLite]
- HTTPS：[是/否]

输出：服务器初始化、Nginx 配置、运行环境安装、数据库配置、SSL 证书。

LNMP 一键部署

在全新的 Ubuntu 服务器上，一条命令装好 Nginx、MySQL 和 PHP：

apt update && apt install -y nginx mysql-server php-fpm php-mysql
apt install -y certbot python3-certbot-nginx

装完记得跑一遍安全初始化：mysql_secure_installation 设置 root 密码、删除匿名用户和测试库。

Nginx 站点配置

server {
    listen 443 ssl http2;
    server_name yourdomain.com;
    root /var/www/yourdomain;
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    location / { try_files $uri $uri/ /index.php?$query_string; }
    location ~ \.php$ { fastcgi_pass unix:/var/run/php/php8.1-fpm.sock; }
    location ~* \.(jpg|png|ico|css|js)$ { expires 30d; }
}

Docker Compose LAMP 环境

version: '3.8'
services:
  web:
    image: nginx:alpine
    ports: ["80:80", "443:443"]
    volumes: ["./site:/usr/share/nginx/html"]
  db:
    image: mariadb:10
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
    volumes: ["db_data:/var/lib/mysql"]
volumes: {db_data:}

密码通过 .env 注入，不要把 MYSQL_ROOT_PASSWORD 直接写死在 compose 文件里。

SSL 证书申请（Certbot）

apt install certbot python3-certbot-nginx -y
certbot --nginx -d example.com -d www.example.com
certbot renew --dry-run

部署不只是把文件传上去

“在我机器上是好的啊”——这句话几乎是每个运维人的噩梦。本地环境和生产环境的差异，制造了一批最难排查的线上问题。部署的真正目标不是“把代码放到服务器上”，而是“创建一套可预期、可重复的运行环境”。

如果你正在用 AI 建站，这一点尤其重要：AI 生成的是代码，但代码能不能稳定跑起来，取决于环境。建议先读一读Docker 部署入门，用容器把环境差异彻底封死。

环境管理三原则

1. 一致性

尽可能缩小开发、测试、生产三套环境的差异。PHP 差一个小版本，函数行为都可能不一样。

做法：用Docker Compose 或 Vagrant 定义本地环境，新同事加入后 10 分钟内能跑起来，而不是花半天手工装环境。

2. 配置分离

代码和配置是两回事。数据库密码、API Key 不该进仓库：

project/
├── .env.example        # 提交到仓库，包含所有键的模板
├── .env                # 被 gitignore，存放真实值
├── config/
│   ├── app.php
│   └── database.php    # 从 .env 读取

3. 可回滚

每一次部署都应该能在 5 分钟内回滚。如果你的发布没有回滚方案，等于在赌。

部署策略对比

对中小站点来说，蓝绿部署是性价比最高的选择：维护两套环境，新版本部署到 green，验证通过后再切流量，出问题切回 blue。要注意的是，蓝绿部署需要两倍的机器资源，如果预算紧张，也可以退而求其次——保留上一版本的构建产物，配合一键回滚脚本，同样能达到 5 分钟内的回滚目标。

备份的现实检查

备份的价值只取决于一件事：你能不能从备份里恢复。

关键建议：别等出了事故才第一次恢复备份。每月在干净服务器上做一次完整恢复演练，验证数据完整性——你会发现不少备份其实恢复不出来。

SSL 的现实

Let's Encrypt 证书对绝大多数站点都够用。用 Certbot 配置好自动续期，再加监控确认续期成功，每月检查一次证书状态，就不会在一年后惊恐地发现“证书过期了”。

上线前检查清单

部署完成不等于可以放流量。上线前按下面清单过一遍，能避免绝大多数“上线即事故”：

• 防火墙只放行必要端口（80/443/SSH），SSH 改为密钥登录
• 数据库密码不是默认值，且只允许内网访问
• 站点目录权限收紧，上传目录禁止执行 PHP
• 全站 HTTPS 生效，HTTP 自动跳转
• 日志轮转已配置，避免日志把磁盘写满
• 备份脚本已跑通，且做过一次恢复演练

部署失败时怎么办

再完善的流程也会遇到发布后接口报错、页面白屏的时刻。这时候靠的不是临场发挥，而是预案：第一步先回滚到上一个版本，让业务先恢复；第二步再慢慢排查，不要一边线上报错一边在服务器上改代码。回滚的前提是代码目录和数据库结构都支持快速回退——所以配置分离和可回滚原则要提前做好，而不是出事当天才想起来。

如果你的团队规模小，也可以考虑用现成的面板或 CI/CD 工具，把部署变成一条可重复执行的流水线，减少手工操作引入的人为失误。