简介这是一份基于Django框架的电子商务网站项目源码主要面向Python Web开发者、高校学生以及需要快速搭建电商原型的技术人员。项目覆盖商品展示、关键词搜索、购物车、用户注册登录、结账与订单状态跟踪等典型电商业务模块能帮助读者系统理解Django的MVT设计模式、模板语言、ORM数据库建模以及内置的用户认证与权限管理机制。压缩包共包含101个文件其中17个Python源码文件用于实现视图、模型与业务逻辑15个HTML模板文件用于渲染前端页面14个pyc编译文件属于字节码缓存另有SQLite数据库快照以及JPG、PNG、WebP等格式素材整体压缩后约3.89MB。目前已有91人学习下载可作为课程设计、毕业设计或Django实战入门的重要参考。通过研读源码与页面逻辑能够快速掌握URL路由、视图函数、模板展示之间的协作方式还可进一步了解购物车会话持久化、结账流程、支付网关集成、缓存优化与部署上线等完整电商开发链路。1. 拿到的 Django 电商网站不是模板套壳从能跑通到能上线很多开发者第一次拿到 Django 电商项目的源码包时第一反应是python manage.py runserver然后打开浏览器看首页长什么样。但真正把这个项目拆过一遍之后会发现一个能跑的商城页面只是冰山一角购物车是存在 Session 里还是数据库里库存扣减有没有加锁订单状态怎么流转以及DEBUGFalse之后静态文件为什么全部消失——这些才是决定这个项目能不能真正上线、能不能交付给客户的关键。这份 Django 制作的电子商务网站源码覆盖了商品展示、购物车、订单、用户认证和后台管理一条完整的业务闭环适合两类人正在学 Django 但苦于没有完整项目可参考的开发者以及需要快速搭建商城原型、后续要基于源码二次开发的小团队。2. 项目骨架与数据模型把商品、订单、用户这三张表想清楚2.1 先从 Django 项目结构和配置说起拿到源码后先别急着点运行我一般会先把整个项目目录扫一遍。经典的 Django 项目分两层外层是项目配置目录内层是 app 业务目录。这个电商项目里你能看到几个典型的目录模块商品相关的 app、订单相关的 app、用户相关的 app以及一个负责页面渲染的主 app。这种拆分方式的好处是后续扩展功能时不用动到已有的业务代码比如你想加一个优惠券模块单独建一个couponapp 就能接入。配置部分最需要关注的是settings.py里的INSTALLED_APPS列表。这个列表决定了 Django 启动时会加载哪些数据表、哪些模板标签、哪些后台功能。我拆这个项目时发现它在INSTALLED_APPS里启用了django.contrib.admin和django.contrib.auth这意味着用户登录、会话管理、后台管理这些基础能力是开箱即用的不需要自己实现密码加密和 session 维持机制。# settings.py 核心片段 INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, shop, # 商品模块 cart, # 购物车模块 orders, # 订单模块 accounts, # 用户模块 ] DATABASES { default: { ENGINE: django.db.backends.sqlite3, NAME: BASE_DIR / db.sqlite3, } }sqlite3作为默认数据库是这个项目最务实的选型零配置、单文件、适合开发和演示。但你心里要清楚它的边界并发写入能力弱高流量场景下很容易出现数据库锁异常。我一般会在开发阶段用 SQLite 快速迭代到了要部署上线之前再把数据库切到 PostgreSQL切换方式后面避坑章节会具体讲。2.2 商品模型与订单模型ORM 字段选择背后的业务考量打开models.py你会看到整个电商系统的核心是三个模型商品、订单、订单项。这个设计和我们平时写 CRUD 练习不一样的地方在于订单和商品之间不是直接的多对多关系而是通过「订单项」这张中间表关联起来的这样做是有现实原因的。# shop/models.py from django.db import models class Product(models.Model): name models.CharField(max_length200, verbose_name商品名称) slug models.SlugField(max_length200, uniqueTrue, verbose_nameURL标识) description models.TextField(blankTrue, verbose_name商品描述) price models.DecimalField(max_digits10, decimal_places2, verbose_name价格) stock models.PositiveIntegerField(default0, verbose_name库存) available models.BooleanField(defaultTrue, verbose_name是否上架) created models.DateTimeField(auto_now_addTrue, verbose_name创建时间) class Meta: ordering (-created,) def __str__(self): return self.name# orders/models.py class Order(models.Model): user models.ForeignKey(accounts.User, on_deletemodels.CASCADE, verbose_name下单用户) full_name models.CharField(max_length100, verbose_name收货人) address models.CharField(max_length250, verbose_name收货地址) phone models.CharField(max_length20, verbose_name联系电话) total models.DecimalField(max_digits10, decimal_places2, verbose_name订单总额) paid models.BooleanField(defaultFalse, verbose_name是否支付) created models.DateTimeField(auto_now_addTrue, verbose_name下单时间) class OrderItem(models.Model): order models.ForeignKey(Order, related_nameitems, on_deletemodels.CASCADE) product models.ForeignKey(shop.Product, related_nameorder_items, on_deletemodels.CASCADE) price models.DecimalField(max_digits10, decimal_places2, verbose_name成交单价) quantity models.PositiveIntegerField(default1, verbose_name数量)这里有几个字段选择值得注意。商品价格用DecimalField而不是FloatField是因为浮点数在计算金额时会有精度丢失问题比如0.1 0.2的结果不是精确的0.3。对于电商系统来说哪怕是几分钱的误差在订单对账时都是事故。而OrderItem里单独存一个price字段是把「下单时的价格」和「商品当前价格」解耦——商品后续改价已下单的订单不受影响这是电商系统里非常重要的一个业务细节。另外related_name的用途是让你在查询时能直接通过order.items.all()拿到当前订单的所有商品条目避免写一堆复杂的 join 查询。2.3 初始化数据用 fixture 给商城造第一批商品项目源码里通常不会带商品数据因为图片和描述属于运营内容。但为了本地跑起来能看到效果需要用 fixture 初始化一批测试数据。我拆这个项目时习惯先创建一个products.jsonfixture 文件放在 app 的fixtures目录下[ { model: shop.product, pk: 1, fields: { name: 机械键盘, slug: mechanical-keyboard, description: 茶轴支持全键无冲适合办公和游戏场景, price: 299.00, stock: 50, available: true } }, { model: shop.product, pk: 2, fields: { name: 27寸显示器, slug: 27-inch-monitor, description: IPS 面板2K 分辨率支持壁挂, price: 1299.00, stock: 20, available: true } } ]加载 fixture 的命令是python manage.py loaddata products.json。注意 fixture 文件里的model字段格式必须是应用名.模型名比如这里的shop.product就对应shop应用下的Product模型。如果提示No fixture named products found大概率是文件没放到 app 的fixtures目录下或者文件名跟命令里写的对不上。这也是新手经常翻车的一个小地方。3. 购物车、订单与库存扣减把核心流程串起来3.1 购物车存在 Session 里还是数据库里购物车模块通常是电商系统里第一个需要做技术决策的地方。这个项目采用的是 Session 购物车方案也就是购物车数据保存在服务端的 session 记录里而不是为购物车单独建一张数据库表。对应的cart/models.py里没有数据库模型购物车逻辑全部写在视图函数里通过request.session读写。会话型购物车的好处有两个一是未登录用户也能往购物车里加东西下单时才要求登录这符合电商行业的真实习惯二是减轻数据库压力用户往购物车加商品、改数量这些高频操作不会产生数据库写入只有最终下单才落库。# cart/views.py def cart_add(request, product_id): product get_object_or_404(Product, idproduct_id, availableTrue) cart request.session.get(cart, {}) # 以商品id为 key避免重复条目 if str(product_id) in cart: cart[str(product_id)][quantity] 1 else: cart[str(product_id)] { quantity: 1, price: str(product.price) # 转字符串避免 Decimal 无法序列化 } request.session[cart] cart request.session.modified True # 告诉 Django session 已变更必须保存 return redirect(cart:detail)这段代码里有三个细节值得展开。第一request.session的数据结构是一个嵌套字典外层 key 是商品 id 的字符串形式内层存数量和加入购物车时的单价。第二价格字段在写入 session 时转成了字符串是因为 Django 的 session 默认使用 JSON 序列化而Decimal类型无法被 JSON 直接序列化不转换的话会直接报TypeError。第三request.session.modified True这行很容易漏掉——如果你只改了 session 里嵌套字典的值Django 不会认为 session 数据发生了变更下次请求时购物车内容就消失了这是我见过最多的购物车翻车原因。3.2 订单生成与库存扣减事务和行锁是最后的防线从购物车到订单这个环节是整个系统里对数据一致性要求最高的地方。用户在购物车界面点「去结算」系统要做的事情包括读取购物车里的商品和数量、计算总价、创建订单记录、创建订单明细、扣减库存、清空购物车。这五个步骤必须当作一个整体来执行——如果订单创建成功但库存没扣掉超卖就会发生。# orders/views.py from django.db import transaction from django.shortcuts import get_object_or_404, redirect, render def order_create(request): cart request.session.get(cart, {}) if not cart: return redirect(cart:detail) with transaction.atomic(): order Order.objects.create( userrequest.user, full_namerequest.POST[full_name], addressrequest.POST[address], phonerequest.POST[phone], total0, # 先创建后面计算总价 ) order_total 0 for product_id, item in cart.items(): product get_object_or_404(Product, idproduct_id) if product.stock item[quantity]: # 库存不足主动抛异常触发回滚 raise ValueError(f商品 {product.name} 库存不足) product.stock - item[quantity] product.save(update_fields[stock]) OrderItem.objects.create( orderorder, productproduct, priceproduct.price, quantityitem[quantity], ) order_total product.price * item[quantity] order.total order_total order.save(update_fields[total]) # 事务提交成功后再清空 session request.session[cart] {} request.session.modified True return render(request, orders/created.html, {order: order})transaction.atomic()是 Django 提供的事务上下文管理器包裹在它里面的所有数据库操作要么全部成功提交要么全部回滚。这里我额外用了一个小技巧库存判断通过if product.stock item[quantity]完成如果条件不满足就主动raise ValueError让事务回滚。但注意这种检查在并发场景下并不够安全——两个用户同时下单可能同时读到库存还有 1 件然后都通过检查最终导致超卖。如果你要处理高并发场景需要把product get_object_or_404(Product, idproduct_id)换成Product.objects.select_for_update().get(idproduct_id)也就是给这行记录加行级锁让其他事务必须等当前事务提交或回滚后才能继续读取。3.3 用户认证与权限内置 auth 的边界在哪里用户模块这个项目直接用的是 Django 自带的django.contrib.auth用户表是框架默认的User模型包含用户名、密码、邮箱等字段。在注册功能这块Django 提供了一套完整的注册、登录、登出视图但默认的表单只有一个用户名和密码没有手机号、昵称这些商城常见的字段。如果你的需求只是让学生作业或者企业内部工具能登录下单内置 auth 完全够用。但如果你要做一个面向 C 端用户的商城需要手机号登录、邮箱验证、微信登录这些能力内置User模型就不够用了。我一般会从拿到源码的第一天就用自定义用户模型替代在settings.py里加一行AUTH_USER_MODEL accounts.User然后在accounts/models.py里创建继承AbstractUser的模型。这个决定的代价是要在第一次makemigrations之前改好如果已经跑过迁移了再改自定义用户模型会非常痛苦。功能点内置 auth自定义 User注册登录开箱即用需要写少量代码自定义字段不支持支持手机号、头像等迁移成本无必须在首次迁移前确定适用场景内部系统、教学项目C 端商城、SaaS 产品4. 前端渲染与 HTML 模板Django 模板语言的组织方式4.1 模板继承base.html 是所有页面的骨架这个项目的页面渲染是基于 Django 模板系统 HTML 实现的没有前后端分离服务端直接渲染完整的 HTML 返回给浏览器。打开templates目录后你会发现一个明显的分层结构base.html在最外层定义了整站的公共框架——导航栏、页脚、CSS 和 JavaScript 的引用位置shop/list.html、shop/detail.html、cart/detail.html这些页面则通过{% extends %}标签继承base.html只写自己独有的内容区域。!-- templates/base.html 核心骨架 -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 title{% block title %}我的商城{% endblock %}/title link relstylesheet href{% static css/base.css %} /head body header nav a href{% url shop:product_list %}首页/a a href{% url cart:detail %}购物车/a {% if user.is_authenticated %} span{{ user.username }}欢迎您/span a href{% url accounts:logout %}退出/a {% else %} a href{% url accounts:login %}登录/a {% endif %} /nav /header main {% block content %}{% endblock %} /main /body /html子模板只需要这样写!-- shop/list.html -- {% extends base.html %} {% block title %}商品列表{% endblock %} {% block content %} div classproduct-grid {% for product in products %} div classproduct-card h3{{ product.name }}/h3 p价格{{ product.price }} 元/p a href{% url shop:product_detail product.slug %}查看详情/a /div {% endfor %} /div {% endblock %}这里{% block %}和{% extends %}是 Django 模板系统的核心机制base.html定义了内容占位符子模板通过重写 block 内容来填充各自页面不同的部分。注意{% static %}标签是 Django 处理静态文件资源的入口它会根据settings.py里的STATIC_URL拼接出/static/css/base.css这样的路径。很多刚接触 Django 的开发者会把 CSS 文件直接放在 templates 目录里然后发现样式怎么都加载不出来原因就是静态文件和模板文件是两套不同的处理机制。4.2 商品列表和详情页视图函数与模板的配合商品列表页的逻辑很直接——从数据库把上架商品取出来传给模板渲染。但这里有一个性能相关的细节如果商品数量很大用Product.objects.filter(availableTrue)一次性取全部记录会非常慢。Django 的 ORM 支持分页项目里用的是Paginator类# shop/views.py from django.core.paginator import Paginator, PageNotAnInteger, EmptyPage def product_list(request): products Product.objects.filter(availableTrue) paginator Paginator(products, 9) # 每页 9 个商品 page request.GET.get(page, 1) try: product_page paginator.page(page) except PageNotAnInteger: product_page paginator.page(1) except EmptyPage: product_page paginator.page(paginator.num_pages) return render(request, shop/list.html, {products: product_page})Paginator的第一个参数是查询集第二个参数是每页条数。分页后模板里用{% for product in products %}遍历的是当前页的数据同时你可以用products.has_previous和products.has_next判断是否还有上一页和下一页在页面上渲染翻页按钮。注意PageNotAnInteger和EmptyPage两个异常分别处理「页码不是数字」和「页码超出范围」的情况不处理的话用户手动改 URL 里的?page参数就会直接抛 500 错误。4.3 表单交互与 CSRF 防护POST 请求的正确打开方式商品详情页和购物车界面都涉及表单提交。Django 对 POST 请求有一道强制校验——CSRF 防护这是为了防跨站请求伪造攻击。在模板里你必须在form标签内部加上{% csrf_token %}!-- cart/templates/cart/detail.html -- form action{% url orders:order_create %} methodpost {% csrf_token %} label收货人input typetext namefull_name required/label label地址input typetext nameaddress required/label label电话input typetext namephone required/label button typesubmit提交订单/button /form如果忘记加{% csrf_token %}提交表单时 Django 会返回 403 Forbidden 错误浏览器页面会显示一个 CSRF 验证失败的报错页。项目里所有用到 POST 的地方包括购物车添加、订单提交、用户注册都有这行模板标签。模板里用action属性指定表单提交的 URLname属性对应视图函数里request.POST.get(full_name)的取值 key这个对应关系不能写错。5. 部署与排查本地能跑不代表线上能用5.1 三个高频翻车点数据库迁移、静态文件、依赖环境把项目从本地复制到服务器上部署我见过最多的翻车点有三个。第一个是数据库迁移。项目在db.sqlite3里已经跑过多轮迁移、里面有测试数据你直接把整个目录拷到服务器上SQLite 能跑但如果你把数据库换成了 PostgreSQL就必须在服务器上重跑python manage.py migrate。很多人会忘记在服务器上执行这个命令结果启动后报no such table: shop_product。解决方式也很简单每次部署到新环境先跑一遍python manage.py migrate确认所有迁移文件都执行成功。第二个是静态文件丢失。开发模式下DEBUGTrueDjango 会自动帮你处理静态文件但线上部署时DEBUGFalseDjango 不再承担静态文件服务你必须手动执行python manage.py collectstatic把所有静态文件收集到STATIC_ROOT指定的目录并交给 Nginx 或 CDN 托管。我刚开始部署时偷懒没跑collectstatic结果线上页面纯 HTML 没有样式浏览器控制台全部是 404。第三个是依赖环境不一致。本地开发环境是 Python 3.10 加一堆包服务器上是另一个版本直接用python manage.py runserver可能能跑但换用 Gunicorn 或 uWSGI 后各种兼容问题。正确的做法是本地生成requirements.txtpip freeze requirements.txt在服务器上创建虚拟环境后执行python -m venv venv source venv/bin/activate pip install -r requirements.txt5.2 生产环境配置DEBUG、ALLOWED_HOSTS 与安全设置DEBUGFalse之后会触发一系列连锁反应除了静态文件不处理还包括错误页面不再显示详细堆栈信息、浏览器控制台提示DisallowedHost错误——这是因为 Django 要求你显式声明允许访问的主机名。# settings.py 生产环境关键配置 DEBUG False ALLOWED_HOSTS [your-domain.com, www.your-domain.com, 服务器IP] STATIC_ROOT BASE_DIR / staticfiles STATIC_URL /static/ # 安全相关 SECURE_SSL_REDIRECT True SESSION_COOKIE_SECURE True CSRF_COOKIE_SECURE TrueALLOWED_HOSTS是一个列表里面只能写你的域名或 IP不写的话 Django 会拒绝所有请求。SESSION_COOKIE_SECURE True表示 session cookie 只在 HTTPS 连接下传输如果服务器还没配 HTTPS这个配置会导致登录后立刻掉线——登录状态存不下来。这是一个很容易踩的坑你在本地跑的时候DEBUGTrue、SESSION_COOKIE_SECURE是默认的False一切正常部署到线上开了 HTTPS 强制跳转同时也改了安全配置结果发现用户登录后跳转回首页又变成未登录状态。排查思路是检查浏览器开发者工具里的 Cookie 是否被标记为 Secure 且当前页面是否是 HTTPS。5.3 数据库切换从 SQLite 到 PostgreSQL 的注意事项项目要正式上线我几乎一定会把数据库从 SQLite 切到 PostgreSQL。切换过程并不只是改settings.py里的DATABASES配置还要注意以下几步# settings.py 切换 PostgreSQL DATABASES { default: { ENGINE: django.db.backends.postgresql, NAME: shop_db, USER: shop_user, PASSWORD: 强密码, HOST: localhost, PORT: 5432, } }首先PostgreSQL 需要安装适配包psycopg2-binary然后要在数据库里先创建好对应的数据库和用户。创建方式是在服务器上执行sudo -u postgres psql -c CREATE DATABASE shop_db; sudo -u postgres psql -c CREATE USER shop_user WITH PASSWORD 强密码; sudo -u postgres psql -c GRANT ALL PRIVILEGES ON DATABASE shop_db TO shop_user;其次原来 SQLite 里的测试数据不会自动迁移过去你需要重新执行python manage.py migrate创建所有数据表然后重新loaddata导入商品 fixture。最后注意DecimalField在 SQLite 里存储时可能没有精度问题但在 PostgreSQL 里精度严格遵循max_digits和decimal_places参数库存扣减后的余额如果小数位数匹配不上会直接报错。5.4 遇到 500 错误时排查到底层日志线上环境DEBUGFalse后页面出现 500 错误只会显示一个简单的服务器错误页面具体原因被隐藏了。这时候有两种排查方式一是看服务器上的日志文件Nginx 的 error.log 和通过日志系统记录的应用日志二是临时用 Django 自带的错误报告机制。在settings.py里配置一个ADMINS列表Django 会把异常堆栈通过邮件发给你ADMINS [(你的名字, 你的邮箱example.com)] # 邮件服务器配置 EMAIL_BACKEND django.core.mail.backends.smtp.EmailBackend EMAIL_HOST smtp.example.com EMAIL_PORT 587 EMAIL_HOST_USER 你的邮箱example.com EMAIL_HOST_PASSWORD 授权码但线上环境直接配 SMTP 发邮件有一定安全风险更稳妥的做法是把异常写入日志文件LOGGING { version: 1, handlers: { file: { level: ERROR, class: logging.FileHandler, filename: BASE_DIR / logs/error.log, }, }, loggers: { django: { handlers: [file], level: ERROR, }, }, }我自己的习惯是任何一次生产环境的报错都要看到原始堆栈信息再动手处理绝不能靠猜。有一次某开发者跟我说订单提交一直失败线上环境翻日志发现是IntegrityError——重复提交订单导致主键冲突。为什么会这样因为用户在结算页面点了两次提交按钮两次 POST 请求几乎同时到达订单记录在同一事务里被创建了两次。解决方式是在前端提交按钮加禁用状态同时在后端用事务的select_for_update配合幂等校验这才是治本。6. 进阶技巧用 Django Admin 做订单运维比想象中更有用很多开发者把 Django Admin 当成一个自动生成的 CRUD 后台默认能用就行。但在这个电商项目里Admin 其实是可以直接拿来当运营后台用的。把订单列表配置好日常的订单状态管理、库存调整、用户查询全都能在 Admin 里完成不需要额外开发管理页面。打开orders/admin.py默认注册 Order 模型只会显示一个简单的列表每条订单看不出任何有效信息。这时候就需要自定义ModelAdmin的配置项# orders/admin.py from django.contrib import admin from .models import Order, OrderItem class OrderItemInline(admin.TabularInline): model OrderItem extra 0 # 不显示空的额外行 readonly_fields (product, price, quantity) admin.register(Order) class OrderAdmin(admin.ModelAdmin): list_display (id, full_name, phone, total, paid, created) list_filter (paid, created) search_fields (full_name, phone, address) inlines [OrderItemInline] def get_readonly_fields(self, request, objNone): # 已支付订单禁止修改金额 if obj and obj.paid: return self.readonly_fields (total,) return self.readonly_fieldslist_display定义了列表页展示哪些字段list_filter在页面右侧生成筛选器search_fields提供搜索框。这些配置看起来简单但在实际运营中价值很大——处理售后问题时输入手机号就能查到该用户的所有订单管理促销活动时按创建时间筛选出某段时间内的订单做对账。更进阶的用法是自定义 Admin Action批量处理订单状态。比如你接到一个需求多笔订单同时发货不想一笔一笔点开编辑。可以给OrderAdmin加一个mark_as_paid动作def mark_as_paid(self, request, queryset): updated queryset.update(paidTrue) self.message_user(request, f已将 {updated} 笔订单标记为已支付) mark_as_paid.short_description 标记为已支付 actions [mark_as_paid]queryset.update()是高效的批量更新方式它直接生成一条 UPDATE SQL不会为每条记录单独实例化模型再逐条保存。这套 Admin 配置方案是我每次拆 Django 电商项目时的固定动作——先理清业务模型再把 Admin 调成运营人员能用的界面最后才考虑写不写自定义管理页面。超过 70% 的电商后台功能其实都能通过 Admin 配置实现比如商品上下架、库存调整、订单状态流转真正需要定制开发的往往只有权限分级和财务报表页面。从那以后我每次拿到一份 Django 项目源码第一件事不是跑起来看页面而是先把 model 和 admin 通读一遍因为这两个文件是整个项目业务逻辑的浓缩。这个习惯帮我避开了很多因为不理解底层设计而埋下的部署坑也希望帮到你。本文还有配套的精品资源点击获取
首尾+随机访问)
