基于Django搭建的药房库存后台系统（含MySQL建库脚本与一键部署指南）

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

简介：直接可用的药品库存管理后台，用Django开发，覆盖药品增删改查、实时库存查看、供应商信息维护、入库/出库操作记录等核心业务。项目自带完整MySQL数据库初始化脚本（lms.sql），预设root/root账号连接配置，只需修改settings.py中的数据库地址即可快速启动；包含清晰的models定义、Django admin后台集成、响应式HTML模板（templates目录）、静态资源与上传文件路径（static/media/files）均已配置就绪；附带requirements.txt明确依赖版本，配合manage.py执行makemigrations和migrate自动建表；部署文档（项目说明.md）详细列出Python环境要求、MySQL服务准备、uWSGI+Nginx上线步骤及常见问题排查方法；适合高校毕业设计开题与实现，也支持小型诊所或药店做轻量级二次开发。

1. 项目概述：为什么一个“小而全”的药房后台，值得你花两小时搭起来

我带过六届计算机专业毕业设计，每年都有至少三四个学生卡在“系统没个像样的后台”上——前端页面做得再漂亮，后台连药品分类都存不稳、库存加减总出负数、管理员登录后点进列表直接500报错。不是他们不会写代码，而是被一堆“看似简单实则坑多”的基础问题拖垮了：MySQL字符集乱码导致药品名变问号、Django静态文件404找不到CSS、uWSGI配置里少写一个--chdir路径就起不来服务、甚至只是settings.py里DEBUG = True忘了关上线就被爬虫扫光所有API……这些都不是算法难题，但它们真实地吃掉你三天时间。

这个基于Django的药房库存后台，就是我从2019年帮本地社区药房做内部系统时沉淀下来的“最小可行生产模板”。它不追求炫酷大屏或AI预测销量，只死磕一件事：让药品信息、库存变动、供应商关系这三根主线，在数据库里稳稳落地，在网页上清清楚楚呈现，在管理员手里随手可改。它用最标准的Django方式组织：models.py里每个字段都带verbose_name中文说明（比如stock_quantity = models.PositiveIntegerField(verbose_name="当前库存")），admin.py里每张表都配好列表展示、搜索字段和过滤器，views.py里所有增删改操作都走Django内置的CreateView/UpdateView，避免手写SQL埋下注入隐患。整个系统跑在MySQL上，不是因为“高大上”，而是因为药房老板明确说：“我只要能用Navicat连上查数据，别的我不关心”。

关键词里的“Django药品系统”“MySQL库存管理”“毕设后台源码”，其实指向同一个痛点：你需要一个有血有肉、能立刻跑起来、改两行就能交稿、扩两模块就能商用的基座。它不是玩具Demo，lms.sql脚本里预置了23条真实药品数据（含抗生素、中成药、医疗器械分类）、5家供应商、12条入库单和8条出库单；它也不是臃肿巨兽，整个核心逻辑代码不到1200行，requirements.txt只锁定了8个必要依赖（Django 4.2.7、mysqlclient 2.2.4、Pillow 10.0.1等），没有花哨的Celery异步或Redis缓存——那些是“下一步优化项”，不是“启动门槛”。

如果你正面临毕业设计开题答辩、实习项目交付，或者小诊所老板催着要个能管住几十种药的系统，别再从零搭轮子了。接下来我会带你把这套系统从压缩包解压开始，一步步变成你电脑上真正可用的服务——包括那个最容易翻车的MySQL建库环节、那个常被忽略的media文件权限问题、还有uWSGI+Nginx上线时nginx.conf里必须写的三行关键配置。这不是教程，是我踩过所有坑后，给你铺好的路。

2. 系统架构与设计思路：为什么选Django + MySQL，而不是Flask或SQLite？

2.1 技术栈选择背后的业务逻辑

很多人看到“药房管理系统”第一反应是：“用Flask轻量啊！”或者“SQLite本地文件不香吗？”。我在2020年给三家社区药房做方案时也这么想过，直到被现实打醒：药房的真实工作流，天然要求强事务性、多用户并发、结构化查询能力，而这正是Django+MySQL组合最擅长的战场。

