django项目打包发布

```html

把Django项目扔到服务器上跑起来，项目和在自己电脑上runserver完全是打包两码事。本地开发时Django自带的发布开发服务器能热重载、能直接读静态文件，项目但线上环境它连一个并发请求都扛不住。打包所以打包发布的发布核心就一句话：用WSGI服务器跑Django应用，用Nginx挡在前面处理静态文件和反向代理。项目

我见过太多人卡在collectstatic这一步。打包Django的发布静态文件机制在开发模式下是自动映射的，但生产环境需要把所有app里的项目static目录汇总到一个地方。在settings.py里加上STATIC_ROOT = os.path.join(BASE_DIR,打包 'staticfiles')，然后执行python manage.py collectstatic。发布这个命令会把admin后台、项目第三方包、打包你自己写的发布所有CSS/JS/图片全部复制到staticfiles目录下。有一次我忘了加STATIC_ROOT，collectstatic直接报错说目标目录没定义，折腾了半小时才反应过来。

WSGI服务器选gunicorn还是uWSGI？我偏向gunicorn。配置简单，跟Django的兼容性好，出问题日志也清晰。安装完直接命令行启动：

gunicorn myproject.wsgi:application --bind 0.0.0.0:8000 --workers 3

workers数量有个经验公式：2 * CPU核心数 + 1。但别死守这个，如果应用里有大量IO操作比如调外部API，可以适当加几个。不过worker开太多反而会因为内存抢占拖慢响应。我一般先用3个跑起来，压测看情况再调。

但gunicorn自己处理不了静态文件，也不该让它处理。Nginx这时候就派上用场了。一个典型的Nginx配置长这样：

server {  listen 80; server_name yourdomain.com; location /static/ {  alias /path/to/staticfiles/; } location /media/ {  alias /path/to/media/; } location / {  proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里有个坑：alias和root的区别。用alias时Nginx会把location匹配的部分替换掉，所以/static/请求会去/path/to/staticfiles/下找对应文件。如果用root，它会拼成/path/to/staticfiles/static/，路径就错了。我刚开始配的时候在这栽过跟头，浏览器一直报404，查了半天Nginx日志才发现路径多了一层。

数据库迁移别忘了。发布前在服务器上跑python manage.py migrate，但要注意如果多个worker同时启动，可能会并发执行迁移导致锁表。稳妥的做法是在部署脚本里单独跑一次migrate，确认成功后再启动gunicorn。

环境变量也得处理好。DEBUG = False是必须的，否则Django会暴露堆栈信息给用户，安全隐患很大。数据库密码、SECRET_KEY这些敏感信息不要硬编码在settings.py里，用os.environ.get()从环境变量读取。我习惯用.env文件配合python-dotenv，本地和线上各维护一份，settings.py里统一加载。

最后说下进程管理。直接命令行启动gunicorn，SSH一断进程就没了。用systemd或者supervisor把它做成系统服务。systemd的配置文件放在/etc/systemd/system/myproject.service，写清楚启动命令、工作目录、重启策略。这样服务器重启后应用也能自动拉起来。

整个流程走下来其实不复杂，但每个环节都有细节要注意。我自己的习惯是写一个deploy.sh脚本，把pull代码、装依赖、collectstatic、migrate、重启服务串起来。每次发布跑一遍，比手动敲命令靠谱得多。