Django+Vue宠物商店实战：库存原子扣减、订单状态机与RBAC权限落地

简介：这是一套基于Python+Django+Vue.js全栈技术实现的宠物商店管理系统源码，专为计算机相关专业本科生毕业设计与课程设计打造，已通过导师审核并获98.5分高分评价，适用于毕设选题参考、项目实战训练及期末大作业开发。资源包共396个文件，涵盖32个核心Python后端逻辑文件、28个Vue前端组件、49个TypeScript业务脚本、35个JPG/JPEG商品图与UI截图、38个SVG图标资源，以及SQL数据库脚本、文档手册（.docx）、配置文件与静态资源，整体压缩包仅23.44MB，轻量易部署。目前已有238人学习下载，学习热度持续上升。读者可直接获取完整可运行项目结构、前后端分离标准目录、真实业务场景下的权限管理与商品订单流程代码、配套说明文档及典型界面截图，大幅降低毕设开发门槛，助力快速理解Django REST API对接Vue生态的工程实践要点。

1. 这不是又一个“增删改查”Demo：Django+Vue双端协同的宠物商店系统，真能跑通库存预警、订单状态机、多角色权限隔离三道关？

你手头那份被导师打回三次的毕业设计选题——“基于Web的宠物用品管理系统”，大概率还卡在登录页跳转404、Vue组件里调不到Django API、或者管理员删商品时把用户购物车也清空了。这不是代码写得不够多，而是没踩过真实业务里的三道硬坎：库存扣减必须原子化（否则两只猫抢最后一袋猫粮会超卖）、订单状态流转不能靠前端JS硬编码（发货/拒收/退款必须服务端强校验）、普通用户、店员、管理员三类角色的数据视图和操作边界必须由后端策略兜底（Vue路由守卫只是第一道门）。这个源码包不是教学玩具，它用Django REST Framework搭出带JWT鉴权的API层，Vue CLI 4构建的前端严格按RBAC模型渲染菜单与按钮，连数据库迁移脚本都预置了PetCategory、PetProduct、OrderItem等12张表的完整关系链。适合正在赶毕设DDL、但不想交一份“能登录但不敢点提交”的同学，也适合想快速验证Django+Vue分离架构落地细节的课程设计者——它不教你怎么写Hello World，只告诉你：当用户点击“立即购买”时，后端如何用select_for_update()锁住库存行，前端如何用Vuex持久化购物车并响应WebSocket推送的订单状态变更。

2. 从零启动：环境准备、项目结构解剖与核心模块职责划分

2.1 环境依赖与版本锚定：为什么必须用Python 3.8+、Django 3.2、Vue CLI 4？

这个项目对版本有明确约束，不是为了制造兼容性障碍，而是规避几个已知黑匣子：

• Django 3.2 是最后一个支持django.contrib.postgres原生JSONField且与DRF 3.12完全兼容的LTS版本，而本项目商品SKU属性（如“适配猫龄：幼猫/成猫/老年猫”）直接存为JSON字段，避免冗余表设计；
• Vue CLI 4 对vue-router3.x 的懒加载语法支持更稳定，能确保/admin/orders和/user/cart两个路由的代码分割不翻车；
• Python 3.8+ 强制要求async/await语法，为后续可能接入的异步通知（如短信发货提醒）留出扩展槽位。

提示：不要用pip install -r requirements.txt一键安装——文件里混入了psycopg2-binary==2.9.1（PostgreSQL驱动）和django-crispy-forms==1.12.0（管理后台表单渲染），但你的本地开发环境若用SQLite（默认配置），需先注释掉psycopg2-binary行，否则pip install会因编译失败中断。

# 推荐分步执行（Windows/macOS/Linux通用） python -m venv venv_petshop source venv_petshop/bin/activate # Linux/macOS # venv_petshop\Scripts\activate # Windows pip install --upgrade pip pip install django==3.2.23 djangorestframework==3.12.4 django-filter==21.1 pip install django-crispy-forms==1.12.0 # 管理后台增强 # SQLite开发阶段跳过psycopg2，待部署到生产环境再装

2.2 项目目录树：看清Django后端与Vue前端如何物理隔离又逻辑耦合

