基于Django的电商网站项目包：从解压到部署实战指南

简介一份基于Django框架的完整电商网站项目源码面向计算机、电子信息等相关专业的大学生可作为课程设计、期末大作业或毕业设计的直接参考。项目以Django的MTV架构为核心覆盖模型定义、ORM迁移、视图逻辑、模板渲染、URL路由等后端要点并集成商品搜索、分类浏览、购物车及第三方支付接口等电商典型功能同时包含SQL注入、XSS等安全防护实践。资源压缩包共1794个文件大小约5.86MB其中以JavaScript1075个、CSS样式表139个、Python源码137个及HTML模板38个为主辅以图片、字体等静态资源目录结构完整便于按模块查阅。该资料已有33人学习下载适合需要快速理解Django电商开发全流程、参考前端布局与后端实现细节的读者。1. 基于 Django 的电商网站压缩包不是你想象的那种“毕业设计垃圾堆”做毕设或者课程设计的人最怕的不是不会写代码而是打开一个号称“Django 电商网站”的项目包发现里面既没有商品模块也没有购物车跑起来连登录都报错。这份基于 Django 的电商网站 zip 不一样的地方在于它是冲着一句话交付去的——解压、配环境、迁移数据库、开后台然后就能在浏览器里看到完整电商流程。这个包里包含商品、购物车、订单、用户以及后台管理用的 Django Admin功能上是典型 B2C 商城的最小闭环。它适合两种人一是时间紧、任务重需要在两周内拿出可演示系统的计算机专业学生二是刚听完 Django 基础课想找一个完整项目来复盘视图、模型、模板三层是怎么配合的入门者。如果你是零基础这个包也能用但建议先补一下 Django 的 MTV 概念再来动它。接下来我会按真实拆包顺序从目录结构、环境配置、二次开发一路讲到最后交付时最容易踩的坑。2. 拆包之前先看结构电商项目的模块划分与运行前提2.1 电商项目的标准模块切分先搞清哪个 app 负责哪件事拿到压缩包后先别急着解压先看包内目录层级。一个合格 Django 电商项目至少要有四个独立 app商品、用户、购物车、订单。有的项目会把用户操作记录单独拆出来做成一个名为 operation 的 app用于记录浏览历史和收藏。模块划分遵循一个核心原则一个 app 只干一类事这样后续改需求的时候改动范围是可控的。常见的模块划分和数据关系是这样的模块核心模型负责的事关键字段goodsGoods / GoodsCategory商品列表、商品详情、分类筛选name、category、price、stock、imageuserUserProfile / UserAddress注册登录、收货地址管理username、mobile、addresscartCart / CartItem购物车增删改、数量调整goods、user、num、selectedorderOrder / OrderGoods下单、订单状态流转、订单商品快照status、total_money、order_sn、goods模块之间靠外键关联购物车条目通过外键指向商品和用户订单商品通过外键指向订单同时存一份商品名称和价格快照。为什么订单里要存快照因为下单那一刻商品的名称、价格、图片需要固定下来之后商品改价了历史订单不能跟着变。这个设计理念在答辩时被老师问到概率很高你可以顺着这个逻辑讲下去。模板的存放位置也有讲究。商品列表页、商品详情页、购物车页、订单确认页、个人中心页面会有对应的模板文件放在各自的 templates 目录下而不是全部堆在项目根目录。如果你打开项目发现共用一套基础模板 base.html说明项目已经做了模板继承这是加分项起码说明不是随手拼出来的代码。2.2 运行环境三个前提Python 版本、虚拟环境、依赖清单这个项目基于 Django 框架依赖的核心包不多但版本不匹配会让它直接罢工。建议先用以下命令确认 Python 版本Django 项目在 Python 3.6 以上才能流畅运行这里最好使用 3.8 到 3.11 之间的稳定版本。python --version # 建议输出 Python 3.8.x 或更高版本拿到项目包之后永远不要直接使用全局环境去装依赖因为你电脑上可能装了好几个项目依赖版本互相冲突到时候想排查都无从下手。正确做法是在项目根目录创建独立虚拟环境cd django-mall # 进入项目根目录manage.py 所在位置 python -m venv venv # 创建虚拟环境文件夹名为 venv # Windows 激活方式 venv\Scripts\activate # macOS / Linux 激活方式 source venv/bin/activate激活成功后命令行提示符前会出现(venv)字样。这时再安装依赖依赖只会装进这个项目的虚拟环境里不会污染全局环境Python 环境出问题也能随时删掉重建这个习惯值得长期保持。接下来安装依赖清单pip install -r requirements.txt如果项目没有 requirements.txt常见做法是自己根据项目代码逐个安装核心依赖。一个典型 Django 电商项目最少需要依赖这些Django、Pillow、mysqlclient 或 PyMySQL、django-crispy-forms。Pillow 负责处理商品图片上传mysqlclient 负责连接 MySQL如果你打算先用自带的 SQLite 跑通可以暂时不装数据库驱动。国内网络环境安装慢可在 pip 命令后面加清华镜像源速度会明显快很多。加上源之后的命令是这样的pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple这里的-i参数指定了包下载源镜像站点拥有主流 Python 包的完整副本省去你反复重试的时间。2.3 解压姿势直接影响项目能否跑起来新手在这里翻车很多人在这一步就出问题项目包是 zip 格式系统自带的解压功能有两点隐患。第一微软内置解压对文件名的编码默认识别较差项目里如果用中文命名了上传文件或静态资源目录解压后可能出现乱码目录名导致 Django 模板加载路径错误。第二解压出的文件可能被系统打上“来自其他计算机”的标记后面运行时会弹出安全确认。推荐使用 7-Zip 或 Bandizip 这类第三方工具解压右键解压到当前文件夹即可。如果系统右键菜单里没有相关选项也可以用 PowerShell 自带的 tar 命令解压tar -xf django-mall.zip这一步执行完毕项目根目录应该出现 manage.py 文件和项目同名子目录这才是正确结构。如果你解压出来只有一层嵌套目录项目文件跑到了内层运行前建议把内层内容整体移到外层否则后面输入python manage.py runserver会提示找不到 manage.py。整理好目录结构再继续。3. 把压缩包变成能访问的网站迁移、初始数据、启动三步走3.1 首要问题告诉 Django 用哪个数据库启动项目前必须确认数据库配置。打开项目同名目录下的 settings.py找到 DATABASES 配置节。如果默认配置是 SQLite那么你什么都不用改直接往下走。如果配置的是 MySQL就需要先在本机准备好 MySQL 服务再在数据库里创建一个空库不然 manage.py 执行迁移时会直接报连接错误。MySQL 8.0 在 Windows 上的安装方式可以直接用官方免安装 zip 包把 zip 解压到指定目录配置好 my.ini 文件再以管理员权限执行mysqld --initialize-insecure初始化最后执行mysqld --install注册成 Windows 服务。这些操作都依赖压缩包里的解压和初始化步骤正好和这个项目包的使用思路一致。使用 MySQL 的 Django 项目settings.py 的典型配置长这样DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: django_mall, USER: root, PASSWORD: 你自己的密码, HOST: 127.0.0.1, PORT: 3306, } }务必注意这里 NAME 字段填的是数据库名称不是表名且这个库需要提前创建好。创建数据库的命令是CREATE DATABASE django_mall CHARACTER SET utf8mb4;在终端或者 MySQL 客户端里执行都行。字符集一定选 utf8mb4不要用 utf8不然保存 emoji 表情符号时会报字符集错误。配置完成后执行迁移命令python manage.py makemigrations python manage.py migratemakemigrations 是把模型定义编译成迁移文件migrate 是把迁移文件里的操作真正落实到数据库。前端更新数据库表结构时这两条命令配合使用。执行完 migrate 后数据库会出现多张以 app 名称为前缀的数据表比如 goods_goods、order_order、user_userprofile 这些。这里说一个原则settings.py 里没有配置好数据库之前绝对不要盲目执行 migrate。常见情况是打开项目就顺手敲 migrate结果终端抛出一大堆连接错误然后开始怀疑项目包有问题。先确认配置再执行迁移顺序不能反。3.2 创建管理员账号和初始商品数据数据库迁移成功之后系统还是空的既没有管理员也没有商品数据。创建管理员账号用 Django 自带命令python manage.py createsuperuser执行后按提示输入用户名、邮箱、密码。密码要求至少八位且不能是纯数字否则会提示重新输入。创建完之后不需要额外注册这个账号默认拥有全部后台权限。接下来处理商品数据。有些项目会在压缩包里带一个 fixtures 目录里面放初始数据文件。导入初始数据用python manage.py loaddata initial_data.jsonfixtures 数据文件是 Django 通过 dumpdata 命令导出的loaddata 导入时会自动处理外键关联关系所以导入顺序不用你操心。导入完成后在浏览器里访问后台地址127.0.0.1:8000/admin就能看到刚才创建的管理员登录界面登录进去商品列表里已有数据。如果项目包里没有附带数据文件你也不必手动一条一条在页面里添加。写一个临时脚本在 Django shell 里批量造数据即可# 创建临时数据脚本用 manage.py shell 执行 python manage.py shell EOF from goods.models import GoodsCategory, Goods from django.contrib.auth import get_user_model User get_user_model() admin_user User.objects.filter(is_superuserTrue).first() print(当前管理员:, admin_user) category, _ GoodsCategory.objects.get_or_create( name数码产品, defaults{desc: 演示分类} ) for i in range(1, 6): Goods.objects.get_or_create( namef演示商品-{i}, defaults{ category: category, price: 99.00 i, stock: 100, } ) print(商品创建完成) EOF代码逻辑是复习 ORM 查询和创建对象的好机会get_or_create 先执行查询查不到再执行创建defaults 字典里放除查询条件以外的字段值。循环里生成五个商品名称和价格保证首页商品列表不是空白。这个脚本执行完可以在后台查看也可以直接访问前台商品列表确认。3.3 启动服务并验证三个入口前台首页、商品详情、后台管理数据就绪后启动开发服务器python manage.py runserver默认监听 8000 端口浏览器访问127.0.0.1:8000。看到首页商品列表后逐个验证以下入口验证入口访问地址预期效果商品列表127.0.0.1:8000显示五个商品卡片和价格商品详情127.0.0.1:8000/goods/1/显示该商品完整信息图片能正常加载Django 后台127.0.0.1:8000/admin管理员登录成功能操作商品和订单这里先记住一个验证标准如果商品详情页里的图片裂开了先去看控制台静态文件 404 报错这是后续避坑章节要处理的高频问题。三个入口都正常后项目才算真正跑通后面的二次开发也才有基础。开发服务器显示页面底部有 Debug 工具栏属于正常现象交付前再关闭就好。4. 能跑起来只是开始商品、购物车、订单这三个模块怎么改4.1 商品详情页的 URL 设计反查 URL 是模板里的隐藏考点商品列表页打开后商品标题是可点击链接点击后进入详情页。这里面 URL 路由设计很关键。现代 Django 推荐使用 path 函数而不是老式正则路由商品详情的路由定义通常长这样# urls.py 文件 from django.urls import path from goods import views urlpatterns [ path(goods/int:goods_id/, views.goods_detail, namegoods_detail), ]int:goods_id表示 URL 中这一段是整数Django 会自动校验类型并传给视图函数。view 函数接收参数后查询商品对象# goods/views.py 文件 from django.shortcuts import render, get_object_or_404 from .models import Goods def goods_detail(request, goods_id): goods get_object_or_404(Goods, idgoods_id) return render(request, goods/detail.html, {goods: goods})模板里指向详情页的写法优先使用 name 反查而不是硬编码 URLa href{% url goods_detail goods.id %}{{ goods.name }}/a这样做的价值在于如果哪天 URL 规则变了比如加了一个语种前缀后台代码不需要跟着改模板会根据 name 自动生成新地址。新手最容易犯的错是在模板中直接写死/goods/1/一旦商品 ID 变成两位数还能跑但改成其他路由规则就会全部失效。答辩时老师大概率也会问“URL 怎么管理”你直接回答用的是反向解析比解释半天路由正则要加分。如果你要新增一个商品分类功能需要新建 app 而不是在现有项目里硬塞代码。执行命令python manage.py startapp category创建完成后把 category 加入 settings.py 的 INSTALLED_APPS 列表再去 category/models.py 里写模型。创建 app 本身不复杂但漏掉 INSTALLED_APPS 注册是最常见的新手错误后续加菜单、加页面全部不会生效。4.2 购物车实现方式先看懂它是存 Session 还是存数据库课程设计级别的购物车实现方式有两种。一种是完全基于 Session把商品 ID 和数量存在用户浏览器会话里未登录也能加购下单时再写入订单表。另一种是数据库购物车表购物车条目落库需要通过用户外键关联查询。两种方案各有取舍Session 方案不需要建表数据临时存储换台电脑购物车就没了数据库方案能保存用户购物车状态但需要处理用户未登录时的临时购物车合并逻辑。拿到这个项目包你可以用一条命令查看它的购物车实现方式python manage.py shell from cart import models as cart_models import inspect print(cart_models.__file__)打开该 app 的 models.py 文件看里面是否定义了 Cart 或者 CartItem 数据模型。如果定义了说明走的是数据库方案如果整个 cart app 只有 views 和 urls没有 models 定义那它大概率是 Session 方案。我在实际使用中更建议数据库方案理由很简单毕业设计演示时需要向老师展示数据持久化Session 方案刷新页面后一旦过期购物车内容就没了现场演示翻车风险高。数据库方案还能在 Django 后台直接看到购物车数据方便你给老师展示“看这里能看到某用户的购物车记录”。购物车表的设计核心字段通常是这样# cart/models.py 示例 class CartItem(models.Model): user models.ForeignKey(user.UserProfile, on_deletemodels.CASCADE, verbose_name用户) goods models.ForeignKey(goods.Goods, on_deletemodels.CASCADE, verbose_name商品) goods_num models.IntegerField(default1, verbose_name购买数量) is_selected models.BooleanField(defaultTrue, verbose_name是否勾选)这里注意 user 字段用的是字符串引用而不是直接 import 模型类好处是避免循环导入问题。goods 和 user 都是外键当主表记录被删除时on_deletemodels.CASCADE级联删除购物车里的对应条目这是订单场景下的合理预设。当购物车里的商品要删除对象时ORM 的操作是刷掉一行代码的事CartItem.objects.filter(userrequest.user, goods_idgoods_id).delete()filter 先定位符合条件的记录然后执行删除最后返回被删条数。Django 执行查询-删除对象有一套固定的链式方法在 shell 里反复多试几次就能熟悉套路。核心原则是明确过滤条件条件写得太窄删不掉写得太宽会误删数据。上面的示例用了两个过滤条件当前用户和商品 ID范围是精准的。4.3 订单状态流转用状态整数字段和 Django Admin 把流程撑起来订单模块是整个项目里最容易在答辩时出彩的部分。订单状态一般用整数表示因为 Django 默认的 choices 字段加上状态中文映射后后台会显示下拉框操作起来非常直观。常见状态设计如下状态整数值状态含义后台显示0待支付橙色标签1已支付待发货蓝色标签2已发货绿色标签3已完成灰色标签4已取消红色标签模型里这样定义# order/models.py 示例 class Order(models.Model): STATUS_CHOICES ( (0, 待支付), (1, 待发货), (2, 待收货), (3, 已完成), (4, 已取消), ) order_sn models.CharField(max_length30, verbose_name订单编号) user models.ForeignKey(user.UserProfile, on_deletemodels.CASCADE, verbose_name下单用户) total_money models.DecimalField(max_digits9, decimal_places2, verbose_name订单总价) status models.SmallIntegerField(choicesSTATUS_CHOICES, default0, verbose_name订单状态) create_time models.DateTimeField(auto_now_addTrue, verbose_name下单时间)header 状态流转的逻辑是用户提交订单生成待支付记录支付成功后台把状态改成 1商家发货改成 2用户确认收货改成 3。但真实商城支付需要接入支付宝或微信支付这在毕设里不现实完整的演示一般用 Django Admin 手动改状态来代替支付回调。把订单模型注册进 Django Admin 后在后台可以直接筛选不同状态的订单这对老师演示非常直观。注册代码很简单# order/admin.py 示例 from django.contrib import admin from .models import Order admin.register(Order) class OrderAdmin(admin.ModelAdmin): list_display (order_sn, user, total_money, status, create_time) list_filter (status,) search_fields (order_sn,)list_display控制后台列表展示哪些列list_filter在右侧生成状态筛选器search_fields让订单号可搜索。这三行配置就能把订单列表变得像一个真实的运营后台。答辩演示时演示完前台下单再切到后台把订单状态从“待支付”改成“待发货”既展示了前后端配合又能解释状态字段的意义这套动作几乎不会有冷场。5. 避坑专场跑 Django 电商项目最容易翻车的五个真实原因5.1 商品图片全部裂开控制台输出大量静态文件 404现象是后台能登录商品名称和价格都正常但每张商品图都显示破碎图标浏览器控制台 Network 里全是.css、.jpg、.js请求返回 404。原因有三个按概率从高到低排。第一模板文件头部缺少静态文件加载声明你根本没有用{% load static %}。第二settings.py 里 STATIC_URL 配置错误或者没配置。第三项目使用 DEBUGFalse 运行Django 默认不会处理静态文件路径。解决方式分两步。先确认 settings.py 里的静态文件配置这是最常用的一段配置# settings.py STATIC_URL /static/ STATICFILES_DIRS [ BASE_DIR / static, ]再检查模板底部或顶部有没有加载静态文件指令{% load static %} img src{% static images/goods/1.jpg %} alt商品图片static 写法会把图片路径映射成/static/images/goods/1.jpg与 STATIC_URL 匹配浏览器才能按这个路径找到文件。顺便检查一下项目里是否有 static 目录且图片真实存在很多压缩包解压后目录完整但图片体积被阉割或路径被改成绝对路径也会失效。5.2 执行 migrate 时提示 table already exists 或 duplicate column name现象是重新配置数据库后跑 migrate结果刷出一堆报错提示某张表已存在或者某一列重复添加。原因是数据库不是全新的可能是你之前执行过一次 migrate表结构已经创建也可能是项目包作者导入了 sql 文件表结构与 Django 迁移记录不匹配。第二种情况最常见数据库有表但 django_migrations 表没有对应记录Django 认为这些表不存在尝试重建时就和已有表冲突。解决方法是先确认当前数据库是否有业务数据需要保留。如果不需要保留直接删库重建最干净在 MySQL 中执行DROP DATABASE django_mall;再重新CREATE DATABASE django_mall CHARACTER SET utf8mb4;然后重新 migrate。需要保留数据时可以查看迁移记录和实际表结构的关系但作为课程设计删库重来反而更快不影响最终交付。注意血泪经验是迁移报错的时候看报错前几行它会告诉你具体冲突的表名比你想省事去百度整段报错要准确得多。5.3 安装 mysqlclient 永远失败报错 Microsoft Visual C 14.0 is required现象是在 Windows 上执行pip install mysqlclient长时间无响应或直接编译报错提示缺少 Visual C 编译器。原因是mysqlclient 有 C 扩展Windows 上需要对应版本的编译工具链机器上没有编译工具时安装必然失败。这不是项目代码的问题是依赖包本身跨平台编译的兼容性问题PyMySQL 是更亲和的替代。解决方式Django 在连接 MySQL 时通常使用 MySQLdb 这个名字PyMySQL 提供兼容接口可以把域名替换过来让它伪装成 MySQLdb。在项目主目录的__init__.py文件中加入两行代码# 项目目录下的 __init__.py import pymysql pymysql.install_as_MySQLdb()然后把 mysqlclient 从 requirements.txt 里删掉改为安装并依赖 pymysql在 requirements.txt 中写上pip install pymysql之后重新执行 migrate数据库可以正常连接。这个方法在很多实战项目里都用得上属于不用买后悔药就能解决的问题。顺手把 pandas 之类的 C 扩展相关包先装好避免后面再踩一次编译坑。5.4 解压报错或目录名变成乱码现象是解压 zip 包过程中提示 CRC 校验失败或者解压出来目录名像是编码错误例如locale乱码。原因是压缩包在传输过程被截断或损坏这是最糟糕的情况另一种情况是解压软件没正确处理 ZIP 文件的 UTF-8 编码标识Windows 自带解压对此支持不好。解决方式分两种先重新下载 zip 包确认文件大小与发布方给的官方大小一致。如果确认文件完整但解压出来依然乱码用 7-Zip 打开压缩包手动复制内层目录到目标路径。tar 命令在 PowerShell 里也可以解压它能保留一部分编码标记。操作完成后进入项目目录手动检查一下 manage.py 路径下是否存在非 ASCII 字符路径。我习惯把解压后的项目整体放在纯英文路径下比如D:\workspace\django-mall避免 Windows 对中文字符路径做特殊处理这也是很多新手项目名带中文导致报错的根源。万一路径里有中文导致模板加载失败就用这个方法处理控制变量去排除。5.5 提交订单时 403 Forbidden或 POST 请求被拦截现象是商品列表正常、购物车正常但点击“提交订单”按钮后页面弹出 403 错误或者直接 500 报错。原因是Django 内置了 CSRF 保护机制表单里缺少{% csrf_token %}令牌或者在提交 POST 请求时视图函数抛了异常而 Request 对象不存在相应的判断。模板表单里没带令牌是新手最经典的翻车点。解决方式是在所有form表单内部第一行加入模板标签form methodpost action{% url create_order %} {% csrf_token %} !-- 其他表单字段 -- /form加入后在模板渲染时 Django 会自动生成一个隐藏的 csrfmiddlewaretoken 字段服务端验证通过后请求才会进入视图函数。如果仍然 500打开 runserver 终端的完整堆栈最后一行会指出行号与异常类型。新手最容易忽略的细节是订单明细列表在 POST 后没有取到购物车 session 被 clear 掉导致写入空订单数据。这类问题本质上是代码执行顺序先查数据库里的订单记录数量再对照终端日志发生顺序就能定位。6. 交付前最后一次验证从空数据库开始四十分钟走完完整回归毕业设计答辩有个铁律不要在开发环境上演示要在验收环境上走一遍完整链路。最有效的验证方法是把当前数据库整个清掉然后从最原始状态重新走一遍流程。这样能暴露所有和静态数据、默认配置相关的问题这些在开发环境长期运行中早已被掩盖。我用得最多的做法是写一个简单的一键验证脚本跑一遍核心页面响应状态不依赖浏览器也能快速确认服务正常# verify.py用 Django 自带的测试客户端做冒烟测试 import os import django os.environ.setdefault(DJANGO_SETTINGS_MODULE, django_mall.settings) django.setup() from django.test import Client c Client() urls [/, /goods/1/, /cart/, /user/login/] for url in urls: resp c.get(url) print(f{url} - {resp.status_code})脚本用 Django test client 分别请求首页、商品详情、购物车页面把 HTTP 状态码打印出来。200 代表可访问404 代表该排查路由500 代表视图有异常。这个脚本要求数据库里商品 ID 为 1 的记录存在如果你的初始数据第一个商品 ID 不一定是 1就把goods/1/换成实际 ID。跑出来全 200 再进浏览器手动操作一遍重点链路。有一个点容易被忽略Django 的 test client 默认不会执行真实数据库写入它会用内存镜像数据库跑测试因此这张验证不会污染你现有的演示数据。这个冒烟脚本的价值是让你在临时环境里用最快速度确认服务是否可用。完整交付检查清单如下顺序检查项通过标准1全新数据库 migrate数据库表创建无报错2导入初始数据或造数后台能看到商品分类和商品3runserver 启动首页商品列表渲染正常4用户注册登录注册成功并跳转至个人中心5商品加购物车购物车数量 16下单并确认订单订单状态为待支付7后台修改订单状态状态流转正常8停服重启数据不丢失说一个我自己经历过的教训。有一年我拿一个 Django 商城项目做公开演示开发环境跑了一个月一切正常结果演示当天用的是另一台机器数据库是全新的我自信过头没有从头跑一遍。打开首页之后商品分类和商品列表全是空白因为没有导入初始数据。当场整个人都蒙了只能一边解释“让我看下数据库”一边手动补数据体验非常狼狈。从那以后我养成了强制习惯每交付一个 Django 项目不管时间多赶至少从空数据库到首页数据完整展示这套流程必须完整跑一遍跑不完宁愿晚点交付也不提前结束。写这篇文章时我又把这份 zip 包从头按这个顺序解压跑了一次希望帮到你。本文还有配套的精品资源点击获取