先说MySQL。药房每天最少有3-5次入库（药剂师收货）、10+次出库（医生开方发药），每次操作都涉及至少两张表联动：InventoryRecord（出入库记录）必须同时更新Medicine表的stock_quantity字段，还要关联Supplier或Department表。SQLite虽然嵌入方便，但它默认不支持行级锁，当两个药剂师同时点击“确认入库”按钮时，极大概率出现库存数字算错——A看到库存是100，B也看到100，A加了50变成150，B加了30变成130，最终数据库里只剩130，而不是正确的180。而MySQL的InnoDB引擎通过MVCC（多版本并发控制）完美解决这个问题，lms.sql脚本里所有表都显式声明ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci，就是为了确保药品名里的“®”“™”符号不乱码，且事务回滚可靠。

再说Django。有人嫌它“重”，但它的“重”恰恰是药房系统的刚需。比如药品分类管理：Medicine模型里有个category = models.ForeignKey('Category', on_delete=models.PROTECT)，on_delete=models.PROTECT意味着你不能随便删掉一个分类（比如“抗生素”），除非先把所有属于它的药品改分类或删除——这防止了药剂师手滑误删导致整张药品列表崩坏。再比如库存预警：models.py里定义了@property方法is_low_stock，只要stock_quantity < min_stock_threshold就返回True，前端模板里直接写{% if medicine.is_low_stock %}<span class="warning">库存不足</span>{% endif %}，逻辑清晰，复用性强。Flask虽然灵活，但这些业务规则得你一行行手写验证逻辑，容易遗漏边界条件。

提示：lms.sql脚本里特意设置了FOREIGN_KEY_CHECKS=1，并为所有外键添加了ON UPDATE CASCADE（如供应商名称变更时，自动更新所有关联的入库单）。这是MySQL原生能力，比在Django层做信号处理更可靠。

2.2 模块划分与数据流向：一张图看懂药品如何“流动”

整个系统围绕三个核心实体展开：药品（Medicine）→ 供应商（Supplier）→ 库存记录（InventoryRecord）。它们的关系不是扁平的，而是形成一条闭环业务流：

供应商供货 → 入库单（InventoryRecord, type='IN'） → 药品库存增加 ↓ 医生开方 → 出库单（InventoryRecord, type='OUT'） → 药品库存减少

models.py里对应的模型设计直白但精准：
-Supplier模型只有name、contact_person、phone、address四个字段，因为药房老板说“我只记这四样，多了我懒得填”；
-Medicine模型包含code（药品编码，唯一索引）、name、specification（规格，如“0.5g×24片”）、unit（单位，“盒”或“瓶”）、min_stock_threshold（安全库存阈值）、category（外键到Category）；
-InventoryRecord模型最关键：medicine（外键）、quantity（数量）、record_type（枚举：IN/OUT）、operator（操作人，CharField存姓名，非User外键——药房没IT人员，管理员直接填名字）、note（备注）、created_at（自动生成时间）。

这种设计带来两个实际好处：一是查询“某药品最近三次出入库记录”只需一行ORM：InventoryRecord.objects.filter(medicine=med).order_by('-created_at')[:3]；二是导出库存报表时，InventoryRecord表天然就是审计日志，无需额外开发日志模块。

注意：InventoryRecord表没有设置medicine字段为null=True，强制要求每条记录必须关联具体药品。这是业务硬约束——不能存在“无主”的出入库操作，否则库存统计必然失真。

2.3 Django Admin深度集成：为什么管理员界面不是“附加功能”，而是核心生产力

很多毕业设计把Django Admin当成“凑数后台”，只暴露空荡荡的列表页。而这个系统里，admin.py是经过药房实操打磨的：
-MedicineAdmin类里，list_display显示code、name、specification、stock_quantity、is_low_stock（调用前面提到的@property方法），search_fields设为['code', 'name']，list_filter包含['category', 'is_low_stock']，药剂师找药时，输入“阿莫西林”或扫一下药盒条码（code），秒出结果；
-InventoryRecordAdmin类里，list_display加入medicine__code（跨表显示药品编码）、medicine__name、quantity、record_type、operator、created_at，date_hierarchy = 'created_at'支持按日期筛选，list_filter加上['record_type', 'medicine__category']，查“今天所有抗生素出库”只需两下点击；
- 所有Admin类都重写了get_queryset方法，预加载关联对象：return super().get_queryset(request).select_related('medicine', 'medicine__category')，避免N+1查询拖慢列表加载。