源码包采用经典分离式布局，后端Django项目与前端Vue项目位于同一根目录下，但互不嵌套：

petshop/ ├── backend/ # Django项目根目录（manage.py所在） │ ├── petshop/ # Django配置包（settings.py在此） │ ├── api/ # REST API应用（核心业务逻辑） │ ├── users/ # 用户认证与权限应用 │ └── manage.py ├── frontend/ # Vue CLI项目根目录（package.json所在） │ ├── src/ │ │ ├── api/ # 封装axios请求拦截器（自动携带JWT Token） │ │ ├── store/ # Vuex状态管理（购物车、用户信息、订单列表） │ │ ├── router/ # 路由定义（含动态路由加载与权限守卫） │ │ └── views/ # 页面组件（Login.vue, ProductList.vue等） │ └── package.json └── README.md

关键耦合点有三处：

1. API地址约定：Vue中所有axios.get('/api/products/')请求，实际指向Django的api/urls.py中path('api/', include('api.urls'))；
2. Token传递机制：Django后端返回JWT Token后，Vue通过localStorage.setItem('token', response.data.token)持久化，并在src/api/index.js中全局设置axios.defaults.headers.common['Authorization'] = 'Bearer ' + token；
3. 静态资源托管：Django的petshop/settings.py中STATICFILES_DIRS = [os.path.join(BASE_DIR, 'frontend/dist')]，确保npm run build生成的dist/目录被Django当作静态文件服务——这是实现“单域名部署”的技术基础。

2.3 核心模块职责拆解：为什么api应用要拆出orders、inventory、notifications三个子模块？

项目未将所有逻辑塞进一个api/views.py，而是按业务域垂直切分，这是应对毕业设计答辩时“高内聚低耦合”提问的关键证据：

注意：users应用负责JWT签发与校验，但不处理密码重置邮件发送——该功能被刻意剥离到notifications模块，因为邮件发送是耗时IO操作，不应阻塞用户登录响应。

3. 关键流程实战：从用户下单到库存扣减的全链路代码走读

3.1 前端购物车提交：Vue如何构造符合Django REST Framework规范的请求体？

用户在ProductDetail.vue点击“加入购物车”后，数据并非直接发给后端，而是先经Vuex持久化，再在结算页Checkout.vue触发最终提交。关键在于请求体结构必须匹配Django序列化器（Serializer）的字段要求：

// src/store/modules/cart.js 中的 checkout() action const orderData = { items: state.cartItems.map(item => ({ product_id: item.product.id, quantity: item.quantity, sku_code: item.sku.code // 必须传SKU编码，非商品ID！因同一商品有不同规格 })), shipping_address: { recipient: rootState.user.profile.name, phone: rootState.user.profile.phone, address: rootState.user.profile.address } } return axios.post('/api/orders/', orderData)

为什么sku_code不能省略？
因为PetProduct模型允许一个商品（如“皇家猫粮”）关联多个ProductSKU实例（“幼猫版2kg”、“成猫版5kg”），库存是按SKU粒度管理的。Django后端OrderItemSerializer中product_id字段被显式声明为PrimaryKeyRelatedField(queryset=ProductSKU.objects.all())，强制要求传入SKU的主键，而非商品主键。

3.2 后端订单创建：Django如何用select_for_update()防止超卖？

Django视图接收到请求后，核心逻辑在api/views.py的OrderCreateView中。重点看库存扣减部分：

# api/views.py from django.db import transaction from django.db.models import F class OrderCreateView(APIView): def post(self, request): serializer = OrderCreateSerializer(data=request.data) serializer.is_valid(raise_exception=True) with transaction.atomic(): # 开启数据库事务 order = serializer.save(user=request.user) # 关键：对每个OrderItem关联的SKU行加排他锁 for item in serializer.validated_data['items']: sku = ProductSKU.objects.select_for_update().get( id=item['product_id'] ) if sku.stock < item['quantity']: raise ValidationError(f"SKU {sku.code} 库存不足，当前剩余{sku.stock}") # 原子化扣减：数据库层面执行 stock = stock - quantity ProductSKU.objects.filter(id=sku.id).update( stock=F('stock') - item['quantity'] ) # 创建OrderItem记录 OrderItem.objects.create( order=order, sku=sku, quantity=item['quantity'], price=sku.price ) return Response(OrderDetailSerializer(order).data, status=201)

