简介面向 Linux 部署环境的 Django 大型前后端商城项目基础架构包适合具备一定 Python 基础、想系统理解电商网站开发的读者。项目未集成支付宝与短信接口重点落在商品、订单、用户等核心业务实现便于专注学习 Django 在电商领域的建模与交互流程。压缩包共 204 个文件约 1.69MB99 个 Python 文件承载模型、视图与配置逻辑30 个 HTML 模板覆盖商品详情、购物车、结算等页面另有 JS、CSS、图片及 SQL 初始化脚本用于前端交互、样式与数据导入已有 231 人浏览学习。借助该资源可从零搭建商城雏形完整走通从环境配置、项目结构规划、模型设计、URL 路由、模板页面、用户认证、性能优化、测试到 GunicornNginx 部署的完整链路同时理解虚拟环境隔离、settings.py 数据库配置、模型与模板分离等 Django 开发要点。目录中的 manage.py、shopping_mall 主应用和 requirements.txt 等文件结构清晰方便二次开发与扩展。1. Linux 部署 Django 商城别把本地跑通当生产可用真正把一套 Django 商城从本地 Windows 迁到 Linux 云服务器那天我花了整个下午排查静态文件 404——页面全部正常CSS、JS 却一张都加载不出来。原因不是代码写错而是本地 runserver 自动托管静态文件换到生产部署后没人管了。这套 linux 部署环境下 django 大型前后端商城正好是把这条坑走完整后的产物商品、购物车、订单、支付、用户中心五个业务模块齐全Nginx 负责静态托管与反向代理Gunicorn 接管 Django 应用MySQL 存业务数据Redis 做缓存与 Session 共享。适合两类人刚掌握 Django 想看看完整商城长什么样的新手以及部署过两三次但总在静态文件和进程管理上翻车的开发者。读完后你能把项目跑起来也能讲清楚每一层为什么存在。2. 项目全景拆解五大业务模块与三层服务架构2.1 架构分层Nginx、Gunicorn、Django 之间到底怎么分工这套商城采用前后端分离加服务端渲染混合的务实方案页面由 Django 模板或前端构建产物渲染接口走 Django REST Framework 提供 JSON 数据二者都跑在同一个 Django 应用里由 Gunicorn 启动多个 worker 进程承载。Nginx 在最前面接收浏览器请求静态文件CSS、JS、图片由 Nginx 直接返回API 和页面请求反向代理到 Gunicorn。之所以不让 Nginx 直接访问 Django是因为 Django 本身不擅长高并发连接处理Gunicorn 作为 WSGI 应用服务器更合适。横向看业务数据全部落在 MySQLRedis 承担三件事缓存热门商品、保存购物车、共享用户 Session。纵向看用户请求的链路是 Browser → Nginx → Gunicorn → Django → MySQL/Redis每一层职责单一出问题时能快速锁定。下面这个目录结构是典型的 Django 大型项目布局把业务代码全部收敛在 apps 目录下商城项目/ ├── manage.py ├── config/ # 项目配置settings、urls、wsgi ├── apps/ │ ├── users/ # 用户中心注册登录、收货地址、个人信息 │ ├── goods/ # 商品模块分类、详情、搜索、热门推荐 │ ├── carts/ # 购物车模块增删改查、勾选状态 │ ├── orders/ # 订单模块下单、订单详情、状态流转 │ └── payment/ # 支付模块支付接口对接与回调处理 ├── utils/ # 通用方法分页、加密、序列化器基类 ├── static/ # 前端静态资源打包产物 ├── media/ # 用户上传的图片、文件 ├── requirements.txt └── .env.example # 环境变量模板复制后改名 .env 使用把业务拆到 apps 下而不是全部塞进一个 app是我见过的大多数商城项目的做法。这样每个模块独立迁移、独立测试二次开发时改动一个模块不会牵连其他模块。config 目录只放公共配置和根路由相当于整个项目的“总闸”。2.2 业务模块设计商品、购物车、订单、支付的数据流转先看商品模块。商品表设计成两级分类加 SPU/SKU 两层结构SPU 是商品抽象比如某款手机SKU 是具体售卖规格如 8GB256GB 黑色版本价格、库存都挂在 SKU 上。列表页和详情页的数据都通过 Redis 做缓存缓存 key 按goods:detail:{sku_id}组织商品更新时主动删除缓存而不是设置固定过期时间这样能保证详情页最多延迟几秒就能看到后台改动。购物车模块是这套系统里对 Redis 依赖最重的一块。未登录用户用 cookie 存购物车登录后合并到 Redis 哈希结构中key 为cart:user:{user_id}field 为 SKU IDvalue 为数量。登录合并的核心代码大概是这个样子def merge_cart(user_id, session_cart): cart_key fcart:user:{user_id} for sku_id, count in session_cart.items(): redis_client.hincrby(cart_key, sku_id, count) return redis_client.hlen(cart_key)hincrby是 Redis 哈希的原子自增操作能避免并发下数量被覆盖。这里的参数session_cart是用户未登录期间存在 cookie 里的购物车字典key 为 SKU ID、value 为数量cart_key的冒号是 Redis 社区习惯的命名空间分隔方式方便按用户维度批量查询。合并后客户端会同步清除 cookie 购物车此后所有购物车操作都走 Redis。订单生成是整个系统的事务核心。用户从购物车勾选商品点击结算时后端先锁住 Redis 里的库存再创建订单记录、扣减 MySQL 库存、清空购物车对应项。这三个动作必须在一个数据库事务里完成任一步失败都要整体回滚。这里有个细节库存扣减不能用“先查再更新”的方式否则并发下单会超卖正确做法是 Django ORM 的原子更新SKU.objects.filter(idsku_id, stock__gtecount)\ .update(stockF(stock) - count)stock__gtecount是查询条件要求当前库存大于等于购买数量F(stock) - count让数据库在读取旧值后直接做减法整个过程在数据库层面完成不经由 Python 进程避免并发下“读到相同旧值”的经典问题。F表达式是 Django 提供的数据库列引用语法这里用于保证扣减的原子性。3. 本地跑起来venv、MySQL 与数据初始化的完整步骤3.1 环境基础创建 venv 并安装项目依赖拿到源码后的第一步不是急着看代码而是先把依赖环境搭起来。项目基于 Python 3.10 以上版本开发进入项目根目录后依次执行以下命令python3 -m venv venv source venv/bin/activate pip install -r requirements.txt第一行创建虚拟环境目录 venv第二行激活它第三行安装依赖。注意后面所有命令都要在激活状态下执行如果终端提示符前面出现(venv)就说明环境已经生效。requirements.txt 里锁定了 Django、Django REST Framework、gunicorn、redis、celery、mysqlclient 等核心库的版本范围安装完成后可以用pip list确认关键包是否就位。如果 pip 安装 mysqlclient 时报错缺少编译环境常见做法是先在系统层安装依赖再重试。在 Debian/Ubuntu 系系统上执行apt install python3-dev default-libmysqlclient-dev build-essential安装完成后再跑一次 pip 命令即可。3.2 配置环境变量与数据库.env 管理敏感参数项目根目录里有一个.env.example文件复制一份改成.env然后把里面的值改成你本机的实际配置。这是这个项目最值得借鉴的习惯所有敏感信息——数据库密码、SECRET_KEY、Redis 地址——都不写死在 settings.py 里而是通过环境变量注入settings.py 里用os.getenv()读取。cp .env.example .env vim .envSECRET_KEYyour-django-secret-key DEBUGTrue ALLOWED_HOSTS127.0.0.1,localhost DB_NAMEshop DB_USERroot DB_PASSWORDyour-mysql-password DB_HOST127.0.0.1 DB_PORT3306 REDIS_URLredis://127.0.0.1:6379/1需要提前在 MySQL 里创建好名为 shop 的数据库字符集选择 utf8mb4否则中文商品名会出现乱码。创建语句很简单CREATE DATABASE shop CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;Redis 默认配置是本地无密码访问如果你本机设置了密码.env里的 REDIS_URL 要写成redis://:密码127.0.0.1:6379/1这种带授权信息的格式。这一步容易踩坑后面第 5 章我会单独展开排查过程。3.3 初始化数据并启动开发服务配置完成后就是数据库迁移和创建管理员账号。Django 的迁移机制会把 apps 下各模块的数据表结构同步到 MySQLpython manage.py migrate python manage.py createsuperuser python manage.py runserver 0.0.0.0:8000migrate执行后可以用SHOW TABLES;在 MySQL 里确认数据表是否创建成功createsuperuser按提示输入用户名、邮箱、密码即可。runserver 0.0.0.0:8000表示监听所有网卡的 8000 端口这样局域网内其他机器也能访问。浏览器打开http://127.0.0.1:8000能看到商城首页访问/admin/用刚才创建的管理员登录后台。如果首页商品为空可以进入 Django 后台手动添加分类、SPU、SKU 和图片。商品图片存放在 media 目录本地开发时 Django 会自己服务这个目录不需要额外配置。到这里本地已经能完整跑通商品浏览、购物车、下订单的全流程了。4. Linux 生产部署实战Nginx 托管静态、Gunicorn 接管接口、systemd 兜底进程4.1 收集静态文件并交给 Nginx本地 runserver 会自动处理静态文件但生产环境必须把散落在各 app static 目录里的资源统一收集到一个目录再交给 Nginx 托管。Django 提供了现成命令只需要在 settings.py 里配置好 STATIC_ROOTSTATIC_URL /static/ STATIC_ROOT BASE_DIR / staticfiles STATICFILES_DIRS [BASE_DIR / static]STATIC_URL 是浏览器访问静态资源的 URL 前缀STATIC_ROOT 是 collectstatic 输出目录STATICFILES_DIRS 是额外的前端构建产物目录。执行收集命令python manage.py collectstatic --noinput完成后项目根目录会生成 staticfiles 目录里面是所有静态资源的汇总。这个目录要一直保持在服务端不要随意移动Nginx 配置会指向它。4.2 Gunicorn 多进程启动 Django开发模式下 runserver 是单进程且自带自动重载不适合生产环境。项目使用 Gunicorn 作为 WSGI 服务器它以多 worker 方式启动 Django 应用。先在项目目录里试运行一次确认参数venv/bin/gunicorn config.wsgi:application -w 4 -b 127.0.0.1:8001 \ --max-requests 1000 --max-requests-jitter 100-w 4表示启动 4 个 worker 进程能同时处理 4 个请求-b 127.0.0.1:8001让 Gunicorn 只监听本机 8001 端口不直接暴露给外网--max-requests是每个 worker 处理 1000 个请求后自动重启--max-requests-jitter 100加上随机浮动避免多个 worker 同时重启造成服务抖动。这里 Gunicorn 监听 127.0.0.1 是刻意的外部流量必须经过 Nginx 转发到 8001不给自己留绕过 Nginx 的入口。worker 数量不是越多越好常见做法是 CPU 核心数的 2 到 4 倍。如果云服务器是 2 核4 个 worker 已经够用开太多反而会因上下文切换降低吞吐。4.3 systemd 托管进程与开机自启裸跑 Gunicorn 的问题在于进程一断就没人管了服务器重启后服务也不会自动起来。生产环境的通用做法是用 systemd 把 Gunicorn 注册成系统服务。在/etc/systemd/system/下创建商城服务的 unit 文件[Unit] DescriptionShop Django Application Afternetwork.target mysql.service redis.service [Service] Typenotify Userwww-data Groupwww-data WorkingDirectory/home/www/商城项目目录 EnvironmentFile/home/www/商城项目目录/.env ExecStart/home/www/商城项目目录/venv/bin/gunicorn config.wsgi:application \ -w 4 -b 127.0.0.1:8001 --max-requests 1000 --max-requests-jitter 100 Restartalways RestartSec5 [Install] WantedBymulti-user.targetUserwww-data指定运行用户避免用 root 跑业务进程EnvironmentFile指向项目里的 .env这样 Gunicorn 启动时会把变量注入进程环境Restartalways是崩溃后的自动重启策略RestartSec5表示等 5 秒再拉起。保存后执行systemctl daemon-reload systemctl enable shop.service systemctl start shop.service systemctl status shop.serviceenable让服务随系统启动start立即启动status查看运行状态。如果 status 显示 activerunning说明 Gunicorn 已经稳定跑起来了。4.4 Nginx 反向代理与静态托管配置最后一步是 Nginx。它在整个架构里同时承担两个角色静态文件服务器和反向代理。配置一个 server 块指向商城域名的 80 端口server { listen 80; server_name shop.example.com; # 静态托管直接返回文件不经过 Django location /static/ { alias /home/www/商城项目目录/staticfiles/; expires 7d; } location /media/ { alias /home/www/商城项目目录/media/; expires 30d; } # 动态请求反向代理到 Gunicorn location / { proxy_pass http://127.0.0.1:8001; 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; } }location /static/和location /media/匹配到的请求由 Nginx 直接读取磁盘返回expires 7d告诉浏览器缓存 7 天location /把所有其他请求转发给本机 8001 端口的 Gunicorn。X-Forwarded-For是链路里最重要的请求头——Django 需要靠它才能拿到用户真实 IP如果少配了这行所有日志里的 IP 都会变成 127.0.0.1。Nginx 还有一层容易被忽略的配置gzip 压缩。商城首页的 JS 和 CSS 动辄几百 KB开启 gzip 能让传输体积缩小到原来的四分之一左右。在 server 块里加上这几行gzip on; gzip_types text/plain text/css application/javascript application/json; gzip_min_length 1024;改完配置执行nginx -t检查语法通过后systemctl reload nginx即可生效。到这里整个链路就通了用户访问 80 端口Nginx 根据请求路径分发到静态目录或 GunicornPHP 时代的 Nginx FastCGI 思路在这里换成了 Nginx WSGI。5. 部署排查实录静态文件 404、Session 掉线与商品图片上传失败5.1 静态文件全丢collectstatic 没跑或者路径不一致现象部署完成后点击任意页面HTML 正常渲染但所有 CSS、JS 全部 404页面惨不忍睹。原因有两种一是上线流程里漏掉了collectstatic --noinputstaticfiles 目录根本不存在二是 runserver 时代 Django 会自动找各 app 下的 static 目录但 Nginx 只认配置里写的那个 alias 路径两边对不上。解决进入项目目录执行收集命令再确认 Nginx 配置里的 alias 路径和 STATIC_ROOT 指向同一目录。我自己的习惯是部署脚本中强制把collectstatic放在迁移之后、重启服务之前少一步都不发版。5.2 后台 Session 频繁失效多 worker 的会话表选择不当现象用户登录商城没几分钟就被踢回登录页Gunicorn 日志里没有报错。原因默认情况下 Session 存在本地文件里Gunicorn 起了 4 个 worker用户请求可能落在任意 worker 上上一个 worker 写的 Session 文件下一个 worker 读不到。解决把 Session 存储切到 Redis单点存储多进程共享。在 settings.py 里配置SESSION_ENGINE django.contrib.sessions.backends.cache SESSION_CACHE_ALIAS default这样所有 worker 共享同一个 Redis 中的 Session key。配置完后重启 Gunicorn用两个浏览器同时测试登录态是否稳定能复现问题才说明修好了。5.3 商品图片上传 413 Request Entity Too Large现象后台添加商品时图片小于几百 KB 能传超过 1 MB 就报 413。原因Nginx 默认client_max_body_size是 1 MB商品原图很容易超。解决在 Nginx 的 server 块里调整限制。client_max_body_size 10m;同时确认 Django 侧没有额外限制默认情况下 Django 对请求体没有硬性大小限制改完 reload Nginx 即可生效。这个坑不疼不痒但遇到时很耽误时间我第一次遇到差点去调 Django 的DATA_UPLOAD_MAX_MEMORY_SIZE其实根本不是那层的问题。5.4 Celery 任务一直 PENDINGworker 没起来或 Redis 连不上现象下单后界面提示成功但异步发出的通知邮件一直没有Celery 监控后台任务永远停在 PENDING 状态。原因Celery worker 进程和主应用是两套进程很多开发者只部署了 Gunicorn 忘了启动 worker排查时发现 worker 确实起了但连不上 Redis日志里是连接拒绝。解决先确认 Redis 在线再用 systemd 单独托管 Celery worker[Service] WorkingDirectory/home/www/商城项目目录 ExecStart/home/www/商城项目目录/venv/bin/celery -A config worker -l info Restartalways启动后用手动调用方式验证任务能被执行再回到业务里测试完整链路。这里的原则是异步任务一定是独立进程部署清单里必须把 Gunicorn、Nginx、Celery worker 三者并列缺一不可。5.5 接口返回时间飘忽不定Redis 缓存穿透现象商品详情页有时候几十毫秒打开有时候要等两三秒流量一大更明显。原因热点商品有缓存但搜索接口每次请求都直接查 MySQL没有设置缓存防线。解决给高频只读接口加一层 Redis 缓存key 按查询条件拼接同时设置 5 到 10 分钟的过期时间再配合页面静态化缓存碎片详情页稳定在百毫秒内。这类问题在本地看不出来只有压测或上线后才有体感部署完最好先跑一轮ab -n 1000 -c 20看看吞吐量是否平滑。6. 二次开发指南把普通商品页改造成限时秒杀6.1 秒杀模块设计Redis 预扣库存 异步落单如果要在商城里加一个限时秒杀频道最直接的做法是在 SKU 表上增加秒杀字段但纯数据库方案会在高并发下崩。我建议沿用项目现有的 Redis 基础设施做两级库存设计。先在 goods 模块扩一张秒杀配置表字段包含 SKU ID、秒杀价格、开始时间、结束时间、秒杀总库存。启动时把库存预热到 Rediskey 为seckill:stock:{sku_id}下单接口变成这样def create_seckill_order(sku_id, user_id): stock_key fseckill:stock:{sku_id} remaining redis_client.decrby(stock_key, 1) if remaining 0: redis_client.incr(stock_key, 1) # 超卖回补 raise BusyError(已抢完) # 异步创建订单避免阻塞请求 celery_app.send_task( apps.orders.tasks.create_order_from_seckill, args[sku_id, user_id], ) return 抢购成功decrby是 Redis 的原子减操作必须配合incr回补逻辑防止超卖这里先扣减再落库把真正的订单写入放到 Celery 异步任务里接口响应能控制在毫秒级。异步任务里需要重新校验商品信息并创建订单记录同时扣减 MySQL 库存整个流程用事务包裹。6.2 验证方式与回滚预案改造完成后先写一个简单的压测脚本模拟 500 个用户同时抢同一个 SKU断言最终订单总数不超过秒杀库存。除了功能正确性秒杀最关键的是 Redis 里剩余的键不能为负数且 MySQL 库存最终与 Redis 预热值相等。上线时建议用 Django 的 feature flag 或简单的配置开关控制秒杀频道是否展示出问题可以秒级下线不用回滚代码。从那次静态文件 404 之后我每次部署 Django 项目都强制走一遍同样的流程collectstatic → 启动 Gunicorn → systemd 托管 → Nginx reload → 全链路自测。这套商城项目的部署文档和配置是我反复踩坑后沉淀下来的拿来跑通再改成你自己的业务希望帮到你。本文还有配套的精品资源点击获取