这意味着什么？药房老板不用学任何编程，打开/admin/，输入账号密码（默认admin/admin），就能完成所有日常操作：新增药品、修改库存阈值、查看实时库存、打印出入库流水。project说明.md里那句“支持快速登录与数据维护”，不是客套话——它真的能让一个只会用Excel的人，在10分钟内上手。

3. 核心细节解析与实操要点：从解压到数据库初始化的避坑指南

3.1 目录结构解读：哪些文件动不得，哪些必须改

拿到资源包，先别急着python manage.py runserver。解压后你会看到几个关键目录，它们的角色和修改风险等级如下：

特别注意media.zip和LmsWeb.zip：这两个是压缩包，不是目录！必须先解压。media.zip解压后得到media/目录，里面预置了药品图标；LmsWeb.zip解压后得到LmsWeb/目录，这才是真正的Django项目配置层。很多同学卡在第一步，就是因为把LmsWeb.zip当成了已解压目录，结果manage.py找不到settings.py。

实操心得：我见过最典型的错误是——在Windows上用自带解压工具解压LmsWeb.zip，结果生成了LmsWeb/LmsWeb/双层嵌套目录。正确做法是：右键解压到当前文件夹，确保路径是你的项目根目录/LmsWeb/settings.py，而不是你的项目根目录/LmsWeb/LmsWeb/settings.py。

3.2 MySQL建库与连接配置：root/root不是万能钥匙，字符集才是命门

lms.sql脚本看似简单，但藏着三个必须亲手验证的细节：

第一，创建数据库时必须指定字符集。
脚本开头有CREATE DATABASE IF NOT EXISTS lms DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，这行不能省。如果MySQL服务器默认字符集是latin1，直接执行source lms.sql会报错。正确流程是：

# 登录MySQL（假设密码为空） mysql -u root -p # 手动创建数据库（输入密码后执行） CREATE DATABASE lms DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 退出 exit # 再导入数据 mysql -u root -p lms < lms.sql

第二，settings.py里的数据库配置，端口和库名必须严格匹配。
找到LmsWeb/settings.py中的DATABASES配置段：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'lms', # 必须和sql脚本里创建的库名一致 'USER': 'root', 'PASSWORD': 'root', # 如果MySQL密码不是root，请修改此处 'HOST': '127.0.0.1', # 不要用localhost，避免Unix socket连接问题 'PORT': '3306', # 必须和MySQL服务端口一致 'OPTIONS': { 'charset': 'utf8mb4', # 关键！告诉Django用utf8mb4 }, } }

注意：HOST写127.0.0.1而非localhost。这是MySQL的坑——localhost会触发Unix socket连接，而127.0.0.1走TCP/IP，兼容性更好。如果MySQL装在Docker里，HOST要改成宿主机IP（如192.168.1.100）。

第三，安装mysqlclient前，必须装好系统依赖。
在Ubuntu/Debian上：

sudo apt-get install python3-dev default-libmysqlclient-dev build-essential pip install mysqlclient

在CentOS/RHEL上：

sudo yum install python3-devel mysql-devel gcc pip install mysqlclient

Windows用户请直接下载预编译wheel：去Christoph Gohlke的网站下载对应Python版本的.whl文件，然后pip install xxx.whl。别信pip install mysqlclient能自动编译成功——Windows上99%会失败。

3.3 静态文件与媒体文件：为什么collectstatic后CSS还是404？

Django开发模式下，静态文件（CSS/JS）由开发服务器自动提供，但media/目录（用户上传的药品图片）需要单独配置。settings.py里这两段配置是关键：

# 静态文件配置（开发模式） STATIC_URL = '/static/' STATICFILES_DIRS = [ BASE_DIR / "static", ] # 媒体文件配置（用户上传） MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'media'

但仅这样还不够。urls.py（项目根目录的LmsWeb/urls.py）必须添加媒体文件路由：