这段代码的玄学点在于select_for_update()的位置：

• 它必须在transaction.atomic()上下文中调用，否则锁会在查询后立即释放；
• select_for_update()锁定的是ProductSKU表的特定行（id=item['product_id']），而非整张表，避免高并发时性能雪崩；
• F('stock') - item['quantity']确保扣减操作在数据库层面完成，杜绝“读取库存→判断→更新”三步间的竞态条件。

3.3 订单状态机：Django如何用状态流转规则拒绝非法操作？

订单状态不是字符串随意赋值，而是由Order模型的status字段配合OrderStatusTransition服务类强管控：

# api/models.py class Order(models.Model): STATUS_CHOICES = [ ('pending', '待支付'), ('paid', '已支付'), ('shipped', '已发货'), ('delivered', '已签收'), ('cancelled', '已取消'), ] status = models.CharField(max_length=20, choices=STATUS_CHOICES, default='pending') # api/services.py class OrderStatusTransition: # 定义合法状态转移路径：key为当前状态，value为允许的目标状态 ALLOWED_TRANSITIONS = { 'pending': ['paid', 'cancelled'], 'paid': ['shipped', 'cancelled'], 'shipped': ['delivered', 'cancelled'], 'delivered': [], 'cancelled': [], } @classmethod def can_transition(cls, from_status, to_status): return to_status in cls.ALLOWED_TRANSITIONS.get(from_status, []) @classmethod def transition(cls, order, new_status, user): if not cls.can_transition(order.status, new_status): raise PermissionDenied(f"订单{order.id}无法从'{order.status}'变为'{new_status}'") # 特殊校验：只有管理员能取消已支付订单 if new_status == 'cancelled' and order.status == 'paid': if not user.is_staff: raise PermissionDenied("仅管理员可取消已支付订单") order.status = new_status order.save()

答辩时可强调的设计亮点：

• 状态机逻辑与模型解耦，便于单元测试（test_order_status_transition.py中可mock所有场景）；
• can_transition()方法可被前端调用（通过/api/orders/status-options/接口），让Vue动态渲染“可操作按钮”，避免用户点击灰色按钮后才报错。

4. 避坑指南：五个血泪经验换来的高频问题与排查方案

4.1 现象：Vue前端登录成功后，访问/admin/页面提示403 Forbidden

原因：Django后端users/views.py中LoginView返回的JWT Token未正确注入到Vue的localStorage，或axios拦截器未读取该Token。
解决：

1. 检查LoginView是否在Response中返回'token'字段（源码中return Response({'token': token})）；
2. 查看浏览器开发者工具→Application→Storage→Local Storage，确认token键值存在且为长字符串；
3. 在src/api/index.js中添加调试日志：console.log('Token from localStorage:', localStorage.getItem('token'))，确认拦截器读取无误。

4.2 现象：Django管理后台（/admin/）中修改商品库存后，前端商品列表页显示的库存未更新

原因：Vue前端使用Vuex缓存了商品列表数据，但未监听Django管理后台的变更事件。
解决：

• 方案A（推荐）：在src/store/modules/products.js中，为fetchProductsaction添加forceRefresh参数，当管理员在后台操作后，前端主动调用dispatch('products/fetchProducts', { forceRefresh: true })；
• 方案B（进阶）：在Django中启用django-signals，当ProductSKU模型save()时触发信号，通过channels推送WebSocket消息到前端，Vuex订阅后刷新缓存。

4.3 现象：用户下单时，OrderCreateView抛出IntegrityError: null value in column "shipping_address"

原因：前端提交的shipping_address对象结构与Django序列化器OrderCreateSerializer中shipping_address字段的嵌套序列化器不匹配。
解决：

• 检查api/serializers.py中ShippingAddressSerializer的字段名（如recipient、phone、address）是否与前端orderData.shipping_address的key完全一致；
• 确认前端未传入null值：shipping_address: { recipient: '', phone: '', address: '' }会导致Django校验失败，应改为shipping_address: null（若允许为空）或补全必填字段。

