简介一套基于Python开发的图书馆管理系统毕业设计完整资源面向计算机专业毕业生、需要完成课程设计或毕设项目的学生也适合希望快速上手Django框架与MySQL数据库的开发者参考。系统涵盖图书信息、借阅、归还、罚款等核心模块采用面向对象设计并配有说明文档便于理解架构和二次开发。资源包共783个文件约19.21MB主要包括45个Python源码文件含模型、视图、控制器、53个Vue页面组件、164个JavaScript脚本以及CSS样式、HTML页面、SQL数据库脚本等另有安装运行批处理和说明文档结构清晰可直接部署或改造。目前已有186人学习下载适合用于毕设答辩、项目实战练习或作为图书馆信息化管理系统的开发蓝本能够有效缩短开发周期并降低起步难度。1. 图书馆管理系统一个能讲清楚前后端完整链路的 Python 毕设项目对正在做毕设的人来说最怕的不是写不出代码而是答辩时讲不清楚“这个系统的数据是怎么流动的”。这套基于 Python 的图书馆管理系统从文件名就能看出它的工程形态——有 Vue 前端组件、有 Django 风格的后端逻辑、有论文文档还带构建和启动脚本。它不是一个只跑在控制台的教学 Demo而是一套前后端分离的完整系统图书信息管理、借阅、归还、罚款统计、读者管理都在里面。适合两类人一是需要一份能跑通、能讲深、能被追问的毕设源码二是想找一个“看得见完整链路”的 Django 实战项目用来学 MVC 架构和前后端联调。2. 架构与目录拆解Django 后端加 Vue 前端的双工程布局2.1 技术选型为什么是 Django 加 MySQL而不是 Flask 加 SQLite这个系统后端选择了 Django前端是 Vue 组件加构建脚本的组合。Django 在这个场景里几乎是“标配”选择它自带 ORM 和 Admin 后台模型定义好之后数据库表结构可以自动迁移生成图书、读者、借阅记录这类实体关系的建模成本很低。相比之下 Flask 更轻但 ORM、表单校验、权限这些都要自己拼对毕设来说工作量会上去。数据层用的 MySQL这一点也很典型。图书馆系统有明确的实体关系——一本书可以被多次借阅、一个读者有多条借阅记录、一次归还可能产生罚款MySQL 这种关系型数据库在处理这类业务上比 NoSQL 顺手得多。而且 Django 的 ORM 对 MySQL 的兼容性非常成熟只需要装mysqlclient或pymysql驱动改一下settings.py里的数据库配置就能接上。前端的选型从文件名可以看出来IndexMain.vue、IndexAsideStatic.vue、BreadCrumbs.vue、IndexHeader.vue这套命名风格是典型的 Vue 2 Element UI 后台管理布局——左侧静态菜单、顶部面包屑导航、主内容区域切换。这类结构在管理系统中非常普遍组件拆分也符合“一个页面一个组件”的维护习惯。2.2 目录结构全览从 .bak 备份文件反推项目组织方式这套资源里有一批.bak后缀的文件比如update-password.vue.bak、IndexMain.vue.bak。.bak通常是开发者在改版前手动复制的备份说明在原工程里这些组件是“有效文件”.bak只是历史版本存档。我一般拿到这类资源会先建立一套还原后的目录预期再对照实际内容往里填library_system/ ├── backend/ # Django 后端工程 │ ├── manage.py │ ├── requirements.txt # 依赖清单 │ ├── library/ # 项目配置目录 │ │ ├── settings.py # 数据库、DRF、跨域配置 │ │ ├── urls.py # 根路由 │ │ └── wsgi.py │ └── bookapp/ # 业务应用 │ ├── models.py # 图书、读者、借阅、罚款模型 │ ├── views.py # 借阅/归还/罚款的视图函数 │ ├── serializers.py # DRF 序列化器 │ └── urls.py # 业务路由 ├── frontend/ # Vue 前端工程 │ ├── src/ │ │ ├── views/ # IndexMain.vue 等页面组件 │ │ ├── components/ # IndexHeader.vue 等布局组件 │ │ ├── api/ # axios 请求封装 │ │ └── router/ # 前端路由 │ ├── package.json │ └── vue.config.js # 代理配置 ├── scripts/ │ ├── 安装.bat │ ├── 运行.bat │ ├── 2-run.bat │ └── 3-build.bat ├── docs/ # 论文和说明文档 └── database/ └── library.sql # 初始化 SQL 脚本2.3 数据库模型设计五张表撑起的核心业务图书管理、读者管理、借阅归还、罚款管理这几个功能落到数据库层面其实很清晰。常见做法是设计这样一组模型# bookapp/models.py from django.db import models class Book(models.Model): 图书信息表 isbn models.CharField(max_length20, uniqueTrue, verbose_nameISBN) title models.CharField(max_length200, verbose_name书名) author models.CharField(max_length100, verbose_name作者) publisher models.CharField(max_length100, verbose_name出版社) publish_date models.DateField(verbose_name出版日期) category models.ForeignKey(Category, on_deletemodels.SET_NULL, nullTrue) total_stock models.IntegerField(default1, verbose_name馆藏总量) available_stock models.IntegerField(default1, verbose_name可借数量) location models.CharField(max_length50, verbose_name馆藏位置) class Reader(models.Model): 读者信息表 reader_id models.CharField(max_length20, uniqueTrue, verbose_name读者证号) name models.CharField(max_length50, verbose_name姓名) id_card models.CharField(max_length18, verbose_name身份证号) phone models.CharField(max_length11, verbose_name手机号) register_date models.DateField(auto_now_addTrue, verbose_name注册日期) status models.BooleanField(defaultTrue, verbose_name是否有效) class BorrowRecord(models.Model): 借阅记录表 book models.ForeignKey(Book, on_deletemodels.CASCADE, verbose_name图书) reader models.ForeignKey(Reader, on_deletemodels.CASCADE, verbose_name读者) borrow_date models.DateTimeField(auto_now_addTrue, verbose_name借出时间) due_date models.DateTimeField(verbose_name应还时间) return_date models.DateTimeField(nullTrue, blankTrue, verbose_name实际归还时间) status models.CharField(max_length10, defaultborrowed, choices[(borrowed, 借出中), (returned, 已归还)])BorrowRecord是整个系统里最关键的一张表。它用borrow_date加due_date记录借期return_date判断有没有逾期逾期天数由due_date和return_date的差计算出来罚款金额再根据逾期天数乘以单价得出。图书的available_stock是借还操作时要同步维护的字段——借出减一归还加一。这种设计把“库存扣减”和“记录流水”拆在两个层面逻辑上更稳翻车概率比直接在图书表上记状态小很多。3. 核心模块实现借阅、归还、罚款的代码走读3.1 借阅接口从请求进入到业务校验的完整路径借阅是图书馆系统最高频的操作。前端调用/api/borrow/接口传入book_id和reader_id后端要做三件事验读者状态、验库存余量、创建借阅记录并扣减库存。核心视图代码大致长这样# bookapp/views.py from django.utils import timezone from datetime import timedelta from django.http import JsonResponse import json from .models import Book, Reader, BorrowRecord MAX_BORROW_COUNT 5 # 单读者最大在借数量 BORROW_DAYS 30 # 默认借期天数 def borrow_book(request): if request.method ! POST: return JsonResponse({code: 405, msg: 仅支持 POST 请求}, status405) data json.loads(request.body) book_id data.get(book_id) reader_id data.get(reader_id) # 1. 读者校验 reader Reader.objects.filter(reader_idreader_id, statusTrue).first() if not reader: return JsonResponse({code: 4001, msg: 读者不存在或已被停用}) # 2. 数量校验防止在借量超过上限 active_count BorrowRecord.objects.filter( readerreader, statusborrowed ).count() if active_count MAX_BORROW_COUNT: return JsonResponse({code: 4002, msg: f借阅数量已达上限 {MAX_BORROW_COUNT} 本}) # 3. 库存校验 book Book.objects.filter(idbook_id).first() if not book or book.available_stock 0: return JsonResponse({code: 4003, msg: 图书不存在或已全部借出}) # 4. 创建借阅记录并扣减库存 due_date timezone.now() timedelta(daysBORROW_DAYS) record BorrowRecord.objects.create( bookbook, readerreader, due_datedue_date ) book.available_stock - 1 book.save() return JsonResponse({code: 0, msg: 借阅成功, data: { record_id: record.id, due_date: due_date.strftime(%Y-%m-%d) }})这段逻辑里几个参数值是按实际业务定的。MAX_BORROW_COUNT 5表示单读者最多同时在借 5 本如果你所在学校的规则是一人 10 本直接改这个常量即可。BORROW_DAYS 30是默认借期timedelta(days30)计算出应还时间然后存库。代码把业务校验分成四步每步返回独立错误码前端可以按错误码给用户展示不同的提示文案这也是我习惯了的一种接口设计方式——错误码比笼统的 “error” 好排查得多。这里有个值得一提的设计细节借阅记录创建用BorrowRecord.objects.create()库存扣减放在之后。理论上这两步应该放在一个数据库事务里但作为教学项目先拆开写会更直观。我拿到代码后会建议你自己加一层transaction.atomic()包裹防止创建记录成功但扣库存失败的数据不一致问题。3.2 归还与罚款计算逾期天数的统计口径归还逻辑比借阅多一步判断是否逾期逾期了就同时生成一条罚款记录。罚款计算看似简单但“按自然日还是按工作日算”“当天归还算不算逾期”这些细节是很多系统里扯皮最多的地方。# bookapp/views.py from .models import BorrowRecord, FineRecord DAILY_FINE 0.5 # 每天罚款 0.5 元 def return_book(request): if request.method ! POST: return JsonResponse({code: 405, msg: 仅支持 POST 请求}, status405) data json.loads(request.body) record_id data.get(record_id) record BorrowRecord.objects.filter(idrecord_id, statusborrowed).first() if not record: return JsonResponse({code: 4004, msg: 借阅记录不存在或已归还}) # 1. 标记归还 now timezone.now() record.return_date now record.status returned record.save() # 2. 恢复库存 book record.book book.available_stock 1 book.save() # 3. 计算逾期天数 due record.due_date overdue_days 0 if now due: # 跨天计算只要超过应还时刻就算逾期 1 天 overdue_days (now - due).days or 1 # 4. 生成罚款记录 fine_amount round(overdue_days * DAILY_FINE, 2) if fine_amount 0: FineRecord.objects.create( recordrecord, readerrecord.reader, amountfine_amount, statusunpaid, reasonf逾期 {overdue_days} 天 ) return JsonResponse({code: 0, msg: 归还成功, data: { overdue_days: overdue_days, fine: fine_amount }})罚款计算的核心是(now - due).days这个表达式。Python 的timedelta.days是向下取整的比如超时 1 小时得到days 0所以用了or 1把不足一天但确实逾期的场景兜住。DAILY_FINE 0.5是每本每日罚款单价同样是一个可以配置化的常量——在第六章我会讲怎么把它改成数据库可配置。归还接口的返回值把overdue_days和fine分开返回前端可以在归还结果弹窗里直接展示“逾期 3 天罚款 1.5 元”。这一步对用户体验很重要系统要让人知道罚款不是凭空产生的。3.3 罚款记录查询与管理管理端不看明细就是黑匣子罚款功能如果只有“生成”没有“查询”对管理员来说就是一个黑匣子。系统的罚款管理模块一般包含三块罚款列表、缴费确认、统计汇总。列表后端用 Django ORM 按时间倒序筛# bookapp/views.py def fine_list(request): reader_id request.GET.get(reader_id, ) status request.GET.get(status, ) fines FineRecord.objects.all() if reader_id: fines fines.filter(reader__reader_idreader_id) if status: fines fines.filter(statusstatus) fines fines.order_by(-created_at) data [{ fine_id: f.id, reader_name: f.reader.name, book_title: f.record.book.title, amount: f.amount, status: f.get_status_display(), reason: f.reason, created_at: f.created_at.strftime(%Y-%m-%d %H:%M) } for f in fines] return JsonResponse({code: 0, data: data})order_by(-created_at)按创建时间倒序新产生的罚款一定排在最前面。get_status_display()是 Django ChoiceField 自带的取中文展示值的方法unpaid会显示为“未缴费”。管理员的“确认缴费”操作就是把这个状态字段改成paid在真实系统里还可以加上操作管理员 ID 和缴费时间方便后续对账。4. 运行部署指南从安装依赖到浏览器打开全流程4.1 环境准备Python、MySQL、Node 三件套最稳妥的跑通姿势是准备这三样Python 3.8 及以上、MySQL 5.7 或 8.0、Node.js 14 以上。系统的.bat脚本已经把这套流程写成了安装和启动两个环节但底层依赖还是需要手动准备的。先看后端依赖。这个项目用到的核心包包括Django、djangorestframework、mysqlclient和django-cors-headers按安装脚本的约定执行pip install django djangorestframework mysqlclient django-cors-headers如果在 Windows 上装mysqlclient报错缺 C 编译环境是常态我一般会换成纯 Python 的pymysql然后在manage.py和settings.py里加两行import pymysql pymysql.install_as_MySQLdb()这一步是完美替代方案ORM 层没有感知模型照写不误。4.2 数据库初始化建库、改配置、执行迁移在 MySQL 里建一个名为library_db的数据库注意字符集选utf8mb4。然后打开backend/library/settings.py把数据库连接信息改成你自己的DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: library_db, USER: root, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, } }改完之后执行迁移生成表结构cd backend python manage.py makemigrations python manage.py migrate python manage.py createsuperusercreatesuperuser会创建一个管理员账号用来登录 Django Admin 后台也方便在后台预填一些图书和读者测试数据。如果资源里带了library.sql初始化脚本也可以跳过 migrate 直接导入 SQL 文件效果一样。4.3 前端构建与启动弄明白 2-run 和 3-build 的顺序这套资源的脚本编排是2-run.bat和3-build.bat分开的命名顺序暗示了先安装依赖再构建。实际手动执行是这样cd frontend npm install npm run serve开发模式下 Vue 会跑在localhost:8080它和后端localhost:8000是两个端口联调需要配代理。在vue.config.js里加module.exports { devServer: { proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true } } } };这样前端的/api/...请求会转发到 Django 的接口上避免跨域问题。如果是部署环境用npm run build产出dist静态目录再由 Nginx 统一托管前后端这个项目里3-build.bat对应的就是这一步。4.4 启动顺序与验证清单跑起来之后按下面的路径走一遍基本流程确认核心功能没处漏油用管理账号登录系统确认首页统计数字和图标加载正常。进入图书管理页新增一本测试图书ISBN 不要和其他书重复。进入读者管理新增一个测试读者记录读者证号。在借阅页面输入图书 ID 和读者证号完成借阅确认图书可用库存减一。手动把这本书的应还日期改到昨天在数据库里执行UPDATE或用 Django Admin然后走归还流程确认产生罚款记录。到罚款管理页面查看到这条罚款记录完成缴费状态确认。第六步尤其关键。如果罚款记录没有生成多半是due_date和实际归还时间之间没有跨天或者是在页面里借阅时BORROW_DAYS太长。测试“逾期场景”时直接在库里改due_date是效率最高的做法。5. 常见问题与避坑记录环境、编码、跨域的排查清单5.1 MySQL 连接报错Access denied for user现象启动 Django 后访问接口直接 500日志里出现Access denied for user rootlocalhost。原因数据库用户名密码和settings.py里配置不一致或者 MySQL 只允许localhost登录但配置写成了127.0.0.1的权限没授权。解决先确认 MySQL 里执行SELECT user, host FROM mysql.user;看 root 账号允许的 host 范围然后在settings.py里把 HOST 改成和权限匹配的地址。常见避坑点是 MySQL 8.0 默认认证插件是caching_sha2_passwordpymysql会因此报错解决方式是在 MySQL 里执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 密码;切换认证方式。5.2 前端请求后端报跨域错现象浏览器控制台出现blocked by CORS policy接口能通但浏览器拦截了响应。原因前端跑在8080端口后端在8000端口跨域默认被浏览器拦。如果项目里没有django-cors-headers或未在settings.py里配置白名单就会翻车。解决两步走。安装django-cors-headers后在settings.py的INSTALLED_APPS加corsheadersMIDDLEWARE加corsheaders.middleware.CorsMiddleware然后配置CORS_ALLOWED_ORIGINS [http://localhost:8080]如果你用的是开发代理方案则不需要这个配置vue.config.js里的 proxy 已把跨域问题消化掉了。两者选一个即可不要同时纠结。5.3 中文乱码和无法写入的问题现象图书分类填入“文学类”保存后数据库查出来是乱码。原因MySQL 建库时没有指定字符集默认latin1不支持中文。解决建库语句补充完整字符集定义CREATE DATABASE library_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;如果库已经建好了用ALTER DATABASE library_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;补救。还要确认settings.py里OPTIONS加了charset: utf8mb4。这个坑一翻就是全部接口都中文乱码排查起来很容易抓狂建议拿到项目第一件事就先验字符集。5.4 迁移失败提示某个字段已存在或缺失现象执行python manage.py migrate报错说column ... already exists或者table has no column named ...。原因库里已经有残留的表但和 Django 的迁移记录django_migrations表对不上。常见于资源自带library.sql但手动导入后又跑了 migrate。解决如果库里不要求保留数据直接删库重建再按顺序执行makemigrations和migrate。如果我需要保留已有测试数据会先python manage.py migrate --fake把当前迁移记录标记为已执行再手工比对差异但这种方式踩坑概率高新手建议直接重建库。5.5 Admin 后台能登录但前端登录一直转圈现象Django Admin 登录正常前端首页也能打开但登录按钮点击后一直 loading接口返回 500。原因前端登录调用的接口和 Django 后台登录是两套多半是自定义登录视图里没有处理密码校验或者用户表用了自定义模型导致authenticate()查询报错。解决检查后端日志如果看到RelatedObjectDoesNotExist或用户模型相关报错说明自定义Reader模型和 Django 默认auth.User的关联没搭好。常见做法是在自定义登录视图里直接用Reader表做密码校验不经过 Django 的auth模块这样最省事也不用处理模型关联的坑。6. 二次开发与扩展把罚款规则改造成可配置项做完的基础功能如果只能对上答辩那多少有点可惜。实际开发里最常见的一个改造需求是罚款单价、借阅上限、借期天数这类业务参数不应是代码里写死的常量。拿第五章的DAILY_FINE 0.5和MAX_BORROW_COUNT 5来说它们散落在视图模块里每次改都要动代码、重启服务。把这些值挪到数据库里做一个SystemConfig模型是最直接的管理方法# bookapp/models.py class SystemConfig(models.Model): 系统参数配置表 key models.CharField(max_length50, uniqueTrue, verbose_name配置键) value models.CharField(max_length200, verbose_name配置值) description models.CharField(max_length200, blankTrue, verbose_name说明)然后写一个读取配置的小工具函数替代模块里的常量# bookapp/config.py from .models import SystemConfig def get_config(key, defaultNone): cfg SystemConfig.objects.filter(keykey).first() return cfg.value if cfg else default在借阅和归还视图里把MAX_BORROW_COUNT、BORROW_DAYS、DAILY_FINE替换成动态读取例如MAX_BORROW_COUNT int(get_config(max_borrow_count, 5)) BORROW_DAYS int(get_config(borrow_days, 30)) DAILY_FINE float(get_config(daily_fine, 0.5))这个改法的好处是显而易见的管理员不再需要登录服务器改代码直接在“系统设置”页面就能调整规则。遇到某些读者逾期行为比较多的情况把罚款单价调高来抑制超期这种操作从此变成了配置变更而不是一次代码发布。顺着这个思路你还可以继续扩展图书分类管理做成树形结构、把罚款对接支付接口、为逾期读者发短信提醒。后面这些改造都绕不开一个共同的路径——先找到原来写死的逻辑再把它抽象成数据和配置。从那以后我每次拿到这类毕设项目都强制先画一遍“写死常量清单”把数字和文本全部标记出来再决定哪些应该入库、哪些保留代码默认值。每次改完我都会跑到归还流程里用测试数据重新走一遍逾期分支确认改动的生效范围没被破坏。这套习惯帮我避免了无数次上线前才发现配置没生效的尴尬希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/18 10:56:35 · 阅读 1.2k Python Django+Vue 图书馆管理系统：前后端分离架构与实战解析
简介一套基于Python开发的图书馆管理系统毕业设计完整资源面向计算机专业毕业生、需要完成课程设计或毕设项目的学生也适合希望快速上手Django框架与MySQL数据库的开发者参考。系统涵盖图书信息、借阅、归还、罚款等核心模块采用面向对象设计并配有说明文档便于理解架构和二次开发。资源包共783个文件约19.21MB主要包括45个Python源码文件含模型、视图、控制器、53个Vue页面组件、164个JavaScript脚本以及CSS样式、HTML页面、SQL数据库脚本等另有安装运行批处理和说明文档结构清晰可直接部署或改造。目前已有186人学习下载适合用于毕设答辩、项目实战练习或作为图书馆信息化管理系统的开发蓝本能够有效缩短开发周期并降低起步难度。1. 图书馆管理系统一个能讲清楚前后端完整链路的 Python 毕设项目对正在做毕设的人来说最怕的不是写不出代码而是答辩时讲不清楚“这个系统的数据是怎么流动的”。这套基于 Python 的图书馆管理系统从文件名就能看出它的工程形态——有 Vue 前端组件、有 Django 风格的后端逻辑、有论文文档还带构建和启动脚本。它不是一个只跑在控制台的教学 Demo而是一套前后端分离的完整系统图书信息管理、借阅、归还、罚款统计、读者管理都在里面。适合两类人一是需要一份能跑通、能讲深、能被追问的毕设源码二是想找一个“看得见完整链路”的 Django 实战项目用来学 MVC 架构和前后端联调。2. 架构与目录拆解Django 后端加 Vue 前端的双工程布局2.1 技术选型为什么是 Django 加 MySQL而不是 Flask 加 SQLite这个系统后端选择了 Django前端是 Vue 组件加构建脚本的组合。Django 在这个场景里几乎是“标配”选择它自带 ORM 和 Admin 后台模型定义好之后数据库表结构可以自动迁移生成图书、读者、借阅记录这类实体关系的建模成本很低。相比之下 Flask 更轻但 ORM、表单校验、权限这些都要自己拼对毕设来说工作量会上去。数据层用的 MySQL这一点也很典型。图书馆系统有明确的实体关系——一本书可以被多次借阅、一个读者有多条借阅记录、一次归还可能产生罚款MySQL 这种关系型数据库在处理这类业务上比 NoSQL 顺手得多。而且 Django 的 ORM 对 MySQL 的兼容性非常成熟只需要装mysqlclient或pymysql驱动改一下settings.py里的数据库配置就能接上。前端的选型从文件名可以看出来IndexMain.vue、IndexAsideStatic.vue、BreadCrumbs.vue、IndexHeader.vue这套命名风格是典型的 Vue 2 Element UI 后台管理布局——左侧静态菜单、顶部面包屑导航、主内容区域切换。这类结构在管理系统中非常普遍组件拆分也符合“一个页面一个组件”的维护习惯。2.2 目录结构全览从 .bak 备份文件反推项目组织方式这套资源里有一批.bak后缀的文件比如update-password.vue.bak、IndexMain.vue.bak。.bak通常是开发者在改版前手动复制的备份说明在原工程里这些组件是“有效文件”.bak只是历史版本存档。我一般拿到这类资源会先建立一套还原后的目录预期再对照实际内容往里填library_system/ ├── backend/ # Django 后端工程 │ ├── manage.py │ ├── requirements.txt # 依赖清单 │ ├── library/ # 项目配置目录 │ │ ├── settings.py # 数据库、DRF、跨域配置 │ │ ├── urls.py # 根路由 │ │ └── wsgi.py │ └── bookapp/ # 业务应用 │ ├── models.py # 图书、读者、借阅、罚款模型 │ ├── views.py # 借阅/归还/罚款的视图函数 │ ├── serializers.py # DRF 序列化器 │ └── urls.py # 业务路由 ├── frontend/ # Vue 前端工程 │ ├── src/ │ │ ├── views/ # IndexMain.vue 等页面组件 │ │ ├── components/ # IndexHeader.vue 等布局组件 │ │ ├── api/ # axios 请求封装 │ │ └── router/ # 前端路由 │ ├── package.json │ └── vue.config.js # 代理配置 ├── scripts/ │ ├── 安装.bat │ ├── 运行.bat │ ├── 2-run.bat │ └── 3-build.bat ├── docs/ # 论文和说明文档 └── database/ └── library.sql # 初始化 SQL 脚本2.3 数据库模型设计五张表撑起的核心业务图书管理、读者管理、借阅归还、罚款管理这几个功能落到数据库层面其实很清晰。常见做法是设计这样一组模型# bookapp/models.py from django.db import models class Book(models.Model): 图书信息表 isbn models.CharField(max_length20, uniqueTrue, verbose_nameISBN) title models.CharField(max_length200, verbose_name书名) author models.CharField(max_length100, verbose_name作者) publisher models.CharField(max_length100, verbose_name出版社) publish_date models.DateField(verbose_name出版日期) category models.ForeignKey(Category, on_deletemodels.SET_NULL, nullTrue) total_stock models.IntegerField(default1, verbose_name馆藏总量) available_stock models.IntegerField(default1, verbose_name可借数量) location models.CharField(max_length50, verbose_name馆藏位置) class Reader(models.Model): 读者信息表 reader_id models.CharField(max_length20, uniqueTrue, verbose_name读者证号) name models.CharField(max_length50, verbose_name姓名) id_card models.CharField(max_length18, verbose_name身份证号) phone models.CharField(max_length11, verbose_name手机号) register_date models.DateField(auto_now_addTrue, verbose_name注册日期) status models.BooleanField(defaultTrue, verbose_name是否有效) class BorrowRecord(models.Model): 借阅记录表 book models.ForeignKey(Book, on_deletemodels.CASCADE, verbose_name图书) reader models.ForeignKey(Reader, on_deletemodels.CASCADE, verbose_name读者) borrow_date models.DateTimeField(auto_now_addTrue, verbose_name借出时间) due_date models.DateTimeField(verbose_name应还时间) return_date models.DateTimeField(nullTrue, blankTrue, verbose_name实际归还时间) status models.CharField(max_length10, defaultborrowed, choices[(borrowed, 借出中), (returned, 已归还)])BorrowRecord是整个系统里最关键的一张表。它用borrow_date加due_date记录借期return_date判断有没有逾期逾期天数由due_date和return_date的差计算出来罚款金额再根据逾期天数乘以单价得出。图书的available_stock是借还操作时要同步维护的字段——借出减一归还加一。这种设计把“库存扣减”和“记录流水”拆在两个层面逻辑上更稳翻车概率比直接在图书表上记状态小很多。3. 核心模块实现借阅、归还、罚款的代码走读3.1 借阅接口从请求进入到业务校验的完整路径借阅是图书馆系统最高频的操作。前端调用/api/borrow/接口传入book_id和reader_id后端要做三件事验读者状态、验库存余量、创建借阅记录并扣减库存。核心视图代码大致长这样# bookapp/views.py from django.utils import timezone from datetime import timedelta from django.http import JsonResponse import json from .models import Book, Reader, BorrowRecord MAX_BORROW_COUNT 5 # 单读者最大在借数量 BORROW_DAYS 30 # 默认借期天数 def borrow_book(request): if request.method ! POST: return JsonResponse({code: 405, msg: 仅支持 POST 请求}, status405) data json.loads(request.body) book_id data.get(book_id) reader_id data.get(reader_id) # 1. 读者校验 reader Reader.objects.filter(reader_idreader_id, statusTrue).first() if not reader: return JsonResponse({code: 4001, msg: 读者不存在或已被停用}) # 2. 数量校验防止在借量超过上限 active_count BorrowRecord.objects.filter( readerreader, statusborrowed ).count() if active_count MAX_BORROW_COUNT: return JsonResponse({code: 4002, msg: f借阅数量已达上限 {MAX_BORROW_COUNT} 本}) # 3. 库存校验 book Book.objects.filter(idbook_id).first() if not book or book.available_stock 0: return JsonResponse({code: 4003, msg: 图书不存在或已全部借出}) # 4. 创建借阅记录并扣减库存 due_date timezone.now() timedelta(daysBORROW_DAYS) record BorrowRecord.objects.create( bookbook, readerreader, due_datedue_date ) book.available_stock - 1 book.save() return JsonResponse({code: 0, msg: 借阅成功, data: { record_id: record.id, due_date: due_date.strftime(%Y-%m-%d) }})这段逻辑里几个参数值是按实际业务定的。MAX_BORROW_COUNT 5表示单读者最多同时在借 5 本如果你所在学校的规则是一人 10 本直接改这个常量即可。BORROW_DAYS 30是默认借期timedelta(days30)计算出应还时间然后存库。代码把业务校验分成四步每步返回独立错误码前端可以按错误码给用户展示不同的提示文案这也是我习惯了的一种接口设计方式——错误码比笼统的 “error” 好排查得多。这里有个值得一提的设计细节借阅记录创建用BorrowRecord.objects.create()库存扣减放在之后。理论上这两步应该放在一个数据库事务里但作为教学项目先拆开写会更直观。我拿到代码后会建议你自己加一层transaction.atomic()包裹防止创建记录成功但扣库存失败的数据不一致问题。3.2 归还与罚款计算逾期天数的统计口径归还逻辑比借阅多一步判断是否逾期逾期了就同时生成一条罚款记录。罚款计算看似简单但“按自然日还是按工作日算”“当天归还算不算逾期”这些细节是很多系统里扯皮最多的地方。# bookapp/views.py from .models import BorrowRecord, FineRecord DAILY_FINE 0.5 # 每天罚款 0.5 元 def return_book(request): if request.method ! POST: return JsonResponse({code: 405, msg: 仅支持 POST 请求}, status405) data json.loads(request.body) record_id data.get(record_id) record BorrowRecord.objects.filter(idrecord_id, statusborrowed).first() if not record: return JsonResponse({code: 4004, msg: 借阅记录不存在或已归还}) # 1. 标记归还 now timezone.now() record.return_date now record.status returned record.save() # 2. 恢复库存 book record.book book.available_stock 1 book.save() # 3. 计算逾期天数 due record.due_date overdue_days 0 if now due: # 跨天计算只要超过应还时刻就算逾期 1 天 overdue_days (now - due).days or 1 # 4. 生成罚款记录 fine_amount round(overdue_days * DAILY_FINE, 2) if fine_amount 0: FineRecord.objects.create( recordrecord, readerrecord.reader, amountfine_amount, statusunpaid, reasonf逾期 {overdue_days} 天 ) return JsonResponse({code: 0, msg: 归还成功, data: { overdue_days: overdue_days, fine: fine_amount }})罚款计算的核心是(now - due).days这个表达式。Python 的timedelta.days是向下取整的比如超时 1 小时得到days 0所以用了or 1把不足一天但确实逾期的场景兜住。DAILY_FINE 0.5是每本每日罚款单价同样是一个可以配置化的常量——在第六章我会讲怎么把它改成数据库可配置。归还接口的返回值把overdue_days和fine分开返回前端可以在归还结果弹窗里直接展示“逾期 3 天罚款 1.5 元”。这一步对用户体验很重要系统要让人知道罚款不是凭空产生的。3.3 罚款记录查询与管理管理端不看明细就是黑匣子罚款功能如果只有“生成”没有“查询”对管理员来说就是一个黑匣子。系统的罚款管理模块一般包含三块罚款列表、缴费确认、统计汇总。列表后端用 Django ORM 按时间倒序筛# bookapp/views.py def fine_list(request): reader_id request.GET.get(reader_id, ) status request.GET.get(status, ) fines FineRecord.objects.all() if reader_id: fines fines.filter(reader__reader_idreader_id) if status: fines fines.filter(statusstatus) fines fines.order_by(-created_at) data [{ fine_id: f.id, reader_name: f.reader.name, book_title: f.record.book.title, amount: f.amount, status: f.get_status_display(), reason: f.reason, created_at: f.created_at.strftime(%Y-%m-%d %H:%M) } for f in fines] return JsonResponse({code: 0, data: data})order_by(-created_at)按创建时间倒序新产生的罚款一定排在最前面。get_status_display()是 Django ChoiceField 自带的取中文展示值的方法unpaid会显示为“未缴费”。管理员的“确认缴费”操作就是把这个状态字段改成paid在真实系统里还可以加上操作管理员 ID 和缴费时间方便后续对账。4. 运行部署指南从安装依赖到浏览器打开全流程4.1 环境准备Python、MySQL、Node 三件套最稳妥的跑通姿势是准备这三样Python 3.8 及以上、MySQL 5.7 或 8.0、Node.js 14 以上。系统的.bat脚本已经把这套流程写成了安装和启动两个环节但底层依赖还是需要手动准备的。先看后端依赖。这个项目用到的核心包包括Django、djangorestframework、mysqlclient和django-cors-headers按安装脚本的约定执行pip install django djangorestframework mysqlclient django-cors-headers如果在 Windows 上装mysqlclient报错缺 C 编译环境是常态我一般会换成纯 Python 的pymysql然后在manage.py和settings.py里加两行import pymysql pymysql.install_as_MySQLdb()这一步是完美替代方案ORM 层没有感知模型照写不误。4.2 数据库初始化建库、改配置、执行迁移在 MySQL 里建一个名为library_db的数据库注意字符集选utf8mb4。然后打开backend/library/settings.py把数据库连接信息改成你自己的DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: library_db, USER: root, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, } }改完之后执行迁移生成表结构cd backend python manage.py makemigrations python manage.py migrate python manage.py createsuperusercreatesuperuser会创建一个管理员账号用来登录 Django Admin 后台也方便在后台预填一些图书和读者测试数据。如果资源里带了library.sql初始化脚本也可以跳过 migrate 直接导入 SQL 文件效果一样。4.3 前端构建与启动弄明白 2-run 和 3-build 的顺序这套资源的脚本编排是2-run.bat和3-build.bat分开的命名顺序暗示了先安装依赖再构建。实际手动执行是这样cd frontend npm install npm run serve开发模式下 Vue 会跑在localhost:8080它和后端localhost:8000是两个端口联调需要配代理。在vue.config.js里加module.exports { devServer: { proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true } } } };这样前端的/api/...请求会转发到 Django 的接口上避免跨域问题。如果是部署环境用npm run build产出dist静态目录再由 Nginx 统一托管前后端这个项目里3-build.bat对应的就是这一步。4.4 启动顺序与验证清单跑起来之后按下面的路径走一遍基本流程确认核心功能没处漏油用管理账号登录系统确认首页统计数字和图标加载正常。进入图书管理页新增一本测试图书ISBN 不要和其他书重复。进入读者管理新增一个测试读者记录读者证号。在借阅页面输入图书 ID 和读者证号完成借阅确认图书可用库存减一。手动把这本书的应还日期改到昨天在数据库里执行UPDATE或用 Django Admin然后走归还流程确认产生罚款记录。到罚款管理页面查看到这条罚款记录完成缴费状态确认。第六步尤其关键。如果罚款记录没有生成多半是due_date和实际归还时间之间没有跨天或者是在页面里借阅时BORROW_DAYS太长。测试“逾期场景”时直接在库里改due_date是效率最高的做法。5. 常见问题与避坑记录环境、编码、跨域的排查清单5.1 MySQL 连接报错Access denied for user现象启动 Django 后访问接口直接 500日志里出现Access denied for user rootlocalhost。原因数据库用户名密码和settings.py里配置不一致或者 MySQL 只允许localhost登录但配置写成了127.0.0.1的权限没授权。解决先确认 MySQL 里执行SELECT user, host FROM mysql.user;看 root 账号允许的 host 范围然后在settings.py里把 HOST 改成和权限匹配的地址。常见避坑点是 MySQL 8.0 默认认证插件是caching_sha2_passwordpymysql会因此报错解决方式是在 MySQL 里执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 密码;切换认证方式。5.2 前端请求后端报跨域错现象浏览器控制台出现blocked by CORS policy接口能通但浏览器拦截了响应。原因前端跑在8080端口后端在8000端口跨域默认被浏览器拦。如果项目里没有django-cors-headers或未在settings.py里配置白名单就会翻车。解决两步走。安装django-cors-headers后在settings.py的INSTALLED_APPS加corsheadersMIDDLEWARE加corsheaders.middleware.CorsMiddleware然后配置CORS_ALLOWED_ORIGINS [http://localhost:8080]如果你用的是开发代理方案则不需要这个配置vue.config.js里的 proxy 已把跨域问题消化掉了。两者选一个即可不要同时纠结。5.3 中文乱码和无法写入的问题现象图书分类填入“文学类”保存后数据库查出来是乱码。原因MySQL 建库时没有指定字符集默认latin1不支持中文。解决建库语句补充完整字符集定义CREATE DATABASE library_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;如果库已经建好了用ALTER DATABASE library_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;补救。还要确认settings.py里OPTIONS加了charset: utf8mb4。这个坑一翻就是全部接口都中文乱码排查起来很容易抓狂建议拿到项目第一件事就先验字符集。5.4 迁移失败提示某个字段已存在或缺失现象执行python manage.py migrate报错说column ... already exists或者table has no column named ...。原因库里已经有残留的表但和 Django 的迁移记录django_migrations表对不上。常见于资源自带library.sql但手动导入后又跑了 migrate。解决如果库里不要求保留数据直接删库重建再按顺序执行makemigrations和migrate。如果我需要保留已有测试数据会先python manage.py migrate --fake把当前迁移记录标记为已执行再手工比对差异但这种方式踩坑概率高新手建议直接重建库。5.5 Admin 后台能登录但前端登录一直转圈现象Django Admin 登录正常前端首页也能打开但登录按钮点击后一直 loading接口返回 500。原因前端登录调用的接口和 Django 后台登录是两套多半是自定义登录视图里没有处理密码校验或者用户表用了自定义模型导致authenticate()查询报错。解决检查后端日志如果看到RelatedObjectDoesNotExist或用户模型相关报错说明自定义Reader模型和 Django 默认auth.User的关联没搭好。常见做法是在自定义登录视图里直接用Reader表做密码校验不经过 Django 的auth模块这样最省事也不用处理模型关联的坑。6. 二次开发与扩展把罚款规则改造成可配置项做完的基础功能如果只能对上答辩那多少有点可惜。实际开发里最常见的一个改造需求是罚款单价、借阅上限、借期天数这类业务参数不应是代码里写死的常量。拿第五章的DAILY_FINE 0.5和MAX_BORROW_COUNT 5来说它们散落在视图模块里每次改都要动代码、重启服务。把这些值挪到数据库里做一个SystemConfig模型是最直接的管理方法# bookapp/models.py class SystemConfig(models.Model): 系统参数配置表 key models.CharField(max_length50, uniqueTrue, verbose_name配置键) value models.CharField(max_length200, verbose_name配置值) description models.CharField(max_length200, blankTrue, verbose_name说明)然后写一个读取配置的小工具函数替代模块里的常量# bookapp/config.py from .models import SystemConfig def get_config(key, defaultNone): cfg SystemConfig.objects.filter(keykey).first() return cfg.value if cfg else default在借阅和归还视图里把MAX_BORROW_COUNT、BORROW_DAYS、DAILY_FINE替换成动态读取例如MAX_BORROW_COUNT int(get_config(max_borrow_count, 5)) BORROW_DAYS int(get_config(borrow_days, 30)) DAILY_FINE float(get_config(daily_fine, 0.5))这个改法的好处是显而易见的管理员不再需要登录服务器改代码直接在“系统设置”页面就能调整规则。遇到某些读者逾期行为比较多的情况把罚款单价调高来抑制超期这种操作从此变成了配置变更而不是一次代码发布。顺着这个思路你还可以继续扩展图书分类管理做成树形结构、把罚款对接支付接口、为逾期读者发短信提醒。后面这些改造都绕不开一个共同的路径——先找到原来写死的逻辑再把它抽象成数据和配置。从那以后我每次拿到这类毕设项目都强制先画一遍“写死常量清单”把数字和文本全部标记出来再决定哪些应该入库、哪些保留代码默认值。每次改完我都会跑到归还流程里用测试数据重新走一遍逾期分支确认改动的生效范围没被破坏。这套习惯帮我避免了无数次上线前才发现配置没生效的尴尬希望帮到你。本文还有配套的精品资源点击获取