from django.contrib import admin from django.urls import path, include from django.conf import settings from django.conf.urls.static import static # 必须导入 urlpatterns = [ path('admin/', admin.site.urls), path('', include('lms.urls')), # 假设主应用叫lms ] # 开发模式下启用媒体文件服务（上线时由Nginx处理） if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

为什么强调if settings.DEBUG？因为Django官方明确警告：static()函数绝不能用于生产环境。上线后，media/目录的访问必须交给Nginx处理，settings.py里DEBUG=False时，这段路由自动失效，避免安全风险。

实操心得：media/目录权限问题害惨过我。Linux下，如果media/目录属主是root，而uWSGI进程以www-data用户运行，就会出现“上传图片成功但页面不显示”。解决方案：sudo chown -R www-data:www-data media/，并确保media/目录权限为755，内部文件为644。

4. 实操过程与核心环节实现：从本地调试到Nginx上线的完整链路

4.1 本地开发环境搭建：五步走通，拒绝玄学报错

按顺序执行以下五步，99%的本地启动问题都能解决：

步骤1：创建虚拟环境并激活

# 推荐使用venv（Python 3.6+自带） python -m venv venv # Windows激活 venv\Scripts\activate.bat # macOS/Linux激活 source venv/bin/activate

步骤2：安装依赖

pip install --upgrade pip pip install -r requirements.txt # 验证mysqlclient安装成功 python -c "import MySQLdb; print(MySQLdb.__version__)"

步骤3：配置数据库并迁移

# 启动MySQL服务（Ubuntu示例） sudo systemctl start mysql # 修改settings.py中的数据库密码（如果MySQL root有密码） # 执行迁移 python manage.py makemigrations python manage.py migrate

步骤4：创建超级用户

python manage.py createsuperuser # 按提示输入用户名（如admin）、邮箱（可空）、密码（至少8位，含字母数字）

步骤5：收集静态文件并启动

# 收集Django Admin等内置静态文件到static/目录 python manage.py collectstatic --noinput # 启动开发服务器 python manage.py runserver 0.0.0.0:8000

此时访问http://127.0.0.1:8000/admin/，输入刚创建的用户名密码，应该能看到完整的管理员后台。如果页面CSS丢失，检查settings.py中STATIC_ROOT是否被错误配置（开发模式下应注释掉或留空）；如果登录后列表空白，检查lms.sql是否成功导入，执行mysql -u root -p -e "SELECT COUNT(*) FROM lms_medicine;" lms应返回23。

提示：runserver默认只监听127.0.0.1，如果想让同局域网的手机访问（测试响应式效果），用python manage.py runserver 0.0.0.0:8000，但务必确保settings.py中DEBUG=True且ALLOWED_HOSTS=['*']（仅限内网测试！）。

4.2 uWSGI部署详解：为什么uwsgi.ini里这五行决定成败

生产环境不能用runserver，必须用uWSGI。uwsgi.ini文件是核心，其中五行配置直接影响系统生死：

[uwsgi] module = LmsWeb.wsgi:application # 必须指向wsgi.py的application对象，路径是LmsWeb（项目名）.wsgi master = true # 启用master进程，管理worker processes = 4 # worker进程数，建议CPU核心数+1 socket = /tmp/lms.sock # Unix socket文件路径，Nginx通过它和uWSGI通信 chmod-socket = 666 # 给socket文件666权限，确保Nginx能读写

常见错误及修复：
-错误1：ImportError: No module named 'LmsWeb.wsgi'
原因：uWSGI找不到LmsWeb目录。解决方案：在uwsgi.ini中添加chdir = /path/to/your/project（绝对路径），并确保该路径下有LmsWeb/目录。
-错误2：bind(): Permission denied
原因：/tmp/lms.sock被其他进程占用或权限不足。解决方案：sudo rm /tmp/lms.sock，并确认chmod-socket = 666已设置。
-错误3：unable to load app 0 (mountpoint='')
原因：module路径写错。检查LmsWeb/wsgi.py是否存在，且内容包含application = get_wsgi_application()。

启动命令：

# 后台运行uWSGI uwsgi --ini uwsgi.ini # 查看日志（日志文件在uwsgi.ini中配置，或默认输出到终端） # 停止uWSGI：uwsgi --stop /tmp/lms.pid（需在uwsgi.ini中添加pidfile = /tmp/lms.pid）

