本文还有配套的精品资源点击获取简介专为小型服装店设计的Django进销存管理系统开箱即用PyCharm可直接运行支持Python 3.7 Django 2.2。默认使用SQLite附带MySQL迁移脚本jxc_db.sql和详细配置说明一键切换数据库。系统分操作员和管理员两类角色操作员能注册登录维护客户资料、录入服装信息、创建入库单和出库单每张单据支持添加多款服装明细提交时自动校验库存——出库数量超过当前余量会实时弹出‘库存不足’提示辅助及时补货管理员账号manage/123456拥有全部数据管理权限包括客户档案、服装资料、所有出入库记录及操作员账户的增删改查。项目结构规范含完整templates页面模板、static静态资源、utils通用工具模块以及customer客户、clothes服装、jxc进销存等业务应用还提供requirements.txt依赖清单和README.md部署指南适合教学演示、个体服装店快速上线或基于现有功能做定制开发。1. 项目概述为什么一个小服装店真需要一套“不重不卡、不教不会”的进销存系统你有没有见过这样的场景一家开了五年的社区女装店老板娘每天早上七点到店第一件事不是整理货架而是翻三本本子——一本记进货谁家工厂、什么款、几件、多少钱一本记销售哪天卖给谁、什么码、收了多少钱还有一本是手写的库存流水账。月底盘库她得把三本子摊在收银台上拿计算器按半小时再对着货架一件件核对经常发现“明明记得进了20条阔腿裤怎么只剩13条”——结果一查有7条被隔壁店员临时借去给顾客试穿忘了登记还有3条被当成样衣挂出去压根没进系统。更头疼的是客户复购张姐上周买了米白针织衫这周来问“有没有同款大一号的”老板娘翻遍微信聊天记录都找不到上次订单号最后只能靠模糊记忆瞎猜错失成交。这就是绝大多数小微服装店主的真实日常。他们不需要ERP那种动辄几十万、要配IT专员、培训三个月才能上手的庞然大物但Excel表格也早就不堪重负一个表里混着供应商信息、尺码颜色变体、不同批次进货价、会员积分、微信订单备注……稍一筛选就乱套复制粘贴三次后数据就对不上。而市面上很多标榜“SaaS进销存”的小程序要么功能阉割严重比如根本不支持“同一款衣服分S/M/L/XL多个库存单元独立管理”要么年费贵得离谱一年两千块对月流水三万的小店来说就是多卖二十件T恤的成本更别说数据全在别人服务器上换平台时连客户手机号都导不出来。这套基于Django开发的服装进销存系统就是为解决这种“不上不下”的尴尬而生的。它不是从零造轮子而是用Python生态里最成熟、文档最全、部署最轻量的Web框架扎扎实实把服装行业最刚需的三个痛点——库存实时性、客户可追溯性、权限可控性——用最小必要功能闭环打通。关键词里的“Django进销存”不是技术堆砌而是指它天然具备Web服务能力能跑在一台几百块的树莓派或学生党闲置的旧笔记本上不用租云服务器“服装库存管理”意味着它原生支持“款号颜色尺码”三级组合建模一条裙子的S码和XL码是两个完全独立的库存单元出库时选中“裙子-藏青-S”系统只扣这个SKU的库存绝不会误扣M码“双角色权限”则直击小店管理现实老板自己是管理员管所有数据店员是操作员只能录单、查客户、看自己经手的单据删不了客户、改不了历史价格、看不到其他同事的业绩——权限颗粒度细到字段级不是简单“登录即可见全部”。我带过三个本地服装工作室落地这套系统最短的一次从下载源码到店员能独立开单只用了4小时。它不追求炫酷的BI大屏但每一步操作都有明确反馈入库单保存成功后页面立刻刷新显示最新库存出库时输入数量超过余量不是报错跳转而是红色文字浮层提示“藏青-S仅剩2件当前输入5件超出3件”光标自动聚焦到该行让你当场修改。这种“所见即所得”的确定感才是小微经营者真正需要的确定性。它适合谁如果你是刚起步的淘宝档口、大学城周边的潮牌集合店、或者转型做私域的老牌童装店只要你还在用本子或Excel记账这套系统就是你现在就能抄起来用的“数字账本”。2. 系统整体设计与思路拆解为什么选择Django而不是Flask或VueNode很多人看到“进销存系统”第一反应是“前端用Vue做个漂亮界面后端用Node.js写API”。但当我真正蹲点三家服装店观察店员操作流程后果断放弃了这个方案。原因很实在店员平均年龄32岁手机微信用得溜但面对浏览器地址栏输入localhost:8080这种事会本能皱眉她们需要的是“点开图标就能用”而不是“先装Node环境、再npm install、最后yarn serve”。Django的MTVModel-Template-View架构恰好完美匹配这个需求——它把数据库模型Model、页面模板Template、业务逻辑View三者物理隔离又通过URL路由天然串联最终打包成一个可执行的manage.py文件双击就能启动服务。PyCharm打开即运行连虚拟环境都不用手动激活这对非技术背景的店主就是降维打击。具体到技术选型我们做了几处关键取舍第一数据库坚持SQLite起步MySQL作为可选升级项。有人质疑“SQLite不是只能单用户吗店里两个人同时开单会不会锁死”这是典型误解。SQLite的“单用户”指的是不能像MySQL那样支持数百并发连接但它对读写锁的处理极其高效——在服装店这种日均单据50张、峰值并发3人的场景下SQLite的写入延迟稳定在8ms以内实测数据。更重要的是它零配置没有服务进程、无需用户名密码、整个数据库就是一个.db文件。店主第一次使用删掉db.sqlite3重启服务一切归零比清空Excel还干脆。而附带的jxc_db.sql脚本和详细配置说明本质是给未来留的扩展接口当店铺扩张到三家分店、日单破百时只需替换DATABASES配置、执行sql脚本导入数据无缝切换到MySQL所有业务代码一行不用改。这种“现在够用、未来可扩”的设计比一上来就强推MySQL导致部署失败要务实得多。第二权限模型采用Django内置Auth系统深度定制而非自研RBAC。Django自带的User模型和Group权限体系经过十多年生产环境锤炼安全性远超新手手写的权限中间件。我们没重造轮子而是基于它做了两层加固- 在用户模型上扩展了is_operator布尔字段默认False管理员账号manage/123456手动设为True- 所有操作员视图函数前加装饰器user_passes_test(lambda u: u.is_authenticated and not u.is_staff)直接拦截未登录或管理员访问- 关键敏感操作如删除客户、修改历史单据额外增加if request.user.is_operator:判断确保操作员连按钮都看不到。这种“借力打力”的方式既规避了自研权限漏洞风险又让代码极度简洁——整个权限控制逻辑集中在不到20行代码里后续维护成本趋近于零。第三库存校验放在视图层而非数据库触发器追求可调试性。严格来说库存不足的校验应该由数据库约束保证。但考虑到店主可能需要临时“负库存出库”比如VIP客户急要先发货后补货我们把校验逻辑放在Django视图的form_valid()方法里def form_valid(self, form): # 获取出库单明细 items self.request.POST.getlist(clothes_id) quantities self.request.POST.getlist(quantity) for item_id, qty in zip(items, quantities): clothes Clothes.objects.get(iditem_id) if int(qty) clothes.stock_quantity: messages.error(self.request, f【{clothes.name} {clothes.color} {clothes.size}】库存仅剩{clothes.stock_quantity}件无法出库{qty}件) return self.form_invalid(form) # 校验通过才执行扣减 for item_id, qty in zip(items, quantities): clothes Clothes.objects.get(iditem_id) clothes.stock_quantity - int(qty) clothes.save() return super().form_valid(form)好处是什么当店员遇到“库存不足”提示时你能立刻在PyCharm调试窗口看到clothes.stock_quantity的实时值、qty的输入值甚至能断点进去看这条裙子是不是被其他单据锁住了。而数据库触发器一旦报错店主只会看到一串冰冷的SQL错误码毫无上下文。对小微系统而言“看得见、调得着”比“理论上更安全”重要十倍。3. 核心模块解析与实操要点服装、客户、单据三大实体如何精准建模这套系统的骨架由customer客户、clothes服装、jxc进销存三个Django应用撑起。它们不是简单罗列数据表而是紧扣服装行业业务语言把抽象概念翻译成程序员能写、店主能懂的字段。下面拆解每个模块的设计逻辑和实操细节。3.1 服装模块clothes为什么必须用“款号颜色尺码”三级主键服装行业的核心难点在于同一款衣服不同颜色、不同尺码库存、售价、供应商都可能完全不同。比如“复古牛仔外套”藏青色S码可能来自广州工厂进价120元而黑色M码是杭州档口现货进价135元XL码甚至还没进货库存为0。如果用传统“商品名称”作为唯一标识系统根本无法区分这三者。因此clothes/models.py中定义了Clothes模型其关键字段如下class Clothes(models.Model): code models.CharField(款号, max_length50, help_text如JD2024-001) name models.CharField(名称, max_length100) color models.CharField(颜色, max_length20) size models.CharField(尺码, max_length20) stock_quantity models.PositiveIntegerField(库存数量, default0) purchase_price models.DecimalField(进货价, max_digits8, decimal_places2, default0) selling_price models.DecimalField(零售价, max_digits8, decimal_places2, default0) supplier models.ForeignKey(Supplier, on_deletemodels.SET_NULL, nullTrue, blankTrue, verbose_name供应商) # 其他字段...这里的关键设计是code、color、size三者组合构成业务主键虽未设DB主键但逻辑上不可重复。这意味着- 录入“JD2024-001-复古牛仔外套”时必须分别录入藏青-S、藏青-M、黑色-S等多条记录- 出库单选择商品时下拉列表显示的是“JD2024-001 藏青 S”、“JD2024-001 藏青 M”而非笼统的“复古牛仔外套”- 库存预警触发条件也是针对每个“款号颜色尺码”组合单独计算。提示在templates/clothes/clothes_form.html中我们特意将颜色、尺码做成下拉选择框并预置了常用值S/M/L/XL、S/M/L/XL/XXL、藏青/酒红/燕麦/奶白等店员录入时只需点选避免手输错误。实测下来新店员10分钟就能熟练录入50款新品。3.2 客户模块customer如何让“回头客”信息真正可用很多进销存系统把客户当成静态档案只存姓名电话。但这对服装店毫无价值——张姐买过三次但每次买的都是不同品类第一次买裤子第二次买上衣第三次买裙子系统若不能关联她的购买偏好就只是个通讯录。因此customer/models.py中的Customer模型除了基础字段重点强化了两点-消费行为沉淀通过外键关联JxcRecord出入库记录形成“客户→订单→商品”的完整链路-标签化管理增加tags字段CharField支持手动添加“孕妇装常客”、“高端客户”、“团购团长”等标签方便后续精准营销。更关键的是在客户详情页templates/customer/customer_detail.html我们嵌入了一个动态表格实时展示该客户最近5笔交易| 日期 | 单据类型 | 商品明细 | 金额 | 操作员 ||------|----------|----------|------|--------|| 2024-03-15 | 出库单 | JD2024-001 藏青 S ×2, JD2024-002 酒红 M ×1 | ¥598.00 | 小李 || 2024-02-28 | 出库单 | JD2024-003 奶白 L ×1 | ¥299.00 | 小王 |这个表格不是静态快照而是通过Django ORM的select_related()和prefetch_related()优化查询确保即使客户有上百笔订单页面加载也不卡顿。店主点开张姐档案3秒内就能看到她最近买了什么、花了多少、谁服务的下次推荐新品时自然知道该推“同色系阔腿裤”还是“同价位针织衫”。3.3 进销存模块jxc单据如何实现“一次录入、多方联动”jxc应用是系统的心脏它包含InboundOrder入库单和OutboundOrder出库单两个核心模型。它们的设计哲学是单据本身不存商品数据只存关系商品数据永远只在clothes表里维护。这样做的好处是数据一致性——当某款裙子的零售价从¥299调整为¥329时所有历史出库单的金额不会自动变更符合会计准则但新单据会立即生效。以OutboundOrder为例其模型结构为class OutboundOrder(models.Model): order_no models.CharField(单据编号, max_length50, uniqueTrue) customer models.ForeignKey(Customer, on_deletemodels.CASCADE, verbose_name客户) operator models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name操作员) created_at models.DateTimeField(创建时间, auto_now_addTrue) total_amount models.DecimalField(总金额, max_digits10, decimal_places2, default0) class OutboundItem(models.Model): order models.ForeignKey(OutboundOrder, on_deletemodels.CASCADE, related_nameitems) clothes models.ForeignKey(Clothes, on_deletemodels.CASCADE, verbose_name服装) quantity models.PositiveIntegerField(数量) price models.DecimalField(单价, max_digits8, decimal_places2) amount models.DecimalField(金额, max_digits10, decimal_places2)注意OutboundItem表的存在——它把一张出库单和多款服装的关系拆解成标准的“一对多”结构。这样带来的实操优势是- 录单时前端用JavaScript动态添加行每行独立选择服装、输入数量系统自动计算该行金额quantity × price并汇总到单据总金额- 提交时后端遍历所有OutboundItem逐条校验库存只要有一条超限整单拒绝提交- 查询时可以轻松统计“某款衣服在Q1的总销量”只需OutboundItem.objects.filter(clothes_idxxx).aggregate(Sum(quantity))。注意在jxc/views.py的OutboundOrderCreateView中我们重写了get_context_data()方法预先加载了所有Clothes对象到模板上下文并按“款号-颜色-尺码”格式化显示避免前端AJAX请求造成卡顿。这是PyCharm调试时发现的性能瓶颈实测页面渲染速度提升40%。4. 实操过程与核心环节实现从零部署到首单开出的完整路径现在我们把这套系统真正跑起来。整个过程分为四个阶段环境准备、数据库切换、账号初始化、首单实战。每一步都附带真实截图级的操作指令和避坑指南确保你跟着做不出错。4.1 环境准备PyCharm Python 3.7 Django 2.2 的极简配置前提条件你的电脑已安装Python 3.7验证命令python --version应输出Python 3.7.x并安装了PyCharm Community Edition免费版足够。步骤详解1.下载并解压源码包将提供的压缩包解压到任意目录例如D:\clothes_jxc。确保目录下能看到manage.py、requirements.txt、jxc_db.sql等文件。在PyCharm中打开项目启动PyCharm →Open→ 选择D:\clothes_jxc文件夹 → 等待右下角索引完成约30秒。配置Python解释器File→SettingsWindows或PyCharm→PreferencesMac→Project: clothes_jxc→Python Interpreter→ 点击右上角号 → 选择System Interpreter→ 浏览到你的Python 3.7安装路径如C:\Python37\python.exe→ 点击OK。安装依赖包在PyCharm底部打开Terminal标签页输入bash pip install -r requirements.txt此命令会自动安装Django 2.2、Pillow处理图片、pytz时区支持等所有依赖。如果遇到网络问题可临时换清华源bash pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple/实操心得很多新手卡在第一步——找不到Python解释器路径。记住一个技巧在Windows搜索栏输入python右键“打开文件所在位置”路径就是C:\Users\XXX\AppData\Local\Programs\Python\Python37\里面的python.exe就是你要找的。Mac用户可在终端输入which python3.7获取路径。4.2 数据库切换从SQLite平滑迁移到MySQL含jxc_db.sql详解默认SQLite开箱即用但如果你计划长期使用或对接其他系统MySQL是更稳妥的选择。迁移过程分三步第一步准备MySQL环境- 下载安装MySQL 5.7或8.0推荐使用XAMPP或Docker避免手动配置- 启动MySQL服务用phpMyAdmin或命令行创建数据库jxc_db字符集选utf8mb4兼容中文和emoji- 创建用户jxc_user密码jxc_pass赋予jxc_db库的所有权限。第二步执行jxc_db.sql脚本该SQL文件位于资源包根目录它不是简单的CREATE TABLE而是包含了完整的表结构、索引、外键约束及初始管理员数据。关键内容解读-- 创建服装表注意stock_quantity字段设为NOT NULL且DEFAULT 0 CREATE TABLE clothes_clothes ( id int(11) NOT NULL AUTO_INCREMENT, code varchar(50) NOT NULL, name varchar(100) NOT NULL, color varchar(20) NOT NULL, size varchar(20) NOT NULL, stock_quantity int(11) NOT NULL DEFAULT 0, -- 其他字段... PRIMARY KEY (id), UNIQUE KEY unique_clothes (code,color,size) -- 三级唯一约束 ); -- 插入初始管理员账号用户名manage密码123456is_staff1表示管理员 INSERT INTO auth_user VALUES (1,pbkdf2_sha256$260000$...,2024-03-10 08:22:33.123456,1,manage,,manageexample.com,1,1,2024-03-10 08:22:33.123456,);在phpMyAdmin中选择jxc_db库 →导入→ 上传jxc_db.sql→ 执行。成功后你会看到12张表auth_user,clothes_clothes,customer_customer,jxc_inboundorder等。第三步修改Django配置打开clothes_jxc/settings.py找到DATABASES配置段注释掉SQLite部分取消注释MySQL部分并填入你的实际参数# DATABASES { # default: { # ENGINE: django.db.backends.sqlite3, # NAME: os.path.join(BASE_DIR, db.sqlite3), # } # } DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: jxc_db, USER: jxc_user, PASSWORD: jxc_pass, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { init_command: SET sql_modeSTRICT_TRANS_TABLES, charset: utf8mb4, }, } }注意MySQL驱动需额外安装。在PyCharm Terminal中执行bash pip install mysqlclient如果报错mysql_config not foundWindows用户请下载预编译wheelhttps://www.lfd.uci.edu/~gohlke/pythonlibs/#mysqlclientMac用户执行brew install mysql-client后重试。4.3 账号初始化管理员与操作员的创建逻辑系统预置了管理员账号manage/123456但操作员需要店主自行创建。创建过程遵循最小权限原则管理员登录与操作员创建1. 启动Django服务在PyCharm Terminal中执行bash python manage.py runserver浏览器访问http://127.0.0.1:8000/admin/用manage/123456登录。进入Users管理页 →Add user→ 填写用户名如xiaoli、邮箱、密码两次输入→ 点击Save and continue editing。关键一步取消勾选Staff status勾选Active在Groups中选择Operators若无此组先在Groups页创建→Save。这样创建的用户后台可见但无法访问/admin/只能走前台登录页。操作员前台注册流程- 访问http://127.0.0.1:8000/user/register/此URL在README.md中有明确标注- 输入用户名、密码、确认密码、手机号用于后续短信通知可选- 提交后系统自动发送欢迎邮件需配置SMTP详见README.md的邮件章节并生成操作员账号。提示操作员注册后默认拥有add_outboundorder,view_customer,change_clothes等权限但没有delete_customer或add_user权限。你可以在Django Admin的Groups页点击Operators组勾选/取消权限复选框实时调整无需改代码。4.4 首单实战从入库到出库的全流程演示现在我们模拟一个真实场景店主上午从广州工厂进货10条“JD2024-001 藏青 S”裙子下午张姐来店买走2条。Step 1录入服装基础信息- 登录管理员账号 →Clothes→Add Clothes- 填写款号JD2024-001、名称复古牛仔外套、颜色藏青、尺码S、库存0、进货价120.00、零售价299.00- 点击Save系统返回列表页显示新录入的服装。Step 2创建入库单- 切换到操作员账号或用管理员临时切换→进销存→新建入库单- 选择供应商若未创建先在Suppliers页添加- 点击添加明细按钮弹出选择框在服装列表中找到JD2024-001 藏青 S输入数量10单价120.00- 系统自动计算金额1200.00点击保存- 页面跳转至入库单详情页顶部显示单据号IN20240315001下方明细表显示“藏青 S ×10”库存数量实时更新为10。Step 3创建出库单触发库存预警- 同一操作员 →进销存→新建出库单- 选择客户张姐若无先在Customers页创建填姓名、电话、微信- 点击添加明细选择JD2024-001 藏青 S输入数量5-此时系统检测到当前库存为105≤10允许提交- 若误输15点击保存瞬间页面顶部出现红色提示【复古牛仔外套 藏青 S】库存仅剩10件无法出库15件并自动聚焦到数量输入框光标闪烁等待你修改。修改为2保存成功库存更新为8张姐的客户档案中自动新增一笔交易记录。实操心得库存预警不是简单的“if stock qty”而是结合了事务原子性。我们用Django的transaction.atomic()包裹整个出库逻辑确保“校验-扣减-记录”三步要么全成功要么全回滚。曾有店主反馈“点了保存没反应”排查发现是浏览器禁用了JavaScript导致前端校验失效后端校验又因网络延迟未及时返回。因此我们在templates/base.html中强制加入script检测若JS禁用页面直接显示“请启用JavaScript以保障库存准确”这是血泪教训换来的用户体验。5. 常见问题与排查技巧实录那些PyCharm调试器帮你揪出的“幽灵Bug”在帮三家服装店部署过程中我们记录了27个高频问题。下面精选6个最具代表性的问题给出精准定位方法和一招解决的技巧。这些问题90%的新手都会踩但官方文档往往只字不提。5.1 问题启动python manage.py runserver报错“No module named ‘PIL’”现象终端输出红色错误末尾是ModuleNotFoundError: No module named PIL服务无法启动。原因分析PILPython Imaging Library是Django处理图片上传的依赖但现代Python环境默认安装的是它的继任者Pillow。requirements.txt中写的是Pillow8.0.0但某些旧版pip会忽略版本号尝试安装已废弃的PIL包。排查步骤1. 在PyCharm Terminal中执行pip list | findstr PILWindows或pip list | grep PILMac/Linux查看是否安装了Pillow2. 若未安装执行pip install Pillow3. 若已安装但报错执行pip uninstall PIL确认卸载旧包再pip install Pillow。终极解决直接编辑requirements.txt将PIL行彻底删除只保留Pillow8.0.0。这是最干净的方案。5.2 问题管理员登录/admin/后看不到customer、clothes等应用菜单现象登录Django Admin左侧只有Authentication and Authorization用户、组没有Customers、Clothes等业务菜单。原因分析Django Admin需要显式注册模型。检查customer/admin.py和clothes/admin.py确认是否包含类似以下代码from django.contrib import admin from .models import Customer, Clothes admin.site.register(Customer) admin.site.register(Clothes)如果缺失admin.site.register()模型就不会出现在Admin界面。排查步骤1. 打开customer/admin.py检查是否有admin.site.register(Customer)2. 同理检查clothes/admin.py3. 若缺失在对应文件末尾添加注册语句4. 重启Django服务CtrlC停止再runserver。注意注册时务必导入正确的模型类。曾有新手把from customer.models import Customer错写成from clothes.models import Customer导致ImportError。5.3 问题出库单提交后库存数量没变化还是原来的值现象操作员创建出库单数量填5点击保存页面显示“保存成功”但回到服装列表该款衣服库存仍是10未扣减为5。原因分析这是最隐蔽的Bug之一根源在于OutboundItem模型的amount字段计算逻辑。原始代码中amount是quantity × price但price字段在OutboundItem中是冗余存储如果入库时价格变了出库单的price却没同步更新就会导致amount不准进而影响财务统计。但更致命的是我们的库存扣减逻辑写在了OutboundOrder的save()方法里而Django Admin默认不调用模型的save()而是直接执行SQL INSERT。排查步骤1. 在jxc/models.py中找到OutboundOrder模型确认库存扣减逻辑是否在save()方法内2. 查看jxc/admin.py确认OutboundOrderAdmin是否重写了save_model()方法3. 正确做法是将库存扣减逻辑移出save()放到视图层如OutboundOrderCreateView.form_valid()并在Admin中重写save_model()调用同一逻辑。终极解决在jxc/admin.py中添加from django.contrib import admin from .models import OutboundOrder from .views import process_outbound_order # 引入视图中的扣减函数 admin.register(OutboundOrder) class OutboundOrderAdmin(admin.ModelAdmin): def save_model(self, request, obj, form, change): super().save_model(request, obj, form, change) if not change: # 仅对新建单据执行扣减 process_outbound_order(obj) # 调用统一扣减函数5.4 问题客户列表页加载极慢滚动卡顿现象进入/customer/页面浏览器转圈10秒以上F12看Networkcustomer_list.json请求耗时8秒。原因分析customer应用的CustomerListView使用了ListView通用视图但未做查询优化。默认queryset Customer.objects.all()会加载所有客户及其关联的订单、地址等形成N1查询。当客户数超200时数据库压力陡增。排查步骤1. 在customer/views.py中找到CustomerListView2. 查看get_queryset()方法确认是否用了select_related()或prefetch_related()3. 使用Django Debug Toolbar已集成在项目中查看SQL查询次数。终极解决修改get_queryset()def get_queryset(self): return Customer.objects.prefetch_related( outboundorder_set__outbounditem_set__clothes ).all()这一行代码将原本可能上百次的查询压缩为3次客户主表、订单表、明细表实测200客户列表加载时间从8秒降至0.6秒。5.5 问题MySQL迁移后中文显示为“???”乱码现象切换MySQL后服装名称、客户姓名变成问号如“复古牛仔外套”显示为“????????”。原因分析MySQL数据库、表、字段的字符集不一致。jxc_db.sql脚本虽指定了utf8mb4但MySQL服务器默认字符集可能是latin1导致导入时编码转换失败。排查步骤1. 在phpMyAdmin的SQL页执行SHOW VARIABLES LIKE character_set%;查看character_set_server值2. 执行SHOW CREATE DATABASE jxc_db;确认数据库字符集3. 执行SHOW CREATE TABLE customer_customer;确认表字符集。终极解决- 修改MySQL配置文件my.iniWindows或my.cnfLinux在[mysqld]段添加ini character-set-server utf8mb4 collation-server utf8mb4_unicode_ci- 重启MySQL服务- 重新执行jxc_db.sql脚本。5.6 问题操作员注册后收不到欢迎邮件现象用户在/user/register/填写信息点击注册页面跳转到“注册成功”但邮箱没收到任何邮件。原因分析Django邮件功能需要SMTP服务器配置。默认配置指向本地localhost:25但现代操作系统基本不开启此服务。排查步骤1. 检查settings.py中EMAIL_BACKEND是否为django.core.mail.backends.smtp.EmailBackend2. 检查EMAIL_HOST,EMAIL_PORT,EMAIL_HOST_USER,EMAIL_HOST_PASSWORD是否正确配置3. 在PyCharm Terminal中进入Django shell测试pythonpython manage.py shellfrom django.core.mail import send_mailsend_mail(‘测试’, ‘这是一封测试邮件’, ‘fromexample.com’, [‘toexample.com’])终极解决推荐使用QQ邮箱SMTP免费、稳定- 开通QQ邮箱的POP3/SMTP服务设置 → 账户 → “POP3/IMAP/SMTP/Exchange/CardDAV/CalDAV服务” → 开启SMTP- 获取授权码非邮箱密码- 在settings.py中配置python EMAIL_BACKEND django.core.mail.backends.smtp.EmailBackend EMAIL_HOST smtp.qq.com EMAIL_PORT 587 EMAIL_USE_TLS True EMAIL_HOST_USER your_qqqq.com EMAIL_HOST_PASSWORD your_authorization_code # 不是邮箱密码最后分享一个小技巧所有邮件模板templates/registration/email/welcome.txt都采用纯文本格式避免HTML邮件被Gmail等服务商过滤。我们测试过纯文本邮件到达率100%而带链接的HTML邮件有15%概率进垃圾箱。对店主而言能收到比好看重要一万倍。本文还有配套的精品资源点击获取简介专为小型服装店设计的Django进销存管理系统开箱即用PyCharm可直接运行支持Python 3.7 Django 2.2。默认使用SQLite附带MySQL迁移脚本jxc_db.sql和详细配置说明一键切换数据库。系统分操作员和管理员两类角色操作员能注册登录维护客户资料、录入服装信息、创建入库单和出库单每张单据支持添加多款服装明细提交时自动校验库存——出库数量超过当前余量会实时弹出‘库存不足’提示辅助及时补货管理员账号manage/123456拥有全部数据管理权限包括客户档案、服装资料、所有出入库记录及操作员账户的增删改查。项目结构规范含完整templates页面模板、static静态资源、utils通用工具模块以及customer客户、clothes服装、jxc进销存等业务应用还提供requirements.txt依赖清单和README.md部署指南适合教学演示、个体服装店快速上线或基于现有功能做定制开发。本文还有配套的精品资源点击获取
服装店用Django进销存系统：带库存预警、客户商品管理与操作员/管理员双权限
发布时间：2026/7/2 22:48:16
本文还有配套的精品资源点击获取简介专为小型服装店设计的Django进销存管理系统开箱即用PyCharm可直接运行支持Python 3.7 Django 2.2。默认使用SQLite附带MySQL迁移脚本jxc_db.sql和详细配置说明一键切换数据库。系统分操作员和管理员两类角色操作员能注册登录维护客户资料、录入服装信息、创建入库单和出库单每张单据支持添加多款服装明细提交时自动校验库存——出库数量超过当前余量会实时弹出‘库存不足’提示辅助及时补货管理员账号manage/123456拥有全部数据管理权限包括客户档案、服装资料、所有出入库记录及操作员账户的增删改查。项目结构规范含完整templates页面模板、static静态资源、utils通用工具模块以及customer客户、clothes服装、jxc进销存等业务应用还提供requirements.txt依赖清单和README.md部署指南适合教学演示、个体服装店快速上线或基于现有功能做定制开发。1. 项目概述为什么一个小服装店真需要一套“不重不卡、不教不会”的进销存系统你有没有见过这样的场景一家开了五年的社区女装店老板娘每天早上七点到店第一件事不是整理货架而是翻三本本子——一本记进货谁家工厂、什么款、几件、多少钱一本记销售哪天卖给谁、什么码、收了多少钱还有一本是手写的库存流水账。月底盘库她得把三本子摊在收银台上拿计算器按半小时再对着货架一件件核对经常发现“明明记得进了20条阔腿裤怎么只剩13条”——结果一查有7条被隔壁店员临时借去给顾客试穿忘了登记还有3条被当成样衣挂出去压根没进系统。更头疼的是客户复购张姐上周买了米白针织衫这周来问“有没有同款大一号的”老板娘翻遍微信聊天记录都找不到上次订单号最后只能靠模糊记忆瞎猜错失成交。这就是绝大多数小微服装店主的真实日常。他们不需要ERP那种动辄几十万、要配IT专员、培训三个月才能上手的庞然大物但Excel表格也早就不堪重负一个表里混着供应商信息、尺码颜色变体、不同批次进货价、会员积分、微信订单备注……稍一筛选就乱套复制粘贴三次后数据就对不上。而市面上很多标榜“SaaS进销存”的小程序要么功能阉割严重比如根本不支持“同一款衣服分S/M/L/XL多个库存单元独立管理”要么年费贵得离谱一年两千块对月流水三万的小店来说就是多卖二十件T恤的成本更别说数据全在别人服务器上换平台时连客户手机号都导不出来。这套基于Django开发的服装进销存系统就是为解决这种“不上不下”的尴尬而生的。它不是从零造轮子而是用Python生态里最成熟、文档最全、部署最轻量的Web框架扎扎实实把服装行业最刚需的三个痛点——库存实时性、客户可追溯性、权限可控性——用最小必要功能闭环打通。关键词里的“Django进销存”不是技术堆砌而是指它天然具备Web服务能力能跑在一台几百块的树莓派或学生党闲置的旧笔记本上不用租云服务器“服装库存管理”意味着它原生支持“款号颜色尺码”三级组合建模一条裙子的S码和XL码是两个完全独立的库存单元出库时选中“裙子-藏青-S”系统只扣这个SKU的库存绝不会误扣M码“双角色权限”则直击小店管理现实老板自己是管理员管所有数据店员是操作员只能录单、查客户、看自己经手的单据删不了客户、改不了历史价格、看不到其他同事的业绩——权限颗粒度细到字段级不是简单“登录即可见全部”。我带过三个本地服装工作室落地这套系统最短的一次从下载源码到店员能独立开单只用了4小时。它不追求炫酷的BI大屏但每一步操作都有明确反馈入库单保存成功后页面立刻刷新显示最新库存出库时输入数量超过余量不是报错跳转而是红色文字浮层提示“藏青-S仅剩2件当前输入5件超出3件”光标自动聚焦到该行让你当场修改。这种“所见即所得”的确定感才是小微经营者真正需要的确定性。它适合谁如果你是刚起步的淘宝档口、大学城周边的潮牌集合店、或者转型做私域的老牌童装店只要你还在用本子或Excel记账这套系统就是你现在就能抄起来用的“数字账本”。2. 系统整体设计与思路拆解为什么选择Django而不是Flask或VueNode很多人看到“进销存系统”第一反应是“前端用Vue做个漂亮界面后端用Node.js写API”。但当我真正蹲点三家服装店观察店员操作流程后果断放弃了这个方案。原因很实在店员平均年龄32岁手机微信用得溜但面对浏览器地址栏输入localhost:8080这种事会本能皱眉她们需要的是“点开图标就能用”而不是“先装Node环境、再npm install、最后yarn serve”。Django的MTVModel-Template-View架构恰好完美匹配这个需求——它把数据库模型Model、页面模板Template、业务逻辑View三者物理隔离又通过URL路由天然串联最终打包成一个可执行的manage.py文件双击就能启动服务。PyCharm打开即运行连虚拟环境都不用手动激活这对非技术背景的店主就是降维打击。具体到技术选型我们做了几处关键取舍第一数据库坚持SQLite起步MySQL作为可选升级项。有人质疑“SQLite不是只能单用户吗店里两个人同时开单会不会锁死”这是典型误解。SQLite的“单用户”指的是不能像MySQL那样支持数百并发连接但它对读写锁的处理极其高效——在服装店这种日均单据50张、峰值并发3人的场景下SQLite的写入延迟稳定在8ms以内实测数据。更重要的是它零配置没有服务进程、无需用户名密码、整个数据库就是一个.db文件。店主第一次使用删掉db.sqlite3重启服务一切归零比清空Excel还干脆。而附带的jxc_db.sql脚本和详细配置说明本质是给未来留的扩展接口当店铺扩张到三家分店、日单破百时只需替换DATABASES配置、执行sql脚本导入数据无缝切换到MySQL所有业务代码一行不用改。这种“现在够用、未来可扩”的设计比一上来就强推MySQL导致部署失败要务实得多。第二权限模型采用Django内置Auth系统深度定制而非自研RBAC。Django自带的User模型和Group权限体系经过十多年生产环境锤炼安全性远超新手手写的权限中间件。我们没重造轮子而是基于它做了两层加固- 在用户模型上扩展了is_operator布尔字段默认False管理员账号manage/123456手动设为True- 所有操作员视图函数前加装饰器user_passes_test(lambda u: u.is_authenticated and not u.is_staff)直接拦截未登录或管理员访问- 关键敏感操作如删除客户、修改历史单据额外增加if request.user.is_operator:判断确保操作员连按钮都看不到。这种“借力打力”的方式既规避了自研权限漏洞风险又让代码极度简洁——整个权限控制逻辑集中在不到20行代码里后续维护成本趋近于零。第三库存校验放在视图层而非数据库触发器追求可调试性。严格来说库存不足的校验应该由数据库约束保证。但考虑到店主可能需要临时“负库存出库”比如VIP客户急要先发货后补货我们把校验逻辑放在Django视图的form_valid()方法里def form_valid(self, form): # 获取出库单明细 items self.request.POST.getlist(clothes_id) quantities self.request.POST.getlist(quantity) for item_id, qty in zip(items, quantities): clothes Clothes.objects.get(iditem_id) if int(qty) clothes.stock_quantity: messages.error(self.request, f【{clothes.name} {clothes.color} {clothes.size}】库存仅剩{clothes.stock_quantity}件无法出库{qty}件) return self.form_invalid(form) # 校验通过才执行扣减 for item_id, qty in zip(items, quantities): clothes Clothes.objects.get(iditem_id) clothes.stock_quantity - int(qty) clothes.save() return super().form_valid(form)好处是什么当店员遇到“库存不足”提示时你能立刻在PyCharm调试窗口看到clothes.stock_quantity的实时值、qty的输入值甚至能断点进去看这条裙子是不是被其他单据锁住了。而数据库触发器一旦报错店主只会看到一串冰冷的SQL错误码毫无上下文。对小微系统而言“看得见、调得着”比“理论上更安全”重要十倍。3. 核心模块解析与实操要点服装、客户、单据三大实体如何精准建模这套系统的骨架由customer客户、clothes服装、jxc进销存三个Django应用撑起。它们不是简单罗列数据表而是紧扣服装行业业务语言把抽象概念翻译成程序员能写、店主能懂的字段。下面拆解每个模块的设计逻辑和实操细节。3.1 服装模块clothes为什么必须用“款号颜色尺码”三级主键服装行业的核心难点在于同一款衣服不同颜色、不同尺码库存、售价、供应商都可能完全不同。比如“复古牛仔外套”藏青色S码可能来自广州工厂进价120元而黑色M码是杭州档口现货进价135元XL码甚至还没进货库存为0。如果用传统“商品名称”作为唯一标识系统根本无法区分这三者。因此clothes/models.py中定义了Clothes模型其关键字段如下class Clothes(models.Model): code models.CharField(款号, max_length50, help_text如JD2024-001) name models.CharField(名称, max_length100) color models.CharField(颜色, max_length20) size models.CharField(尺码, max_length20) stock_quantity models.PositiveIntegerField(库存数量, default0) purchase_price models.DecimalField(进货价, max_digits8, decimal_places2, default0) selling_price models.DecimalField(零售价, max_digits8, decimal_places2, default0) supplier models.ForeignKey(Supplier, on_deletemodels.SET_NULL, nullTrue, blankTrue, verbose_name供应商) # 其他字段...这里的关键设计是code、color、size三者组合构成业务主键虽未设DB主键但逻辑上不可重复。这意味着- 录入“JD2024-001-复古牛仔外套”时必须分别录入藏青-S、藏青-M、黑色-S等多条记录- 出库单选择商品时下拉列表显示的是“JD2024-001 藏青 S”、“JD2024-001 藏青 M”而非笼统的“复古牛仔外套”- 库存预警触发条件也是针对每个“款号颜色尺码”组合单独计算。提示在templates/clothes/clothes_form.html中我们特意将颜色、尺码做成下拉选择框并预置了常用值S/M/L/XL、S/M/L/XL/XXL、藏青/酒红/燕麦/奶白等店员录入时只需点选避免手输错误。实测下来新店员10分钟就能熟练录入50款新品。3.2 客户模块customer如何让“回头客”信息真正可用很多进销存系统把客户当成静态档案只存姓名电话。但这对服装店毫无价值——张姐买过三次但每次买的都是不同品类第一次买裤子第二次买上衣第三次买裙子系统若不能关联她的购买偏好就只是个通讯录。因此customer/models.py中的Customer模型除了基础字段重点强化了两点-消费行为沉淀通过外键关联JxcRecord出入库记录形成“客户→订单→商品”的完整链路-标签化管理增加tags字段CharField支持手动添加“孕妇装常客”、“高端客户”、“团购团长”等标签方便后续精准营销。更关键的是在客户详情页templates/customer/customer_detail.html我们嵌入了一个动态表格实时展示该客户最近5笔交易| 日期 | 单据类型 | 商品明细 | 金额 | 操作员 ||------|----------|----------|------|--------|| 2024-03-15 | 出库单 | JD2024-001 藏青 S ×2, JD2024-002 酒红 M ×1 | ¥598.00 | 小李 || 2024-02-28 | 出库单 | JD2024-003 奶白 L ×1 | ¥299.00 | 小王 |这个表格不是静态快照而是通过Django ORM的select_related()和prefetch_related()优化查询确保即使客户有上百笔订单页面加载也不卡顿。店主点开张姐档案3秒内就能看到她最近买了什么、花了多少、谁服务的下次推荐新品时自然知道该推“同色系阔腿裤”还是“同价位针织衫”。3.3 进销存模块jxc单据如何实现“一次录入、多方联动”jxc应用是系统的心脏它包含InboundOrder入库单和OutboundOrder出库单两个核心模型。它们的设计哲学是单据本身不存商品数据只存关系商品数据永远只在clothes表里维护。这样做的好处是数据一致性——当某款裙子的零售价从¥299调整为¥329时所有历史出库单的金额不会自动变更符合会计准则但新单据会立即生效。以OutboundOrder为例其模型结构为class OutboundOrder(models.Model): order_no models.CharField(单据编号, max_length50, uniqueTrue) customer models.ForeignKey(Customer, on_deletemodels.CASCADE, verbose_name客户) operator models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name操作员) created_at models.DateTimeField(创建时间, auto_now_addTrue) total_amount models.DecimalField(总金额, max_digits10, decimal_places2, default0) class OutboundItem(models.Model): order models.ForeignKey(OutboundOrder, on_deletemodels.CASCADE, related_nameitems) clothes models.ForeignKey(Clothes, on_deletemodels.CASCADE, verbose_name服装) quantity models.PositiveIntegerField(数量) price models.DecimalField(单价, max_digits8, decimal_places2) amount models.DecimalField(金额, max_digits10, decimal_places2)注意OutboundItem表的存在——它把一张出库单和多款服装的关系拆解成标准的“一对多”结构。这样带来的实操优势是- 录单时前端用JavaScript动态添加行每行独立选择服装、输入数量系统自动计算该行金额quantity × price并汇总到单据总金额- 提交时后端遍历所有OutboundItem逐条校验库存只要有一条超限整单拒绝提交- 查询时可以轻松统计“某款衣服在Q1的总销量”只需OutboundItem.objects.filter(clothes_idxxx).aggregate(Sum(quantity))。注意在jxc/views.py的OutboundOrderCreateView中我们重写了get_context_data()方法预先加载了所有Clothes对象到模板上下文并按“款号-颜色-尺码”格式化显示避免前端AJAX请求造成卡顿。这是PyCharm调试时发现的性能瓶颈实测页面渲染速度提升40%。4. 实操过程与核心环节实现从零部署到首单开出的完整路径现在我们把这套系统真正跑起来。整个过程分为四个阶段环境准备、数据库切换、账号初始化、首单实战。每一步都附带真实截图级的操作指令和避坑指南确保你跟着做不出错。4.1 环境准备PyCharm Python 3.7 Django 2.2 的极简配置前提条件你的电脑已安装Python 3.7验证命令python --version应输出Python 3.7.x并安装了PyCharm Community Edition免费版足够。步骤详解1.下载并解压源码包将提供的压缩包解压到任意目录例如D:\clothes_jxc。确保目录下能看到manage.py、requirements.txt、jxc_db.sql等文件。在PyCharm中打开项目启动PyCharm →Open→ 选择D:\clothes_jxc文件夹 → 等待右下角索引完成约30秒。配置Python解释器File→SettingsWindows或PyCharm→PreferencesMac→Project: clothes_jxc→Python Interpreter→ 点击右上角号 → 选择System Interpreter→ 浏览到你的Python 3.7安装路径如C:\Python37\python.exe→ 点击OK。安装依赖包在PyCharm底部打开Terminal标签页输入bash pip install -r requirements.txt此命令会自动安装Django 2.2、Pillow处理图片、pytz时区支持等所有依赖。如果遇到网络问题可临时换清华源bash pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple/实操心得很多新手卡在第一步——找不到Python解释器路径。记住一个技巧在Windows搜索栏输入python右键“打开文件所在位置”路径就是C:\Users\XXX\AppData\Local\Programs\Python\Python37\里面的python.exe就是你要找的。Mac用户可在终端输入which python3.7获取路径。4.2 数据库切换从SQLite平滑迁移到MySQL含jxc_db.sql详解默认SQLite开箱即用但如果你计划长期使用或对接其他系统MySQL是更稳妥的选择。迁移过程分三步第一步准备MySQL环境- 下载安装MySQL 5.7或8.0推荐使用XAMPP或Docker避免手动配置- 启动MySQL服务用phpMyAdmin或命令行创建数据库jxc_db字符集选utf8mb4兼容中文和emoji- 创建用户jxc_user密码jxc_pass赋予jxc_db库的所有权限。第二步执行jxc_db.sql脚本该SQL文件位于资源包根目录它不是简单的CREATE TABLE而是包含了完整的表结构、索引、外键约束及初始管理员数据。关键内容解读-- 创建服装表注意stock_quantity字段设为NOT NULL且DEFAULT 0 CREATE TABLE clothes_clothes ( id int(11) NOT NULL AUTO_INCREMENT, code varchar(50) NOT NULL, name varchar(100) NOT NULL, color varchar(20) NOT NULL, size varchar(20) NOT NULL, stock_quantity int(11) NOT NULL DEFAULT 0, -- 其他字段... PRIMARY KEY (id), UNIQUE KEY unique_clothes (code,color,size) -- 三级唯一约束 ); -- 插入初始管理员账号用户名manage密码123456is_staff1表示管理员 INSERT INTO auth_user VALUES (1,pbkdf2_sha256$260000$...,2024-03-10 08:22:33.123456,1,manage,,manageexample.com,1,1,2024-03-10 08:22:33.123456,);在phpMyAdmin中选择jxc_db库 →导入→ 上传jxc_db.sql→ 执行。成功后你会看到12张表auth_user,clothes_clothes,customer_customer,jxc_inboundorder等。第三步修改Django配置打开clothes_jxc/settings.py找到DATABASES配置段注释掉SQLite部分取消注释MySQL部分并填入你的实际参数# DATABASES { # default: { # ENGINE: django.db.backends.sqlite3, # NAME: os.path.join(BASE_DIR, db.sqlite3), # } # } DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: jxc_db, USER: jxc_user, PASSWORD: jxc_pass, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { init_command: SET sql_modeSTRICT_TRANS_TABLES, charset: utf8mb4, }, } }注意MySQL驱动需额外安装。在PyCharm Terminal中执行bash pip install mysqlclient如果报错mysql_config not foundWindows用户请下载预编译wheelhttps://www.lfd.uci.edu/~gohlke/pythonlibs/#mysqlclientMac用户执行brew install mysql-client后重试。4.3 账号初始化管理员与操作员的创建逻辑系统预置了管理员账号manage/123456但操作员需要店主自行创建。创建过程遵循最小权限原则管理员登录与操作员创建1. 启动Django服务在PyCharm Terminal中执行bash python manage.py runserver浏览器访问http://127.0.0.1:8000/admin/用manage/123456登录。进入Users管理页 →Add user→ 填写用户名如xiaoli、邮箱、密码两次输入→ 点击Save and continue editing。关键一步取消勾选Staff status勾选Active在Groups中选择Operators若无此组先在Groups页创建→Save。这样创建的用户后台可见但无法访问/admin/只能走前台登录页。操作员前台注册流程- 访问http://127.0.0.1:8000/user/register/此URL在README.md中有明确标注- 输入用户名、密码、确认密码、手机号用于后续短信通知可选- 提交后系统自动发送欢迎邮件需配置SMTP详见README.md的邮件章节并生成操作员账号。提示操作员注册后默认拥有add_outboundorder,view_customer,change_clothes等权限但没有delete_customer或add_user权限。你可以在Django Admin的Groups页点击Operators组勾选/取消权限复选框实时调整无需改代码。4.4 首单实战从入库到出库的全流程演示现在我们模拟一个真实场景店主上午从广州工厂进货10条“JD2024-001 藏青 S”裙子下午张姐来店买走2条。Step 1录入服装基础信息- 登录管理员账号 →Clothes→Add Clothes- 填写款号JD2024-001、名称复古牛仔外套、颜色藏青、尺码S、库存0、进货价120.00、零售价299.00- 点击Save系统返回列表页显示新录入的服装。Step 2创建入库单- 切换到操作员账号或用管理员临时切换→进销存→新建入库单- 选择供应商若未创建先在Suppliers页添加- 点击添加明细按钮弹出选择框在服装列表中找到JD2024-001 藏青 S输入数量10单价120.00- 系统自动计算金额1200.00点击保存- 页面跳转至入库单详情页顶部显示单据号IN20240315001下方明细表显示“藏青 S ×10”库存数量实时更新为10。Step 3创建出库单触发库存预警- 同一操作员 →进销存→新建出库单- 选择客户张姐若无先在Customers页创建填姓名、电话、微信- 点击添加明细选择JD2024-001 藏青 S输入数量5-此时系统检测到当前库存为105≤10允许提交- 若误输15点击保存瞬间页面顶部出现红色提示【复古牛仔外套 藏青 S】库存仅剩10件无法出库15件并自动聚焦到数量输入框光标闪烁等待你修改。修改为2保存成功库存更新为8张姐的客户档案中自动新增一笔交易记录。实操心得库存预警不是简单的“if stock qty”而是结合了事务原子性。我们用Django的transaction.atomic()包裹整个出库逻辑确保“校验-扣减-记录”三步要么全成功要么全回滚。曾有店主反馈“点了保存没反应”排查发现是浏览器禁用了JavaScript导致前端校验失效后端校验又因网络延迟未及时返回。因此我们在templates/base.html中强制加入script检测若JS禁用页面直接显示“请启用JavaScript以保障库存准确”这是血泪教训换来的用户体验。5. 常见问题与排查技巧实录那些PyCharm调试器帮你揪出的“幽灵Bug”在帮三家服装店部署过程中我们记录了27个高频问题。下面精选6个最具代表性的问题给出精准定位方法和一招解决的技巧。这些问题90%的新手都会踩但官方文档往往只字不提。5.1 问题启动python manage.py runserver报错“No module named ‘PIL’”现象终端输出红色错误末尾是ModuleNotFoundError: No module named PIL服务无法启动。原因分析PILPython Imaging Library是Django处理图片上传的依赖但现代Python环境默认安装的是它的继任者Pillow。requirements.txt中写的是Pillow8.0.0但某些旧版pip会忽略版本号尝试安装已废弃的PIL包。排查步骤1. 在PyCharm Terminal中执行pip list | findstr PILWindows或pip list | grep PILMac/Linux查看是否安装了Pillow2. 若未安装执行pip install Pillow3. 若已安装但报错执行pip uninstall PIL确认卸载旧包再pip install Pillow。终极解决直接编辑requirements.txt将PIL行彻底删除只保留Pillow8.0.0。这是最干净的方案。5.2 问题管理员登录/admin/后看不到customer、clothes等应用菜单现象登录Django Admin左侧只有Authentication and Authorization用户、组没有Customers、Clothes等业务菜单。原因分析Django Admin需要显式注册模型。检查customer/admin.py和clothes/admin.py确认是否包含类似以下代码from django.contrib import admin from .models import Customer, Clothes admin.site.register(Customer) admin.site.register(Clothes)如果缺失admin.site.register()模型就不会出现在Admin界面。排查步骤1. 打开customer/admin.py检查是否有admin.site.register(Customer)2. 同理检查clothes/admin.py3. 若缺失在对应文件末尾添加注册语句4. 重启Django服务CtrlC停止再runserver。注意注册时务必导入正确的模型类。曾有新手把from customer.models import Customer错写成from clothes.models import Customer导致ImportError。5.3 问题出库单提交后库存数量没变化还是原来的值现象操作员创建出库单数量填5点击保存页面显示“保存成功”但回到服装列表该款衣服库存仍是10未扣减为5。原因分析这是最隐蔽的Bug之一根源在于OutboundItem模型的amount字段计算逻辑。原始代码中amount是quantity × price但price字段在OutboundItem中是冗余存储如果入库时价格变了出库单的price却没同步更新就会导致amount不准进而影响财务统计。但更致命的是我们的库存扣减逻辑写在了OutboundOrder的save()方法里而Django Admin默认不调用模型的save()而是直接执行SQL INSERT。排查步骤1. 在jxc/models.py中找到OutboundOrder模型确认库存扣减逻辑是否在save()方法内2. 查看jxc/admin.py确认OutboundOrderAdmin是否重写了save_model()方法3. 正确做法是将库存扣减逻辑移出save()放到视图层如OutboundOrderCreateView.form_valid()并在Admin中重写save_model()调用同一逻辑。终极解决在jxc/admin.py中添加from django.contrib import admin from .models import OutboundOrder from .views import process_outbound_order # 引入视图中的扣减函数 admin.register(OutboundOrder) class OutboundOrderAdmin(admin.ModelAdmin): def save_model(self, request, obj, form, change): super().save_model(request, obj, form, change) if not change: # 仅对新建单据执行扣减 process_outbound_order(obj) # 调用统一扣减函数5.4 问题客户列表页加载极慢滚动卡顿现象进入/customer/页面浏览器转圈10秒以上F12看Networkcustomer_list.json请求耗时8秒。原因分析customer应用的CustomerListView使用了ListView通用视图但未做查询优化。默认queryset Customer.objects.all()会加载所有客户及其关联的订单、地址等形成N1查询。当客户数超200时数据库压力陡增。排查步骤1. 在customer/views.py中找到CustomerListView2. 查看get_queryset()方法确认是否用了select_related()或prefetch_related()3. 使用Django Debug Toolbar已集成在项目中查看SQL查询次数。终极解决修改get_queryset()def get_queryset(self): return Customer.objects.prefetch_related( outboundorder_set__outbounditem_set__clothes ).all()这一行代码将原本可能上百次的查询压缩为3次客户主表、订单表、明细表实测200客户列表加载时间从8秒降至0.6秒。5.5 问题MySQL迁移后中文显示为“???”乱码现象切换MySQL后服装名称、客户姓名变成问号如“复古牛仔外套”显示为“????????”。原因分析MySQL数据库、表、字段的字符集不一致。jxc_db.sql脚本虽指定了utf8mb4但MySQL服务器默认字符集可能是latin1导致导入时编码转换失败。排查步骤1. 在phpMyAdmin的SQL页执行SHOW VARIABLES LIKE character_set%;查看character_set_server值2. 执行SHOW CREATE DATABASE jxc_db;确认数据库字符集3. 执行SHOW CREATE TABLE customer_customer;确认表字符集。终极解决- 修改MySQL配置文件my.iniWindows或my.cnfLinux在[mysqld]段添加ini character-set-server utf8mb4 collation-server utf8mb4_unicode_ci- 重启MySQL服务- 重新执行jxc_db.sql脚本。5.6 问题操作员注册后收不到欢迎邮件现象用户在/user/register/填写信息点击注册页面跳转到“注册成功”但邮箱没收到任何邮件。原因分析Django邮件功能需要SMTP服务器配置。默认配置指向本地localhost:25但现代操作系统基本不开启此服务。排查步骤1. 检查settings.py中EMAIL_BACKEND是否为django.core.mail.backends.smtp.EmailBackend2. 检查EMAIL_HOST,EMAIL_PORT,EMAIL_HOST_USER,EMAIL_HOST_PASSWORD是否正确配置3. 在PyCharm Terminal中进入Django shell测试pythonpython manage.py shellfrom django.core.mail import send_mailsend_mail(‘测试’, ‘这是一封测试邮件’, ‘fromexample.com’, [‘toexample.com’])终极解决推荐使用QQ邮箱SMTP免费、稳定- 开通QQ邮箱的POP3/SMTP服务设置 → 账户 → “POP3/IMAP/SMTP/Exchange/CardDAV/CalDAV服务” → 开启SMTP- 获取授权码非邮箱密码- 在settings.py中配置python EMAIL_BACKEND django.core.mail.backends.smtp.EmailBackend EMAIL_HOST smtp.qq.com EMAIL_PORT 587 EMAIL_USE_TLS True EMAIL_HOST_USER your_qqqq.com EMAIL_HOST_PASSWORD your_authorization_code # 不是邮箱密码最后分享一个小技巧所有邮件模板templates/registration/email/welcome.txt都采用纯文本格式避免HTML邮件被Gmail等服务商过滤。我们测试过纯文本邮件到达率100%而带链接的HTML邮件有15%概率进垃圾箱。对店主而言能收到比好看重要一万倍。本文还有配套的精品资源点击获取简介专为小型服装店设计的Django进销存管理系统开箱即用PyCharm可直接运行支持Python 3.7 Django 2.2。默认使用SQLite附带MySQL迁移脚本jxc_db.sql和详细配置说明一键切换数据库。系统分操作员和管理员两类角色操作员能注册登录维护客户资料、录入服装信息、创建入库单和出库单每张单据支持添加多款服装明细提交时自动校验库存——出库数量超过当前余量会实时弹出‘库存不足’提示辅助及时补货管理员账号manage/123456拥有全部数据管理权限包括客户档案、服装资料、所有出入库记录及操作员账户的增删改查。项目结构规范含完整templates页面模板、static静态资源、utils通用工具模块以及customer客户、clothes服装、jxc进销存等业务应用还提供requirements.txt依赖清单和README.md部署指南适合教学演示、个体服装店快速上线或基于现有功能做定制开发。本文还有配套的精品资源点击获取
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
