毕业设计-基于Python的图书馆管理系统
1. 系统定位：图书馆管理系统——读者在线查书/借书/还书 +
管理员后台管理图书，主打"轻量化"（论文原话"轻量化开发，
只完成图书管理系统最本质的工作"）。
2. 技术栈（这篇的最大特色，交代得非常具体）：
Python 3.6.4 + Django 3.2.12 + MySQL + PyCharm +
Navicat 15 + pymysql驱动。版本号都写明了，答辩前要记住。
★注意版本逻辑：论文说"因为Python是3.6.4，低版本Django
不支持Python3，故用Django 3.2.12"——这句话逻辑是反的
（应是"低版本Django不支持新版Python"或"高版本Django
不支持Python3.6"），Django 3.2是LTS长期支持版，适配
Python3.6-3.10，答辩要能说圆。
3. 两类角色+三个界面：
- 前台（游客/用户）：图书列表（每页6本分页）、搜索
（书名/分类/作者/状态）、图书详情（收藏/评论/赞/踩/
借阅）、系统公告、信息反馈（留言板）、个人中心
- 用户后台：个人中心、图书借阅管理（可发起归还）、
图书归还管理
- 管理员后台（Django-Admin）：用户管理、图书分类管理、
图书信息管理、图书借阅管理（审核）、图书归还管理
（审核+入库）、图书入库管理、信息反馈（回复）、
系统管理（轮播图/系统公告）
4. 核心业务闭环（答辩主线）：
管理员入库图书 → 用户搜索/浏览 → 申请借阅(待审核) →
管理员审核通过 → 生成借阅记录(借阅天数/应还日期) →
用户发起归还 → 管理员审核归还+图书入库 → 库存恢复。
5. 8张数据表：图书借阅表、图书归还表、图书分类表、
图书入库表、系统公告表、信息反馈表、用户信息表、
图书信息表。全部拼音字段（tushubianhao图书编号、
jieyuetianshu借阅天数、yinghairiqi应还日期、
sfsh是否审核默认待审核、shhf审核回复）。
6. Django-Admin是本系统的重头戏（论文2.2节花了大篇幅）：
"一行代码即可管理一张数据库表"（admin.site.register），
相比手动后台1个模型要4个urls+4个视图+4个模板，
Admin自带增删改查，对"以管理工作为重"的图书系统极度契合。
7. MTV模式（论文口径）：Django将MVC的View拆成View+Template，
View管逻辑，Template管页面，Model管数据，View把两者
连起来——"每一部分只做一件事，耦合度大大降低"。
8. ORM三原则（论文原文，可能考）：简单（最基本形式构建
数据）、传达性（数据库结构被任何人都能理解的语言文档化）、
精确性（基于数据模型创建正确标准化的结构）。
9. 测试方法：动态测试+黑盒测试。测试细节比一般模板论文
真实得多：借阅扣库存、库存归零不能借、库存为负不能借、
分页首页点上一页不跳转、搜索大小写切换、书名切片模糊
搜索、两次密码不同注册不通过等——都是可复述的真用例。
10. 系统自述的不足（结论章原文，答辩"缺点"题直接用）：
界面生硬、未加Django Comments库、没爬虫爬书目、
没做读书喜好数据分析、没配专业服务器、无真实图书内容
——"只能算一个雏形"。
================================================================
【一、论文结构总览】（六章26页，每章带"小结"是本篇格式特色）
================================================================
1 绪论
1.1 开发背景和意义（图书馆系统60年代末起源→90年代末
革命性变革的历史脉络写得很完整）
1.2 论文的结构（逐章说明）
1.3 小结
2 相关技术简介及部署环境说明
2.1 Python（90年代Guido设计、胶水语言、知乎/豆瓣/
Youtube都是Python开发）
2.2 Django（MTV、ORM三原则、URLConf、Template、View、
Django-Admin、App应用概念）
2.3 PyCharm（JetBrains IDE）
2.4 MySQL（瑞典MySQL AB、体积小速度快开源）
2.5 Navicat Premium（香港卓软数码、Navicat15）
★注意：目录里没有2.5条目（目录从2.4直接跳2.6），正文有2.5
2.6 小结
3 需求分析
3.1 可行性分析（经济/市场/技术/用户使用/法律——五维，
比一般论文多"市场"和"法律"两维）
3.2 需求分析（6条功能需求）
3.3 小结
4 系统总体设计
4.1 总体模块设计（查询借阅模块/后台模块/管理员模块/
注册登录模块四大块）
4.2 模型的设计（8张表结构）
4.3 系统的E-R图（用户层面E-R图一张）
4.4 小结
5 系统详细设计与实现
5.1 前台功能模块（图5-1~5-6）
5.2 管理员功能模块（图5-7~5-15）
5.3 小结
6 系统测试
6.1 软件测试的定义
6.2 图书列表页模块测试（借阅/分页/图书简介/搜索）
6.3 归还模块测试
6.4 注册、登录模块测试
6.5 小结（动态测试+黑盒测试）
结论（含大段自我批评式不足陈述）/ 参考文献15篇 / 致谢
================================================================
【二、核心技术点精讲】（答辩必问，逐个吃透）
================================================================
■ Django-Admin（本系统管理员端的实现方式，最重要）
- 来自django.contrib标准库，settings.py INSTALLED_APPS
里默认启用，超级用户 python manage.py createsuperuser。
- 每个模型只需 admin.site.register(模型名) 一行代码，
就获得列表页/详情页/增删改查/搜索/过滤。
- 定制能力：ModelAdmin类可配置 list_display（列表显示
哪些列）、search_fields（可搜索字段）、list_filter
（侧边过滤器）——对应论文里"图书借阅管理可按图书编号/
名称/账号/是否通过查询"。
- 答辩被问"你的后台怎么做的"：诚实答"基于Django-Admin
二次定制"，并强调这是Django官方推荐做法，不是偷懒。
■ MTV与MVC的映射（口诀）
Django M(Model) = MVC的M（数据处理）
Django T(Template) = MVC的V（页面展示）
Django V(View) = MVC的C（逻辑调度）
论文说法："Django将MVC设计模式中的视图分成了View模块和
Template模块两部分"。
■ ORM与pymysql
- Python类定义模型，类属性=数据库列；ORM把面向对象调用
映射成SQL，通过pymysql执行（论文原话）。
- Python3不再支持MySQLdb模块，所以用pymysql
（装法：pip install pymysql，并在项目__init__.py里
import pymysql; pymysql.install_as_MySQLdb()）。
- settings.py数据库配置：ENGINE=
django.db.backends.mysql + NAME/USER/PASSWORD/HOST/PORT。
■ 分页实现（论文"每页六个"）
- Django自带Paginator：Paginator(book_list, 6)，
page = paginator.get_page(page_num)，模板里渲染
object_list和page.has_previous/has_next。
- 测试细节呼应：首页点"上一页"不跳转=page.has_previous()
为False时按钮禁用。
■ 搜索实现（模糊查询）
- Django ORM的 __icontains（不区分大小写包含查询）：
Book.objects.filter(tushumingcheng__icontains=kw)
——正好对应论文测试"输入字母频繁大小写切换也能搜到"；
书名切片搜索=icontains本身就是模糊匹配子串。
■ 借阅审核机制
- sfsh字段默认"待审核"，管理员在借阅管理里审核；
- 归还同样有sfsh待审核+shhf审核回复；
- 归还审核通过后管理员执行"图书入库"操作恢复库存。
================================================================
【三、数据库设计拆解】（8张表，重点记4张）
================================================================
★ 表4.1 图书借阅表（核心业务表）：
jieyuebianhao借阅编号 / tushubianhao图书编号 /
tushumingcheng图书名称 / tushufenlei图书分类 /
fengmian封面(longtext) / zuozhe作者 /
jieyuetianshu借阅天数(int) / jieyueriqi借阅日期(date) /
yinghairiqi应还日期(date) / beizhu备注 / zhanghao账号 /
xingming姓名 / shouji手机 / sfsh是否审核(默认待审核) /
shhf审核回复 —— 借阅天数+借阅日期推算应还日期。
★ 表4.2 图书归还表：
guihaibianhao归还编号 / tushubianhao/mingcheng/fenlei /
fengmian / zuozhe / yinghairiqi应还日期 /
guihairiqi归还日期(date) / zhanghao/xingming/shouji /
sfsh待审核 / shhf审核回复 —— 与借阅表结构对称，
归还时对照应还日期可判断是否逾期。
★ 表4.8 图书信息表（主数据表）：
tushubianhao图书编号 / tushumingcheng图书名称 /
tushufenlei图书分类 / fengmian封面 / zuozhe作者 /
chubanshe出版社 / tushuzhuangtai图书状态(在馆/借出) /
tushujianjie图书简介(longtext) / thumbsupnum赞(默认0) /
crazilynum踩(默认0) / clicktime最近点击时间 /
clicknum点击次数(默认0) —— 赞踩点击三计数与美食课题
同款模板结构。
★注意：此表没有"库存数量"字段！但测试章节说"借阅一本
查看图书数量是否减少、数量归零能否借出、数量为负不能借"——
表结构里根本没有数量字段，测试与表设计对不上（见雷点5）。
★ 表4.7 用户信息表：
zhanghao账号 / xingming姓名 / mima密码 / xingbie性别 /
touxiang头像(longtext) / shouji手机 —— 简洁的六字段。
其余表速记：图书分类表(tushufenlei单字段)、图书入库表
(编号/名称/分类/封面/作者/rukushijian入库时间)、系统公告表
(title/introduction/picture/content)、信息反馈表
(userid/username/avatarurl/content+cpicture留言图片/
reply+rpicture回复图片——支持图文留言和图文回复）。
----------------------------------------------------------------
E-R图：论文只给了"用户层面"一张总E-R图（图4.1），说"从
管理员的层面来说，管理员可以管理此系统中的所有实体"——
没有逐实体E-R图（比问卷课题5张E-R图少），答辩被问E-R细节
就按"用户-图书借阅-图书-图书归还"的主线口述。
----------------------------------------------------------------
================================================================
【四、功能实现细节】（对着截图能讲出来）
================================================================
前台（游客+用户）：
1. 首页：首页、图书信息、系统公告、信息反馈、后台管理
五个入口；图书列表每页6本，分页切换。
2. 注册：账号/姓名/密码/性别，两次密码校验。
3. 图书信息：四种搜索字段（名称/分类/作者/状态）；
详情页可收藏、评论、赞、踩、借阅。
4. 借阅操作：填写借阅天数等提交，状态"待审核"。
5. 信息反馈：查看别人的留言+自己发布（可带图）。
6. 个人中心：改个人信息、退出登录、我的收藏管理。
用户后台：
- 图书借阅管理：查看自己借阅详情，发起"归还"操作。
- 图书归还管理：查看归还记录。
管理员后台（Django-Admin）：
1. 用户管理：按账号/姓名/性别查询，增删改。
2. 图书分类管理：分类名称增删改。
3. 图书信息管理：四字段查询，新增/修改/查看评论/
回复评论/删除。
4. 图书借阅管理：按图书编号/名称/账号/是否通过查询，
审核借阅申请。
5. 图书归还管理：审核归还+图书入库（恢复在馆状态）。
6. 图书入库管理：入库记录维护。
7. 信息反馈：查询/修改/回复/删除。
8. 系统管理：轮播图、系统公告。
================================================================
【五、PPT逐页要点】（22页）
================================================================
P1 封面：题目+"汇报人姓名：""汇报时间："（★两处都空着！）
P2 摘要（论文摘要全文）
P3 概述-开发背景（60年代末起源→90年代末变革）
P4 开发意义（特性1-3：高自由度/互动性强/展现形式丰富）
P5 开发意义续（特性4-5：高检索率/节省资源）
P6 论文的结构+第1章小结
P7 Python简介（3.6.4版本、知乎/豆瓣/Youtube案例）
P8 Django简介（MTV、ORM三原则）
P9 Django续（URLConf/Template/View/Django-Admin/App
六大核心+版本3.2.12）
P10 PyCharm + MySQL（pymysql连接）
P11 Navicat + 2.6小结
P12 系统的E-R图（★只有一张E-R图，无文字说明）
P13 系统前台界面图
P14 图书信息详情界面图
P15 图书借阅界面图
P16 个人中心界面图
P17 管理员登录界面图
P18 管理员功能界面图
P19 用户后台功能界面图
P20 结论（含全部"不足"自述——PPT照搬论文结论全文，
把"只能算一个雏形"这种自贬话术放PPT上有风险，
答辩老师容易顺着追问，建议PPT版精简不足表述）
P21 致谢（论文致谢全文）
P22 THE END!谢谢观看 2022（★年份"2022"残留，若2026年
答辩需更新或删除）
PPT与论文的差异点：
- PPT结构=论文前两章全文+图集+结论致谢，缺了需求分析、
总体设计（模块设计）、系统测试三大块的文字内容
（测试只有论文6章可讲，PPT没放）。
- PPT每页都有两张装饰图片（提取时显示连续[图片]）。
- PPT P12 E-R图页无任何文字解释，讲的时候要自己补：
"这是系统用户层面的E-R图，实体包括用户、图书、借阅、
归还、公告、反馈，用户与图书通过借阅/归还产生联系"。
- PPT没有参考文献页。
================================================================
【六、答辩高频问题预测】（14问，含参考答案要点）
================================================================
Q1 借阅流程完整走一遍？
A：管理员图书入库→用户前台搜索图书（名称/分类/作者/
状态四字段）→详情页点借阅→填写借阅天数提交，生成
借阅记录（sfsh=待审核）→管理员借阅管理审核通过→
图书状态改为"借出"→到期用户在个人后台发起归还→
管理员归还管理审核→执行图书入库，状态恢复"在馆"。
Q2 应还日期怎么计算的？
A：借阅日期+jieyuetianshu借阅天数。Django里
yinghairiqi = jieyueriqi + timedelta(days=n)。
归还时比较guihairiqi与yinghairiqi判断逾期。
Q3 为什么选Django-Admin做后台而不是自己写？
A：①Admin是Django标准库自带，admin.site.register
一行代码获得完整增删改查+搜索+过滤，开发效率高；
②图书管理系统以管理操作为重，Admin的列表+表单模式
契合；③Admin有权限体系（staff/superuser）和操作日志。
定制上用ModelAdmin的list_display/search_fields/
list_filter满足查询需求。
Q4 MTV和MVC的关系？
A：Django把MVC的View拆成Template（页面）+View（逻辑），
即 Django的View≈MVC的Controller，Django的Template≈
MVC的View，Model不变。好处是逻辑与展示分离，
模板可继承复用。
Q5 同一本书被两个人同时借阅怎么处理？（并发经典题）
A：借阅事务里先检查tushuzhuangtai是否"在馆"，借出
改状态为"借出"；并发下可能超借，严谨做法是
select_for_update()行锁或给状态加唯一约束/乐观锁，
甚至Redis分布式锁。诚实答"当前版本单机低并发没出
问题，高并发场景需要加锁"。
Q6 图书状态和库存数量什么关系？
A：本系统用tushuzhuangtai字段（在馆/借出）表达单本
借阅状态，是"一馆一本书一条记录"模型。若同一书目
有多本馆藏，应扩展kucunshuliang(库存数)字段，
借阅-1、归还+1。论文测试提到"数量减少/归零/为负"，
说明设计意图是多本模型，但表里没建数量字段——
被问到就答"当前版本以状态字段实现，数量字段列入
扩展"。
Q7 数据库表之间的关联怎么设计的？
A：以zhanghao/tushubianhao做软关联（借阅表、归还表
都冗余存了图书名称、分类、封面、作者）——为查询
性能做的反范式冗余，代价是图书改信息时借阅记录
不联动。严格设计应用外键(ForeignKey)，这里用冗余
换查询简单，答辩可主动讲权衡。
Q8 为什么要审核借阅/归还？
A：①控制馆藏流转（确认书在馆才放借）；②记录经手人
与时间，责任可追溯；③防止恶意占用。sfsh待审核+
shhf审核回复是通用审核字段设计。
Q9 搜索功能怎么实现的？大小写都能搜到？
A：Django ORM的__icontains查询（SQL层面LIKE，
MySQL默认不区分大小写校验规则），所以大小写切换
都能命中；书名切片搜索本质是子串模糊匹配LIKE
'%切片%'。
Q10 分页怎么实现的？
A：Django Paginator(books, 6)每页6条，视图get_page
处理页码越界，模板用has_previous/has_next控制
上下页按钮——对应测试用例"第一页点上一页不跳转"。
Q11 测试怎么做的？举个具体用例？
A：动态测试+黑盒测试。举例：借阅模块——借一本看数量
是否-1；重复借到数量为0时不能借出且有提示；管理员
误操作致数量为负时用户不能借阅；归还后数量恢复。
注册模块——两次密码不同不通过；不规范姓名有提示；
非纯数字学号有提示。
Q12 系统不足与改进？（论文结论原文+延展）
A：论文自述：界面生硬、未加Comments库、无爬虫爬书目、
无读书喜好数据分析、无专业服务器、无真实图书内容。
延展答法：①库存数量字段缺失（多本馆藏场景）；
②无续借/预约功能；③无逾期提醒（可用Celery定时
任务扫描yinghairiqi发站内信）；④推荐系统（借阅
历史做协同过滤）；⑤前后端分离（DRF）。
Q13 Python 3.6.4 + Django 3.2.12 这组合有什么讲究？
A：Django 3.2是LTS长期支持版（支持到2024年4月），
兼容Python 3.6-3.10，3.6.4配3.2.12是稳定组合。
注意：Python3.6本身2021年12月已停止官方支持，
现在新项目建议Python3.10+Django4.2 LTS——被问到
版本老就答"开发时点考虑的是稳定性与教程生态"。
Q14 部署方式？
A：开发用runserver；生产 uWSGI/Gunicorn + Nginx +
MySQL，静态文件collectdata收集后由Nginx直供，
DEBUG=False。论文自述"没有为平台配置专业服务器"
是诚实不足项。
================================================================
【七、高危雷点清单】（模板套用痕迹与数据矛盾，答辩前必查）
================================================================
雷点1【英文摘要串台·必改】Abstract里写"a simple and
light book recommendation system"（图书推荐系统）、
功能模块写成"message board"（留言板）、关键词
"Book recommendation system"——中文摘要是"图书馆管理
系统/信息反馈"，中英文不对应，模板来自"图书推荐系统"
的痕迹。英文摘要必须重写对齐。
雷点2【目录缺2.5】目录从2.4 MySQL直接跳2.6小结，正文
里其实有"2.5 Navicat Premium简介"——目录漏编2.5，
答辩前更新目录域。
雷点3【版本逻辑表述反了】2.2节"因为本次使用的Python版本
为3.6.4，低版本的Django不支持Python3，故此次使用的
Django版本为3.2.12"——因果混乱：不是"低版本Django不
支持Python3"，而是3.6.4这个Python版本不能配太高版本
Django。表述要改成"选用对Python 3.6兼容的LTS版Django
3.2.12"。
雷点4【序号断档】3.2需求分析6条功能列表用(1)-(6)连续，
但4.1模块设计里"注册、登录模块"标题下无内容（正文
"注册、登录模块"五个字后面直接就是4.2），疑似内容
丢失；另5.2管理员功能模块里"图书借阅管理""图书归还
管理"两段没有编号小标题（其他功能都有），格式不统一。
雷点5【表结构与测试矛盾】图书信息表只有tushuzhuangtai
状态字段，没有库存数量字段；但6.2测试大谈"图书数量
减少/归零/为负"。要么给图书表加kucunshuliang字段，
要么改测试口径为状态判断，二者必须对齐。
雷点6【信息反馈表头像字段冗余】表4.6信息反馈表存了
avatarurl头像——留言表带头像字段是通用评论模板结构
（与美食课题评论表同源），本系统用户表也有头像，属
冗余存储，无伤大雅但可说明来源。
雷点7【参考文献跑题】[9]马卫《基于ASP.NET的博客系统的
设计与实现》（"基ASP.NE"还有错字，掉了T）——ASP.NET
博客系统与Python图书馆无关；[11]周仁平《教育技术学术
博客研究》同样跑题；[1]王兆媛缺编号[1]标号（格式
断档从[2]才开始有标号）。参考文献需补Django/图书馆
主题文献替换。
雷点8【PPT封面双空位+年份残留】P1"汇报人姓名：""汇报
时间："全空；P22"THE END!谢谢观看 2022"——2026年
答辩必须改掉"2022"。
雷点9【PPT结论页自贬风险】P20原样照搬论文结论，含
"只能算上一个雏形，所达到的标准只能令我自己勉强
满意"——答辩PPT主动暴露如此多不足且措辞自贬，
容易引导老师追问，建议改为"核心功能已完整实现，
个性化推荐等功能列入后续迭代"。
雷点10【元数据泄露】论文doc元数据：作者"实践教学管理
中心卜迟武"、最后修改人"泽鸿 李"、Company"番茄花园"
（番茄花园是知名盗版系统论坛名，说明Word可能是
番茄花园Ghost版Office装的）；PPT元数据最后修改人
也是"泽鸿 李"。提交前用"文件-信息-检查文档"清除。
雷点11【摘要与正文模块不一致】中文摘要功能列表是
"用户管理、图书管理、图书借阅、图书归还、图书入库、
信息反馈、系统管理"七模块，正文4.1的模块划分却是
"查询借阅模块/后台模块/管理员模块/注册登录模块"四大
块——两套划分口径并存，答辩讲模块时先声明口径：
"按角色分前台/后台，按功能分七大模块"。
雷点12【测试章节位置错乱】6.5小结段落末尾直接黏着
"结 论"标题（"……减少差错。结 论"连排），格式错误；
且第6章标题"6 系统测试"与6.1"软件测试的定义"之间
只讲定义没讲方法论（黑盒/动态测试在小结才出现），
结构建议调整：6.1定义→6.2方法→6.3-6.5用例。
================================================================
【八、知识延展】（资料之外，让自己答得比别人深）
================================================================
1. 图书馆系统行业演进（背景题加分素材）：
- 第一代：卡片目录+手工登记（论文背景里的60年代前）
- 第二代：单机C/S管理系统（90年代，MARC机读目录）
- 第三代：B/S WebOPAC在线检索（本系统所处层次）
- 第四代：RFID自助借还+移动图书馆App（参考文献[6]
提到RFID，可延伸：RFID标签替代条码，自助借还机
识读，盘点机器人巡架）
- 第五代：智慧图书馆（大数据选书、AI推荐、座位预约、
信用借阅芝麻分免押金）
2. MARC编目与中图法（专业加分点）：
真实图书馆用MARC21/CNMARC机读目录格式编目，分类用
《中国图书馆分类法》（中图法，如TP312=程序语言、
I247.5=当代长篇小说）。本系统的"图书分类"表只有
分类名字符串，可延伸"真实场景应加中图法分类号字段
clfhao，支持分类号排架检索"。
3. 逾期与预约的业务闭环（改进方向标配答案）：
- 逾期：Celery定时任务每天扫描yinghairiqi<今天且
未归还的记录→发站内通知/邮件；逾期罚金规则
（元/天）在配置表维护。
- 预约：预约表(id+图书id+用户id+排队序号)，书归还
入库后触发通知队首用户，保留N天不借则顺延。
- 续借：借阅记录加续借次数字段，最多续借2次每次
30天，有预约时禁续借。
4. 并发借阅的数据库层方案（Q5的深化）：
- 悲观锁：SELECT * FROM book WHERE id=x FOR UPDATE
（Django: Book.objects.select_for_update().get()）
- 乐观锁：版本号字段，UPDATE ... WHERE version=n，
影响行数=0则重试
- 原子UPDATE：UPDATE book SET stock=stock-1 WHERE
stock>0，天然防负库存。
5. Django权限体系（Admin后台安全话题）：
User模型自带is_staff/is_active/is_superuser三开关；
Group组+Permission权限点（add_book/change_book…）；
自定义权限用Meta的permissions。答辩问"管理员权限
怎么控制"时可展开。
6. 借阅数据做推荐（呼应英文摘要残留的"recommendation"）：
用户-图书借阅矩阵做ItemCF：同被借的书相似度高；
"借了A的人也借了B"；冷启动用图书分类+热度；
（clicknum/thumbsupnum）兜底。这样还能把英文摘要的；
"recommendation system"圆回来。
7. 分页的性能优化（数据量大时）：
Paginator深分页LIMIT 100000,6会慢，可改游标分页；
（WHERE id > last_id LIMIT 6）或延迟关联；
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)