简介这是一份基于 Python Django 框架开发的商城项目完整源码定位为后端入门与实战参考适合正在学习 Web 开发、准备课程设计或毕业设计的开发者。项目包含商品展示、用户登录、购物车、订单等常见电商模块前端页面和后台逻辑齐全可帮助读者理解 Django 的 URL 路由、模型设计、模板渲染和视图编写方式。资源文件共 403 个压缩包大小 33.44MB其中 53 个 Python 源码文件是项目主体覆盖核心业务逻辑293 张商品与页面图片用于商城展示另有 11 个 HTML 模板、8 个 CSS 样式、6 个 JavaScript 脚本及 JSON/XML 配置和说明文档目录结构清晰便于按功能模块查阅和二次开发。目前已有 3687 人学习下载适合具备一定 Python 基础、想通过完整项目快速掌握 Django 开发流程的读者。解压后可直接对照源码学习也可基于现有模块扩展功能对梳理电商业务逻辑和项目组织方式有明确帮助。1. 拿到Django商城项目源码.zip先别急着双击解压打开这个zip包之前先想清楚一个问题你要的是“跑起来看看效果”还是一个能改、能上线、能拿去找工作的Django商城项目源码这个zip解压之后就是一个完整的Django商城工程里面通常带着models、views、admin和一组初始数据目的就是让你在本地把它跑成一个能登录后台、能管理商品订单的小商城。它适合两种人一是刚学完Django基础、正需要项目实战新手案例的人二是要在已有Django项目里抄一套商城模块设计的人。但别指望双击解压就能访问页面——真正的门槛在数据库迁移、依赖安装和静态文件这三关。2. 解压到跑通先看懂manage.py身边那堆文件在干什么2.1 解压前先确认两件事Python版本与Django版本这个zip是源码包不是安装包里面没有可以直接双击运行的exe。第一步必须是确认本机Python环境。常见的商城项目是基于Python 3.6到3.10写的Django版本多数在2.2到4.2之间。你先在命令行里敲两个命令python --version # 输出示例Python 3.10.12 # 如果没反应试试 python3 --versionWindows下也可以检查 py --version pip show django # 输出示例Name: Django Version: 4.2.5 # 如果什么都没显示说明Django还没装拿到这两个版本号后再解压。为什么顺序不能反因为Django的版本和Python版本是强绑定的比如Django 2.2在Python 3.10上会有兼容警告Django 4.2则要求Python 3.8起步。很多翻车现场就是版本对不上源码包本身没问题环境先把你卡死了。如果Django还没装我给的标准做法是先建虚拟环境再装依赖别直接pip install到全局。python -m venv venv # Windows下激活 venv\Scripts\activate # macOS / Linux下激活 source venv/bin/activate # 激活后终端前面会出现(venv)字样说明你已经在虚拟环境里了激活虚拟环境这一步是血泪经验换来的。商城项目再小也至少有十几个第三方依赖直接装全局很容易和系统里其他项目打架。Python项目实战新手最容易忽略这个等到依赖冲突再回头补救比一开始就建环境痛苦得多。2.2 项目结构里的三个“老熟人”配置文件、路由和App把zip解压之后用文件管理器或者命令行看一眼根目录。一个标准Django商城项目的结构基本长这样find . -maxdepth 2 -type d | sort # 输出类似 # ./mall # ./mall/settings # ./mall/urls.py # ./apps # ./apps/goods # ./apps/order # ./apps/user # ./static # ./templates这里的mall是项目配置目录里面放着settings.py、urls.py。apps目录下面通常是按业务拆的App比如goods管商品、order管订单、user管用户。注意这里有个常见做法商城项目里开发者习惯用apps/做包名然后在settings.py里把App的路径注册进去而不是直接用顶层目录。你需要打开settings.py重点看三块# settings.py 节选 INSTALLED_APPS [ # Django自带后台、认证、会话 django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, # 商城自己的业务App apps.goods, apps.order, apps.user, ] DATABASES { default: { ENGINE: django.db.backends.sqlite3, NAME: BASE_DIR / db.sqlite3, } } TEMPLATES [ { BACKEND: django.template.backends.django.DjangoTemplates, DIRS: [BASE_DIR / templates], # APP_DIRS和DIRS两个一起决定模板去哪里找 APP_DIRS: True, } ]DATABASES这一段决定了这个商城项目默认用SQLite做数据库对新手友好不需要单独装MySQL迁移、备份都是单文件操作。如果源码里配的是MySQL你得先检查本机有没有MySQL服务而且要额外装mysqlclient或者pymysql驱动复杂度直接上一个台阶。我一般会优先选SQLite版本跑通再谈换库。2.3 用requirements.txt把依赖环境一次性装齐解压后先找根目录下的requirements.txt这是整个环境的“后悔药”清单。开发者把依赖写在这里你就能精确复刻他的开发环境。常见的商城项目依赖长这样Django3.2,4.0 Pillow8.0 django-simple-captcha装依赖的命令很简单但有几个参数值得说清楚pip install -r requirements.txt # -r 表示读取requirements.txt文件一次性安装里面列出的全部包 # 如果网络不通或速度慢可以加 -i 参数指定你自己常用的Python包镜像站装完之后不要急着启动先验证一下关键包是否到位pip list | grep -i -E django|pillow|captcha # 输出示例 # Django 3.2.25 # Pillow 10.4.0 # django-simple-captcha 0.5.20重点检查Pillow。商城项目必然处理商品图片Django的ImageField字段依赖Pillow库没装它你后面前戏全对也起不来。这个项目用的Django版本如果低于4.0Pillow版本别装最新的装8.x或9.x更稳新版Pillow对旧版Django的兼容性没那么好。3. 数据库迁移与初始化商城能跑起来的真正起点3.1 为什么每次都要先执行migrate很多刚拿到Django商城项目源码的人会直接敲runserver然后浏览器里报OperationalError: no such table一脸懵。问题出在你跳过了数据库迁移。Django的ORM把Python类映射成数据库表但映射动作不是自动发生的需要migrate命令去“建表”。python manage.py migrate # 输出会依次显示 Applying blogs.0001_initial... OK 之类的记录 # 这些记录会写进一张叫django_migrations的表里 # 以后再执行migrateDjango会对比已应用和新生成的迁移文件只执行增量部分migrate做了什么它读取项目里每个App的migrations目录下的迁移文件按顺序执行在数据库里创建工作表。你看到Applying xxx.0001_initial OK就说明这个App的初始表建好了。执行完后可以查看SQLite文件验证python manage.py shell -c from django.db import connection; print([t.name for t in connection.introspection.get_table_list()]) # 输出会列出所有表名比如 # [auth_user, goods_good, order_order, user_profile]这里面auth_user是Django自带的用户表goods_good是商城商品表order_order是订单表。看到这些表存在你就明白migrate的职责不是“创建数据库”而是“把模型映射成表”。如果源码里自带db.sqlite3文件migrate也不冲突Django会检查django_migrations表发现已经执行过的迁移会跳过。另外一个备选命令是migrate --run-syncdb它会创建所有缺少的表而不执行迁移文件。新手不要用这个因为少了迁移历史的表以后改字段会非常痛苦。老老实实跑migrate这是最不玄学的路径。3.2 创建超级管理员商城后台的第一个入口数据库有了但你还进不去后台因为后台需要管理员的账号密码。这一步是Django商城项目的必选项没有管理员账号admin后台就是一道锁着的门python manage.py createsuperuser # 交互式提示 # Username (leave blank to use yourname): admin # Email address: 直接回车跳过即可 # Password: 输入密码不显示 # Password (again): 再次输入 # Superuser created successfully.邮箱可以留空Django不强制要求。密码有个最低强度要求太简单会告诉你Too short但本地开发环境无所谓你甚至可以先去settings.py里把AUTH_PASSWORD_VALIDATORS注释掉再创建省得被密码规则烦。我通常不注释因为以后上线后这些校验器是保护伞本地麻烦一点没关系。创建完之后你的商城后台就有了第一个可登录的账号。这个账号同时会被写入auth_user表如果你之前执行过migrate又重置过数据库可能需要重新创建。找不到管理员账号时最简单的办法就是重新createsuperuser不会覆盖已有用户。3.3 源码里自带的db.sqlite3用还是不用解压的zip里如果带着db.sqlite3你会有个选择直接用他的数据库还是初始化自己的。我建议你分两种情况。第一种你只想看看商城长什么样商品、订单数据都是现成的直接用。第二种你要在这个项目上改业务、加功能强烈建议删掉或者改名重新migrate# 备份原始数据库别直接删 mv db.sqlite3 db.sqlite3.bak # 重新建库 python manage.py migrate为什么因为源码里自带的db.sqlite3里有开发者自己测试时的数据可能包括测试订单、垃圾商品、奇怪的用户记录。你在这个基础上改模型迁移时会遇到数据冲突或类型不匹配。特别是改了字段后migrate会提示你输入默认值或者干脆报错那时候你根本不知道原始数据里哪条记录有问题排查起来是黑匣子。我见过最典型的翻车直接在带数据的库上改了商品表字段类型migrate报错database disk image is malformed最后只能删库重来。所以别心疼那些演示数据它们不是你的资产你的代码才是。如果你决定保留自带数据至少先给admin账号开个身份python manage.py shell -c from django.contrib.auth.models import User; User.objects.create_superuser(admin, , yourpassword123) # 这行命令用代码的方式创建超级管理员等价于createsuperuser # 第一个参数是用户名第二个是邮箱空第三个是明文密码 # 适合在脚本里跑不用手动交互4. 启动项目与验证功能从黑匣子到可视化后台4.1 runserver跑起来先看浏览器反馈到了这一步项目终于可以启动了。启动Django开发服务器商城项目跟普通Django项目没有任何区别还是那一条命令python manage.py runserver # 终端输出 # Starting development server at http://127.0.0.1:8000/ # 如果你在远程服务器上需要监听所有网卡 python manage.py runserver 0.0.0.0:8000第一个参数是IP0.0.0.0表示监听所有网卡第二个参数是端口。默认8000被占用时换个端口跑python manage.py runserver 8080 # 或者同时指定IP和端口 python manage.py runserver 0.0.0.0:9090浏览器打开http://127.0.0.1:8000正常能看到商城首页。这时候要注意一个问题这个商城项目的首页模板和静态文件CSS、JS、图片是否正常加载。如果页面是纯文字、没有样式说明静态文件配置有问题这个我们放到第5章的坑里去解决。页面能出来才说明项目骨架是通的Django创建app时的路由注册、模板继承都没有大问题。开发服务器跑起来之后你改代码它会自动重载不用手动重启。但有个例外你改了settings.py里的数据库配置、添加了新的App必须手动重启。Django的自动重载不覆盖所有场景别让它背锅。4.2 登录admin后台商品、分类、订单数据从哪来商城首页只是门面真正能验证这个项目可用性的是Django自带的后台。别小看这个admin后台它是商城项目源码里最核心的可视化数据入口。访问http://127.0.0.1:8000/admin用刚才创建的账号密码登录。登录之后你会看到一组注册到admin的模型。典型的商城项目会有商品管理商品名称、价格、库存、封面图、上下架状态分类管理商品分类的层级关系订单管理订单号、用户、金额、支付状态、收货地址用户管理Django自带的用户和用户扩展表你可以点开商品列表看看有没有初始化数据。如果没有数据或者你想自己加一条点右上角的“增加”按钮填好商品名、价格、库存选择一张本地图片保存。保存后去商城首页刷新商品如果没有出现多半是首页只展示上架状态或库存大于0的商品这属于业务逻辑过滤不是bug。看下models里商品字段有没有is_on_sale之类的标志位python manage.py shell -c from apps.goods.models import Good # 用ORM查询所有上架商品 print(list(Good.objects.filter(is_on_saleTrue))) # 如果你不知道模型叫什么先看models.py里的类名再查 这条命令验证了两件事一是数据库连接正常二是商品查询逻辑通。4.3 用Django自带admin删一条测试订单反向体验ORMadmin后台里直接删除一条测试订单是最直观的ORM行为体验。删除不是真的立刻消失它走的是Django的delete()方法触发数据库的DELETE语句。在admin里删除时你会看到确认页面点确认后记录才真正没了。如果你想在代码里删除Django提供两种方式# 方式一删除单条记录 order Order.objects.get(id1) order.delete() # 返回一个元组 (1, {apps.Order: 1})表示删掉了1条 # 方式二直接按条件删除 Order.objects.filter(statuscancelled).delete() # 注意这条会删掉所有已取消的订单且不走模型的delete()覆盖方法这就是热搜词里说的django执行查询-删除对象的方法。这里有个坑filter().delete()是批量删除不会调用你模型里自己重写的delete()方法。如果订单模型里有关联的支付记录、退款记录批量删除只会删订单主表关联记录可能变成孤儿数据。我在admin后台删测试数据的习惯是先看一眼这个模型有没有关联的外键比如Order里有OrderItem的ForeignKey指向它删除Order时Django默认的on_deleteCASCADE会把子表也清掉。这是Django的级联删除不是bug但你要知道后果。等真正上了生产环境一个误操作把订单连带明细全删了那是没有后悔药的。5. Django商城项目源码5个必踩的坑现象、原因、解决5.1 ModuleNotFoundError: No module named PIL现象执行runserver后访问商品页或admin后台页面报ModuleNotFoundError: No module named PIL。原因商城项目模型里有ImageField字段渲染数据时需要Pillow库处理图片。这个库不在Django依赖里必须单独安装。很多Python项目实战新手在pip install django之后就以为齐了漏掉了Pillow。解决pip install Pillow # 装完重启runserver注意是重启不是刷新页面如果还报错检查是否装到了虚拟环境外面。用which pip和pip --version确认当前pip属于哪个环境。5.2 django.core.exceptions.ImproperlyConfigured版本错配现象启动时直接抛ImproperlyConfigured提示Django版本要满足某个条件或者提示数据库驱动缺失。原因Django版本与Python版本或数据库后端不匹配。比如Django 4.2要求Python 3.8你如果还在用Python 3.6启动就会报错。另一种情况是settings.py里配置了MySQL但没装mysqlclient或pymysql驱动。解决# 查看当前Python版本和Django版本 python --version pip show django # 锁定一个已知能跑的Django版本 pip install Django3.2,4.0不要直接升级到最新Django新版本常常改了API旧项目源码会跑不起来。跑通这个商城优先升级它其次。5.3 admin后台只有文字没有样式静态文件404现象admin后台能登录但页面全部是纯文字CSS和JS加载不出来浏览器开发者工具里一堆静态文件404。原因Django的开发服务器默认不自动收集App里的静态文件需要你在settings.py里配置STATIC_URL和STATICFILES_DIRS启动时Django才会去找。很多商城源码把静态文件放在根目录static/下没有配置的话admin样式就丢了。解决检查settings.py末尾STATIC_URL /static/ # 如果项目里有独立静态资源目录加上这一行 STATICFILES_DIRS [BASE_DIR / static]改完重启runserver。如果源码是production配置把DEBUGFalse静态文件还需要执行collectstatic生成到STATIC_ROOT这是部署阶段的事本地开发保持DEBUGTrue就行。5.4 OperationalError: no such table: 忘了迁移或删了迁移文件现象访问商品列表报no such table: goods_good但migrate执行过django_migrations表里也有记录。原因migrate虽然显示OK但表的创建和迁移记录不在同一个数据库里。最常见的是你改了DATABASES配置指向了一个新的SQLite文件或者你在没有迁移文件的情况下用过--run-syncdb表建了但没记录后来重建库时表就不在了。解决# 先确认当前连接的数据库路径 python manage.py shell -c from django.conf import settings; print(settings.DATABASES[default][NAME]) # 如果路径不对改settings.py或删除旧的db.sqlite3再重新迁移 mv db.sqlite3 db.sqlite3.bak python manage.py migrate如果迁移文件本身缺失就得用makemigrations补上python manage.py makemigrations apps.goods python manage.py migratemakemigrations会扫描models.py和现有迁移文件生成增量迁移。如果业务App里有SendGrid、商品库存逻辑改动这一步就是让Django重新识别表结构。5.5 订单时间比本地时间慢8小时时区与USE_TZ的坑现象订单的创建时间显示比北京时间慢8小时本地查询数据库时间字段却是对的。原因settings.py里USE_TZ True且TIME_ZONE UTCDjango默认用UTC存时间渲染时再转当前时区。商城模板如果没有启用时区转换显示的就是UTC时间。这个坑在有项目实战经验的人那里也经常翻车。解决在settings.py里把TIME_ZONE改成你所在时区的标准名称不考虑直接改UTC的写法USE_TZ True TIME_ZONE Asia/Shanghai改完重启服务。你可能会问USE_TZ要不要关掉别关。关了之后所有时间字段变成无时区的naive datetime换服务器或换数据库时区历史数据又错乱。保持USE_TZ True只改TIME_ZONE是更安全的做法。对于商城的订单来说建议后端统一用UTC存前端展示时转当地时间。但这个小项目里直接把TIME_ZONE改掉最省事代价是你以后切云服务器的时候要再确认一次。6. 把下载的商城改成自己的三个必改项与一个验收习惯6.1 重置数据库清掉演示数据你决定在这个源码上继续做的话第一件事是把演示数据清干净。前面第3章建议过备份db.sqlite3现在动手mv db.sqlite3 db.sqlite3.bak.$(date %Y%m%d) # 日期后缀帮助你识别备份时间后悔药要留 python manage.py migrate python manage.py createsuperuser # 重新创建你自己的管理员账号这条路径最干净。前提是你已经看过源码自带的演示数据、确认了字段含义清了也不心疼。以后写自己的测试数据所有记录都是你知根知底的。6.2 换掉SECRET_KEY上线前必须做商城项目源码里的SECRET_KEY是开发者留在代码里的相当于服务器的通用钥匙。这个人如果哪天把他的key发到公开仓库所有用过这份源码的人都会暴露风险。本地开发可以先不动但如果你部署到公网必须换python manage.py shell -c from django.core.management.utils import get_random_secret_key print(get_random_secret_key()) # 复制输出的字符串把复制出的结果替换到settings.py对应位置。注意SECRET_KEY变更会让所有session失效用户要重新登录这对新部署没影响。部署到正式环境时把SECRET_KEY放到环境变量里读取别留在代码里。生产环境的密钥管理是个大话题但这一步至少让你不在“拿着别人的钥匙开门”的状态。6.3 改站点标题与首页品牌词商城项目里一般有两处品牌信息admin后台的站点标题和首页模板里的商城名。admin的标题在项目的urls.py里配置# mall/urls.py from django.contrib import admin admin.site.site_header 我的商城后台 admin.site.site_title 我的商城 admin.site.index_title 商品与订单管理首页模板的商城名在templates/目录下通常是base.html或header.html里的一行a classnavbar-brand href/我的商城/a改完刷新页面前后台品牌词就统一成你自己的了。这一步很小但能快速帮你确认模板继承关系你改的是子模板还是基础模板决定了整个站点哪里会受影响。验证一个商城项目是否真正跑通我有个习惯性的三步检查首页能打开并加载静态文件后台能登录且能增删商品订单表能写入一条测试记录。三步走完这个源码的“水分”就挤干了。最后说一句我自己的教训拿到Django商城项目源码先别急着写新功能把这三个必改项做掉再动手能省掉你后面大量排查时间。希望帮到你。本文还有配套的精品资源点击获取