4.4 现象：Vue路由守卫（router.beforeEach）中next()未被调用，导致页面白屏

原因：src/router/index.js中权限守卫逻辑存在异步等待未处理，例如store.dispatch('user/checkAuth').then(...)未覆盖所有分支。
解决：

• 在守卫函数末尾强制添加else { next() }兜底；
• 更稳妥做法：将权限检查改为async/await，并用try/catch包裹：

router.beforeEach(async (to, from, next) => { try { await store.dispatch('user/checkAuth') if (to.meta.requiresAuth && !store.state.user.token) next('/login') else next() } catch (error) { next('/login') // 任何异常都跳转登录页 } })

4.5 现象：部署到Nginx后，Vue路由（如/user/profile）刷新返回404

原因：Nginx未配置前端路由的fallback规则，将/user/profile当作静态文件路径查找，而非交由Vue Router处理。
解决：
在Nginx配置中location /块内添加：

location / { try_files $uri $uri/ /index.html; }

此配置确保所有未匹配静态资源的请求，均由index.html响应，交由Vue Router解析URL。

5. 权限系统深度解析：RBAC模型在Django与Vue中的双向落地

5.1 Django后端：如何用Group和Permission实现细粒度数据隔离？

项目未使用自定义权限逻辑，而是深度绑定Django内置的auth.Group与auth.Permission，这是答辩时体现“遵循框架最佳实践”的关键：

• 角色建模：

  • 普通用户组：仅分配add_order、view_product、change_order（仅限自己订单）权限；
  • 店员组：额外分配view_orders（查看全部订单）、change_productsku（修改库存）权限；
  • 管理员组：拥有add_*、change_*、delete_*全表权限，且is_staff=True可访问Django管理后台。

• 数据级权限控制：
  api/views.py中OrderListView通过重写get_queryset()实现：

  class OrderListView(ListAPIView): serializer_class = OrderListSerializer def get_queryset(self): user = self.request.user if user.is_staff: # 管理员看全部 return Order.objects.all() elif hasattr(user, 'employee_profile'): # 店员看全部 return Order.objects.all() else: # 普通用户只看自己的 return Order.objects.filter(user=user)

5.2 Vue前端：如何根据用户角色动态渲染菜单与按钮？

前端权限不依赖后端返回的is_staff布尔值，而是解析Django返回的user.permissions数组（通过/api/users/me/接口获取），实现真正的RBAC：

// src/store/modules/user.js const state = { permissions: [] // 如 ['view_product', 'add_order', 'change_order'] } // src/utils/permission.js export function hasPermission(permission) { return state.permissions.includes(permission) } // 在组件中使用 <template> <button v-if="hasPermission('change_productsku')" @click="openStockModal"> 修改库存 </button> </template>

菜单动态生成逻辑（src/router/index.js）：

// 定义路由元信息 const routes = [ { path: '/admin/products', name: 'AdminProducts', component: () => import('@/views/admin/ProductList.vue'), meta: { permissions: ['view_product', 'change_productsku'] } } ] // 路由守卫中过滤 router.beforeEach((to, from, next) => { const requiredPerms = to.meta.permissions || [] const userPerms = store.state.user.permissions if (requiredPerms.some(perm => userPerms.includes(perm))) { next() } else { next('/403') // 无权限页面 } })

5.3 权限校验的双重保险：为什么前端按钮隐藏+后端API拦截缺一不可？

这是一个常被答辩委员追问的点。答案很直白：

• 前端隐藏按钮（如店员看不到“删除用户”按钮）是用户体验优化，防止用户误点；
• 后端API拦截（如UserDeleteView中if not request.user.is_staff: raise PermissionDenied）是安全底线，因为前端代码可被任意篡改。

项目在api/permissions.py中定义了IsAdminOrSelf权限类：

class IsAdminOrSelf(BasePermission): def has_object_permission(self, request, view, obj): return request.user.is_staff or obj == request.user

并在users/views.py的UserDetailView中声明：

class UserDetailView(RetrieveUpdateDestroyAPIView): permission_classes = [IsAdminOrSelf] # 仅管理员可删他人，用户只能删自己

这种设计让答辩时能清晰展示：权限控制既在路由层（菜单）、也在视图层（API）、还在对象层（单条记录），形成纵深防御。

6. 毕业设计加分技巧：三招让答辩老师眼前一亮的实操细节

6.1 把“库存预警”做成可演示的实时通知：WebSocket集成实战

答辩时如果只说“系统有库存预警”，老师只会点头；但如果你打开后台，将某SKU库存设为1，然后在前台商品页看到右上角弹出红色气泡“【警告】皇家猫粮幼猫版库存仅剩1袋！”，老师一定会追问技术细节。这背后是Django Channels的轻量级集成：

• 后端配置（backend/petshop/settings.py）：

  INSTALLED_APPS += ['channels'] ASGI_APPLICATION = 'petshop.asgi.application' CHANNEL_LAYERS = { 'default': { 'BACKEND': 'channels.layers.InMemoryChannelLayer' # 开发环境用内存层 } }

• 预警触发逻辑（api/services.py）：

  from channels.layers import get_channel_layer from asgiref.sync import async_to_sync def check_low_stock_alert(sku): if sku.stock <= sku.low_stock_threshold: channel_layer = get_channel_layer() async_to_sync(channel_layer.group_send)( "inventory_alerts", { "type": "inventory.alert", "message": f"【警告】{sku.product.name}{sku.code}库存仅剩{sku.stock}袋！" } )

• 前端接收（src/plugins/websocket.js）：

  const socket = new WebSocket(`ws://${window.location.host}/ws/inventory/`); socket.onmessage = (e) => { const data = JSON.parse(e.data); if (data.type === 'inventory.alert') { this.$message.warning(data.message); // Element UI消息提示 } };

从那以后我每次做带实时通知的毕设，都强制走一遍WebSocket连接测试：先用wscat -c ws://localhost:8000/ws/inventory/手动发消息，确认通道畅通，再写业务逻辑。这招让三次答辩都没被问倒过WebSocket握手失败的问题——希望帮到你。

6.2 用Django管理后台的list_display_links和search_fields提升答辩演示效率

答辩现场老师常会说：“你演示下管理员怎么批量修改商品价格？” 如果你手忙脚乱在ProductList.vue里找编辑入口，不如直接切到Django管理后台/admin/api/product/，这里已预置好：

• list_display_links = ['name', 'category']：点击商品名直接进入编辑页；
• search_fields = ['name', 'description', 'sku__code']：支持按商品名、描述、SKU编码全局搜索；
• list_filter = ['category', 'is_active', 'created_at']：右侧筛选栏可按分类、上下架状态、创建时间快速过滤。

这些不是默认配置，而是api/admin.py中显式声明：

@admin.register(Product) class ProductAdmin(admin.ModelAdmin): list_display = ['name', 'category', 'is_active', 'created_at'] list_display_links = ['name', 'category'] search_fields = ['name', 'description', 'skus__code'] # 注意外键反向查询写法 list_filter = ['category', 'is_active', 'created_at']

演示技巧：答辩时用Chrome隐身窗口打开/admin/，输入admin/admin（默认账号密码），现场演示“搜索‘猫粮’→勾选3个商品→动作选‘修改价格’→批量设为¥199”，全程30秒，比Vue前端操作直观十倍。

6.3 为答辩定制requirements.txt：剔除开发依赖，只留生产必需包

很多同学答辩时被问“你用的什么数据库？”，答“SQLite”会被质疑“没考虑生产环境”。其实只需在requirements.txt中做个小手术：

• 保留Django==3.2.23、djangorestframework==3.12.4等核心包；
• 移除django-debug-toolbar、django-extensions等开发专用包（它们会污染生产环境）；
• 将psycopg2-binary==2.9.1从注释状态改为启用，并备注# 生产环境PostgreSQL驱动，开发时可注释。

这样答辩时可以说：“开发用SQLite快速迭代，部署时只需替换数据库配置并安装psycopg2-binary，零代码修改”。老师听到“零代码修改”四个字，基本就认可你的工程化思维了。

本文还有配套的精品资源，点击获取