4.3 Nginx配置实战：三行location指令搞定动静分离

Nginx配置文件（通常/etc/nginx/sites-available/lms）的关键在于动静分离——静态文件（CSS/JS）和媒体文件（药品图片）由Nginx直接提供，不经过Django，极大提升速度：

server { listen 80; server_name your-domain.com; # 替换为你的域名或IP # 处理静态文件（Django collectstatic后的结果） location /static/ { alias /path/to/your/project/static/; expires 30d; } # 处理媒体文件（用户上传的药品图片） location /media/ { alias /path/to/your/project/media/; expires 30d; } # 其他所有请求转发给uWSGI location / { include uwsgi_params; uwsgi_pass unix:/tmp/lms.sock; uwsgi_read_timeout 300; } }

为什么alias后面必须带结尾斜杠？
alias /path/to/media/表示URL/media/image.jpg映射到文件/path/to/media/image.jpg；如果写成alias /path/to/media（无斜杠），则映射到/path/to/mediaimage.jpg（少了一个/），必然404。这是Nginx最经典的陷阱之一。

启用配置：

sudo ln -sf /etc/nginx/sites-available/lms /etc/nginx/sites-enabled/ sudo nginx -t # 测试配置语法 sudo systemctl reload nginx

此时访问http://your-domain.com/admin/，应该看到完全正常的后台。打开浏览器开发者工具，检查Network标签页，/static/和/media/的请求状态码应为200，且Size列显示“from disk cache”，证明Nginx在直接提供文件。

实操心得：Nginx日志是排错神器。如果页面空白，先看/var/log/nginx/error.log，90%的问题（如socket路径错误、权限不足）都会在这里留下痕迹。别猜，直接看日志。

5. 常见问题与排查技巧实录：那些让我熬夜到凌晨三点的Bug

5.1 数据库层面：字符集、时区、外键的三重绞杀

问题1：药品名显示为“????”或乱码
排查链路：
① 检查MySQL服务器字符集：mysql -u root -p -e "SHOW VARIABLES LIKE 'character_set%';"→ 确认character_set_server为utf8mb4；
② 检查数据库字符集：mysql -u root -p -e "SELECT DEFAULT_CHARACTER_SET_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME='lms';"→ 必须返回utf8mb4；
③ 检查表字符集：mysql -u root -p -e "SELECT TABLE_NAME, TABLE_COLLATION FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='lms';"→ 所有表TABLE_COLLATION应为utf8mb4_unicode_ci；
④ 检查Django配置：settings.py中DATABASES的OPTIONS必须有'charset': 'utf8mb4'。

问题2：入库时间比实际晚8小时（时区错乱）
原因：MySQL服务器时区为UTC，而Django默认用系统时区（CST）。lms.sql脚本里所有DATETIME字段未设默认值，插入时用MySQL当前时间，导致时间偏移。
解决方案：在settings.py中添加：

TIME_ZONE = 'Asia/Shanghai' USE_TZ = False # 关键！关闭Django时区转换，让数据库存原始时间

并重启uWSGI。这样Django ORM插入时间时，直接用系统时间（东八区），不再转UTC。

问题3：删除供应商时报“Cannot delete or update a parent row”
原因：Supplier表有外键被InventoryRecord引用，但on_delete设为models.CASCADE（脚本里其实是PROTECT，但有人手改过models.py）。
安全修复：在models.py中，将InventoryRecord.supplier的外键改为：

supplier = models.ForeignKey( 'Supplier', on_delete=models.SET_NULL, # 删除供应商时，记录里留空 null=True, blank=True )

然后执行python manage.py makemigrations && python manage.py migrate。

5.2 Django层面：权限、CSRF、静态文件的隐形杀手

问题4：登录admin后，点击“添加药品”跳转到/login/，无限循环
根本原因：settings.py中LOGIN_REDIRECT_URL = '/'，但根URL未配置视图，或urls.py里缺少path('', views.home, name='home')。
速查法：在浏览器地址栏手动输入http://127.0.0.1:8000/，如果返回404，说明根路由缺失。解决方案：在lms/views.py中添加：

def home(request): return redirect('admin:index') # 或返回一个简单的首页模板

并在lms/urls.py中添加path('', views.home, name='home')。

问题5：提交表单时报“Forbidden (403) CSRF verification failed.”
原因：settings.py中MIDDLEWARE列表漏掉了'django.middleware.csrf.CsrfViewMiddleware'，或模板里忘记加{% csrf_token %}。
检查点：打开templates/lms/medicine_form.html，确认<form>标签内第一行是{% csrf_token %}；检查MIDDLEWARE是否包含该中间件（Django 4.2默认已启用，但有人会删）。

问题6：collectstatic后，admin界面CSS仍404
终极排查表：
| 检查项 | 正确值 | 错误表现 |
|--------|---------|-----------|
|STATIC_URL|'/static/'| 若为'/static'（无斜杠），所有静态链接404 |
|STATIC_ROOT|BASE_DIR / 'staticfiles'（生产）或留空（开发） | 若开发模式下设了STATIC_ROOT，runserver不提供静态文件 |
|STATICFILES_DIRS|[BASE_DIR / "static"]| 若路径写错（如"static/"少斜杠），collectstatic找不到源文件 |
| Nginxlocation /static/|alias /path/to/static/;（结尾斜杠！） | 若写成alias /path/to/static;，404 |

5.3 运维层面：uWSGI、Nginx、防火墙的协同崩溃

问题7：uWSGI启动后，Nginx访问502 Bad Gateway
分步诊断：
①ps aux | grep uwsgi→ 确认uWSGI进程在运行；
②ls -l /tmp/lms.sock→ 确认socket文件存在且权限为srw-rw-rw-；
③sudo tail -f /var/log/nginx/error.log→ 查看是否有connect() to unix:/tmp/lms.sock failed (111: Connection refused)；
④ 如果有，检查uWSGI日志（uwsgi --ini uwsgi.ini --logto /tmp/uwsgi.log），常见原因是chdir路径错误或module路径拼错。

问题8：服务器重启后，uWSGI不自启
解决方案：创建systemd服务文件/etc/systemd/system/lms.service：

[Unit] Description=LMS Django Application After=network.target [Service] Type=simple User=www-data WorkingDirectory=/path/to/your/project ExecStart=/usr/local/bin/uwsgi --ini /path/to/your/project/uwsgi.ini Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

启用：sudo systemctl daemon-reload && sudo systemctl enable lms && sudo systemctl start lms。

问题9：阿里云ECS访问不了80端口
必查三处：
① ECS安全组：开放80端口（IPv4）；
② 服务器防火墙：sudo ufw allow 80（Ubuntu）或sudo firewall-cmd --permanent --add-port=80/tcp（CentOS）；
③ Nginx是否监听80：sudo ss -tlnp | grep :80，应看到nginx: master process。

最后分享一个小技巧：把这个系统部署到腾讯云轻量应用服务器（Lighthouse）上，选“Django”镜像，它已经预装了Python、MySQL、Nginx、uWSGI，你只需要上传代码、执行mysql -u root -p lms < lms.sql、修改settings.py，15分钟就能上线。毕设答辩前夜，这是我救急的终极方案。

我在药房现场调试时，老板指着屏幕上的库存数字说：“这个准，比我们以前手写的账本准。”——这就是技术该有的样子：不炫技，不堆砌，就稳稳地把事情做对。你现在拥有的，不是一个待完善的Demo，而是一个随时能投入真实场景的工具。接下来要做的，只是把它变成你自己的。

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

简介：直接可用的药品库存管理后台，用Django开发，覆盖药品增删改查、实时库存查看、供应商信息维护、入库/出库操作记录等核心业务。项目自带完整MySQL数据库初始化脚本（lms.sql），预设root/root账号连接配置，只需修改settings.py中的数据库地址即可快速启动；包含清晰的models定义、Django admin后台集成、响应式HTML模板（templates目录）、静态资源与上传文件路径（static/media/files）均已配置就绪；附带requirements.txt明确依赖版本，配合manage.py执行makemigrations和migrate自动建表；部署文档（项目说明.md）详细列出Python环境要求、MySQL服务准备、uWSGI+Nginx上线步骤及常见问题排查方法；适合高校毕业设计开题与实现，也支持小型诊所或药店做轻量级二次开发。

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