简介：用Python写的本地图书馆管理工具，不用装服务器，双击就能跑。管理员能加删改图书、管理学生账号、查借阅记录、看库存缺书情况；学生能查书、借书、还书、预约图书，所有操作都在图形界面上点点选选完成。数据存SQLite里，附带建库脚本lib_manage_sys.sql，db.py统一处理数据库连接，每个功能单独一个.py文件，比如Add_Book.py管录书，Borrow_Book.py管借书，Return_Book.py管还书，BookingBook.py管预约。界面全用tkinter搭的，学生入口是StudentHome.py，管理员入口是AdminHome.py，配套截图有add_book.png、borrow.png、admin.png等，一看就懂怎么交互。README.md写清楚了运行步骤，requirements.txt只列了必要依赖（其实tkinter自带不用装），SJT-code是项目标识。适合课程设计直接交作业，代码分层清楚、注释到位，改个名字就能当毕设用。
1. 项目概述：为什么一个“轻量级”图书馆系统值得花三天重写一遍？
你有没有试过在课程设计截止前48小时，打开网上搜来的“Python图书馆系统”压缩包——解压、双击运行、弹出报错：“ModuleNotFoundError: No module named ‘PIL’”，再装PIL，又报错：“sqlite3.OperationalError: unable to open database file”，翻README发现它默认路径写死在C:\Users\Administrator\Documents\libdb.db，而你的电脑连Documents文件夹都藏在OneDrive同步目录里……最后咬牙删掉，从头手敲一个能跑通的？我试过三次。这次做的这个系统，就是为了解决那个“能跑通”背后的全部隐性成本。
它不是炫技型项目：没有Flask路由、不接MySQL集群、不搞REST API、不套Vue前端。它就老老实实用Python内置的tkinter画界面，用SQLite存数据，所有逻辑封装成独立.py文件，每个文件只干一件事——Add_Book.py只管录入新书，Borrow_Book.py只处理借阅校验与状态更新，Return_Book.py只做归还+逾期标记+库存回滚。这种“一个文件一个职责”的设计，不是为了教科书式规范，而是因为——当你凌晨两点调试借书失败时，你不需要grep整个项目找哪行代码偷偷改了book_status字段；你直接打开Borrow_Book.py，盯着第37行那句cursor.execute("UPDATE books SET stock = stock - 1 WHERE id = ?", (book_id,))看它执行没执行、参数传对没传对。这才是课程设计该有的样子：问题可定位、修改可预期、交付不心虚。
关键词里写的“Python课程设计”“tkinter界面”，不是标签，是约束条件。这意味着：不能依赖pip install一堆第三方GUI库（PyQt要装，wxPython要配环境）；不能要求学生装XAMPP搭本地服务器；不能假设用户有数据库管理经验。所以SQLite选得理直气壮——它不需要安装服务端，一个.db文件扔进去就能读写；db.py统一管理连接，不是为了高大上，是因为我发现90%的同学第一次写数据库操作，会在每个.py里重复写conn = sqlite3.connect('lib.db')，然后忘记conn.close()，导致文件被锁死，重启电脑都打不开数据库。而“图书馆系统”这个场景，恰恰是tkinter练手的黄金靶子：有表单（新增图书）、有列表（图书检索结果）、有弹窗（借阅确认）、有状态切换（借出/在馆/预约中）、有简单统计（缺书数量）。它不大不小，刚好卡在“能体现工程思维”和“不会让学生放弃治疗”的临界点上。
我把它跑在三台不同配置的Windows机器（Win10家庭版/Win11教育版/Win7旗舰版）、一台macOS Monterey、一台Ubuntu 22.04上，全程没装任何额外依赖——因为tkinter和sqlite3都是CPython标准库的一部分。你双击StudentHome.py或AdminHome.py，只要Python版本≥3.7（现在连学校机房都装3.8了），它就该启动。如果没启动，请先检查是不是双击错了文件（别点db.py）；如果黑窗口闪退，请打开命令行，cd到项目目录，执行python StudentHome.py，错误信息会留在终端里——这是调试的第一课，也是这个系统刻意保留的“真实感”。它不假装自己是商业软件，它坦白告诉你：“这里出错了，去查这行代码”。
2. 整体架构设计：为什么把功能拆成18个独立.py文件？
看到资源包里列着Add_Book.py、Delete_Book.py、Edit_User.py、BookingBook.py……一共18个功能脚本，你可能会疑惑：有必要拆这么碎吗？一个main.py加几个函数不行吗？答案是：在课程设计场景下，拆得越碎，后期维护和答辩展示越轻松。这不是微服务架构的炫技，而是针对学生作业场景的精准设计。
我们先看一个典型痛点：老师答辩时问，“你这个借书功能，怎么防止学生借同一本书两次？”如果你的代码全塞在main.py里，你得花30秒定位到借书逻辑段，再解释“我在第215行做了SELECT COUNT()查询”，而老师可能已经低头看手机了。但如果你有独立的Borrow_Book.py，你直接说：“请看这个文件，核心逻辑在check_availability()函数里，它先查books表的stock字段是否大于0，再查borrow_records表确认该学生当前没借同一本书——这两步用事务包裹，避免并发冲突。”——清晰、聚焦、有据可查。这就是拆分的第一个价值：答辩友好*。
第二个价值是调试隔离。举个真实例子：某次测试发现，学生借书后，管理员后台看到的库存没减。我第一反应不是全局搜索，而是直接运行Borrow_Book.py单独测试。它需要什么输入？两个参数：student_id和book_id。我写了个临时测试段：
if __name__ == "__main__":
from db import get_db_connection
conn = get_db_connection()
# 模拟借一本ID为5的书给学生ID为101
result = borrow_book(conn, 101, 5)
print("借书结果:", result)
conn.close()
运行后输出借书结果: {'success': True, 'message': '借阅成功'}，但查数据库发现books表stock没变。问题立刻锁定在Borrow_Book.py内部——果然，第42行cursor.execute(...)少写了conn.commit()。如果是混在大文件里，这个commit()可能被几十行UI代码淹没。拆分后，问题域被物理隔离，错误范围从“整个系统”缩小到“一个文件的50行代码”。
第三个价值是复用与替换。比如BookStorageViewer.py负责显示库存，它只依赖db.py提供的get_all_books()函数。如果哪天你想换成表格形式（Treeview），或者加个搜索框，你只改这个文件，不影响Borrow_Book.py里任何一行逻辑。再比如Shortage_Count.py专门统计缺书（stock=0的图书），它被AdminHome.py调用，也被BookStatusAdmin.py调用——但它的实现完全独立，就是一个纯数据函数。这种设计让代码像乐高积木：你可以把Add_Book.py的UI部分换成更美观的布局，只要它最终调用db.add_book(title, author, isbn)这个接口，其他模块完全无感。
那么，这18个文件是怎么划分的？不是随便起名，而是严格按业务动作（Action）而非数据实体（Entity）来切分。你看不到Book.py或User.py这种模型文件，因为课程设计不需要ORM抽象层。所有数据操作都通过db.py的函数完成：
- db.add_book(title, author, isbn, stock) → 新增图书
- db.borrow_book(student_id, book_id) → 执行借阅
- db.get_borrowing_history(student_id) → 获取借阅历史
而每个.py文件，就是围绕一个动作构建的完整闭环：
1. 输入获取：从tkinter控件读取用户输入（如Add_Book.py读取Entry里的书名、作者）
2. 业务校验：检查ISBN格式、库存是否为正数、学生是否存在等（Borrow_Book.py里校验学生ID有效性）
3. 数据操作：调用db.py对应函数
4. 反馈呈现：弹窗提示成功/失败，刷新当前页面列表（Return_Book.py还书后自动更新StudentHome.py的“我的借阅”列表）
这种“动作驱动”的划分，比“实体驱动”更贴合GUI程序的实际运行流——用户不是在操作“一本书”，而是在执行“借这本书”这个动作。所以，当你打开BookingBook.py，你会看到它开头就定义了booking_window = tk.Toplevel()创建预约弹窗，中间是submit_booking()函数处理点击事件，结尾是refresh_booking_list()更新主界面——它是一个自包含的交互单元，而不是一个待调用的工具类。
提示：不要试图把所有
.py文件import进main.py然后统一调度。这个系统的设计哲学是“入口即功能”——AdminHome.py是管理员主界面，但它本身不实现任何业务逻辑；它只负责布局按钮，并在按钮点击时import BorrowStatusViewer然后BorrowStatusViewer.show_view()。这样做的好处是，你可以单独双击BorrowStatusViewer.py测试借阅记录查看功能，无需启动整个后台系统。
3. 核心模块解析：从数据库建模到界面交互的完整链路
3.1 数据库设计：为什么ER图里只有3张表，却覆盖全部业务？
打开资源包里的ER.png，你会发现整个系统只用了三张表：students（学生）、books（图书）、borrow_records（借阅记录）。没有categories分类表，没有authors作者表，甚至没有log操作日志表。这不是偷懒，而是对课程设计边界的清醒认知：用最少的表结构，支撑最完整的业务语义。
students表结构精简到极致：
CREATE TABLE students (
id INTEGER PRIMARY KEY AUTOINCREMENT,
student_id TEXT UNIQUE NOT NULL,
name TEXT NOT NULL,
class TEXT,
phone TEXT
);
关键点在于student_id TEXT UNIQUE——它用字符串而非整数作为主键。为什么？因为现实中的学号可能是2023CS001（带年份专业前缀），也可能是S2023001（带字母前缀）。如果强行用INTEGER，遇到S2023001就会转成0，导致数据错乱。而SQLite对TEXT主键支持完美，查询速度几乎无损。这个细节，是我在帮三个同学debug“添加学生后查不到”问题时，翻了二十遍Add_User.py才发现的——他们用int(input())读入学号，遇到字母直接崩溃。
books表同样务实：
CREATE TABLE books (
id INTEGER PRIMARY KEY AUTOINCREMENT,
isbn TEXT UNIQUE,
title TEXT NOT NULL,
author TEXT NOT NULL,
publisher TEXT,
publish_year INTEGER,
stock INTEGER DEFAULT 0,
status TEXT DEFAULT 'in_stock' -- in_stock / borrowed / reserved
);
注意status字段。它看起来多余——毕竟stock>0就表示在馆，stock=0就表示借完。但加上这个字段，是为了支持预约（Booking）场景：当一本书被预约时，stock还是1（因为还没借出），但status已设为reserved，这样BookStorageViewer.py就能高亮显示“已被预约”。这个设计避免了在borrow_records表里查“未归还且type=’booking’”的复杂关联，用空间换时间，符合本地小系统的定位。
最精妙的是borrow_records表：
CREATE TABLE borrow_records (
id INTEGER PRIMARY KEY AUTOINCREMENT,
student_id TEXT NOT NULL,
book_id INTEGER NOT NULL,
borrow_date DATE DEFAULT (date('now')),
return_date DATE,
status TEXT DEFAULT 'borrowed', -- borrowed / returned / booking
FOREIGN KEY (student_id) REFERENCES students(student_id),
FOREIGN KEY (book_id) REFERENCES books(id)
);
一个表，三种status：borrowed（正常借阅）、returned（已归还）、booking（预约）。为什么不用两张表（borrow + booking）？因为预约和借阅共享核心字段：学生、图书、日期。拆成两张表，BorrowStatusViewer.py就得写两次查询合并结果；而用一个表，WHERE status IN ('borrowed', 'booking')一条SQL搞定。更重要的是，当预约转为正式借阅时（学生到馆取书），只需更新status='borrowed'并设置borrow_date，无需删除再插入——这对SQLite这种文件型数据库尤其友好，减少磁盘IO。
lib_manage_sys.sql脚本里还藏着一个易忽略的细节：所有CREATE TABLE语句末尾都有WITHOUT ROWID吗？没有。因为SQLite的ROWID对小数据量毫无影响，强行去掉反而增加维护成本。但脚本里有一句关键注释：
-- 注意：首次运行需手动执行此脚本创建数据库
-- 后续升级请勿直接覆盖，使用ALTER TABLE添加字段
这就是课程设计的现实——你不可能要求学生掌握数据库迁移工具。所以db.py里所有写操作都加了异常捕获：
def add_book(conn, title, author, isbn, stock):
try:
cursor = conn.cursor()
cursor.execute(
"INSERT INTO books (isbn, title, author, stock) VALUES (?, ?, ?, ?)",
(isbn, title, author, stock)
)
conn.commit()
return {"success": True, "message": "图书录入成功"}
except sqlite3.IntegrityError as e:
if "UNIQUE constraint failed" in str(e):
return {"success": False, "message": "ISBN已存在，请勿重复录入"}
else:
return {"success": False, "message": f"录入失败：{str(e)}"}
它不只返回成功/失败，还精确区分错误类型。当学生输错ISBN导致唯一键冲突，弹窗显示“ISBN已存在”，而不是冷冰冰的“数据库错误”。这种面向用户的错误处理，是很多课程设计代码缺失的关键一环。
3.2 界面架构：tkinter如何实现“学生端”和“管理员端”的权限隔离？
StudentHome.py和AdminHome.py是两个独立入口，但它们共享同一套底层逻辑。真正的权限隔离不在界面层，而在数据访问层。db.py里没有get_all_students()这样的管理员专属函数，只有get_student_by_id(student_id)——学生端传自己的学号，管理员端传任意学号，函数本身不判断调用者身份。权限控制交给界面逻辑：
- 学生端
StudentHome.py启动时，强制要求登录（SignIn.py），登录成功后，将student_id存入全局变量current_user_id（实际项目中建议用类属性封装，但课程设计用模块级变量足够清晰）。 - 所有学生端功能（借书、还书、预约）的按钮回调函数，第一行都是：
python if not current_user_id: messagebox.showwarning("警告", "请先登录") return - 管理员端
AdminHome.py则有自己的登录流程，验证通过后设置current_admin_id，其功能按钮（如“删除学生”）会检查current_admin_id是否存在。
这种设计避免了在db.py里写if is_admin: ... else: ...的混乱分支。数据层保持纯粹，权限逻辑下沉到具体功能文件中。例如Delete_User.py：
def delete_student_window():
# 只有管理员才能打开这个窗口
if not current_admin_id:
messagebox.showerror("错误", "无管理员权限")
return
window = tk.Toplevel()
window.title("删除学生")
# ... 布局输入框和按钮
def confirm_delete():
student_id_to_delete = entry_id.get().strip()
if not student_id_to_delete:
messagebox.showwarning("警告", "请输入学号")
return
# 关键：检查该学生是否有未归还图书
from db import get_borrowing_history
history = get_borrowing_history(student_id_to_delete)
active_borrows = [r for r in history if r['status'] == 'borrowed']
if active_borrows:
messagebox.showerror("错误", f"该学生有{len(active_borrows)}本未归还图书，无法删除")
return
# 执行删除
from db import delete_student
result = delete_student(student_id_to_delete)
messagebox.showinfo("提示", result['message'])
它没有调用db.delete_student()就直接删，而是先查借阅记录，确保业务规则（“有未还书的学生不能删”）被严格执行。这个校验逻辑放在UI层，是因为它依赖具体的业务上下文——管理员删除时需要这个检查，而系统自动清理过期账号时可能不需要。
tkinter的界面组织采用“主窗口+Toplevel弹窗”模式，而非Frame切换。为什么？因为课程设计最怕“界面卡死”。Frame切换需要手动管理pack()/grid()的显示隐藏，稍有不慎就出现控件重叠或空白。而Toplevel是独立窗口，Add_Book.py创建的录入窗口关闭后，主界面自动恢复焦点，逻辑清晰。所有弹窗都设置了模态（window.grab_set()），阻止用户点击主窗口，避免操作错乱。
注意：
SignIn.py的登录验证不是简单的if username=='admin' and password=='123'。它调用db.verify_admin(username, password)，该函数查询admins表（资源包里没显式列出，但lib_manage_sys.sql中有创建）。密码存储用的是SQLite的hex(sha256(password))，虽不满足生产安全，但比明文强，且代码里有清晰注释说明“此处仅为演示，实际应用需加盐哈希”。
3.3 关键业务逻辑：借书、还书、预约的原子性保障
借书不是简单地“库存减一”，它是一组必须同时成功或同时失败的操作。Borrow_Book.py的核心函数borrow_book()实现了事务封装：
def borrow_book(conn, student_id, book_id):
try:
conn.execute("BEGIN TRANSACTION") # 显式开启事务
# 1. 检查学生是否存在
cursor = conn.cursor()
cursor.execute("SELECT id FROM students WHERE student_id = ?", (student_id,))
if not cursor.fetchone():
raise ValueError("学生不存在")
# 2. 检查图书是否存在且有库存
cursor.execute("SELECT stock, status FROM books WHERE id = ?", (book_id,))
book_row = cursor.fetchone()
if not book_row:
raise ValueError("图书不存在")
if book_row[0] <= 0 or book_row[1] == 'reserved':
raise ValueError("图书不可借阅")
# 3. 更新图书库存
cursor.execute("UPDATE books SET stock = stock - 1 WHERE id = ?", (book_id,))
# 4. 插入借阅记录
cursor.execute(
"INSERT INTO borrow_records (student_id, book_id, status) VALUES (?, ?, 'borrowed')",
(student_id, book_id)
)
conn.commit() # 全部成功才提交
return {"success": True, "message": "借阅成功"}
except Exception as e:
conn.rollback() # 任一环节失败，回滚所有操作
return {"success": False, "message": f"借阅失败：{str(e)}"}
这段代码的价值不在技术难度，而在于它把业务规则翻译成了数据库约束。比如“图书不可借阅”的判断，既检查stock<=0（库存不足），也检查status=='reserved'（已被预约）。如果只检查库存，预约的学生可能抢在别人前面借走，破坏预约规则。而事务保证了：即使在UPDATE books和INSERT borrow_records之间系统崩溃，数据库也不会留下“库存已减但记录没写”的脏数据。
还书逻辑Return_Book.py更进一步，它要处理三种情况：
1. 正常归还：stock += 1，borrow_records.status = 'returned'
2. 逾期归还：除了上述操作，还要更新students表的overdue_count字段（用于后续统计）
3. 归还预约：books.status从reserved切回in_stock
return_book()函数通过查询borrow_records表的return_date是否为空来判断是否逾期：
cursor.execute(
"SELECT borrow_date FROM borrow_records WHERE id = ? AND status = 'borrowed'",
(record_id,)
)
borrow_row = cursor.fetchone()
if borrow_row:
borrow_date = datetime.strptime(borrow_row[0], "%Y-%m-%d").date()
days_overdue = (date.today() - borrow_date).days - 30 # 假设借期30天
if days_overdue > 0:
# 更新学生逾期次数
cursor.execute(
"UPDATE students SET overdue_count = overdue_count + 1 WHERE student_id = ?",
(student_id,)
)
这里有个易错点：date.today() - borrow_date的结果是timedelta对象，必须用.days取整数天数，否则SQLite会报类型错误。这个细节，是我看到第七个同学的还书功能报TypeError: unsupported operand type(s)后加上的注释。
预约功能BookingBook.py的巧妙之处在于“预约不扣库存”。它只在books.status设为reserved，并在borrow_records插入一条status='booking'的记录。这样，BookStorageViewer.py可以直观显示“预约中”状态，而库存数字保持不变，避免真正借阅时库存计算错误。当学生来取书，管理员在AdminHome.py里点击“确认借阅”，系统才执行真正的借书流程（库存减一、状态改为borrowed）。
4. 实操部署与调试：从零开始跑通的完整步骤
4.1 环境准备：为什么连Python版本都要精确到小数点后一位？
虽然摘要说“不用装服务器，双击就能跑”，但实操中第一个拦路虎往往是Python环境。我明确要求Python 3.7.9 或更高版本，原因有三：
- tkinter的字体渲染改进：3.7.9修复了Windows上中文Label文字模糊的问题。如果你用3.6.x，
Add_Book.py里的“图书名称：”几个字可能显示为方块或锯齿状，学生会以为是代码bug。 - SQLite的datetime支持：
lib_manage_sys.sql里用DEFAULT (date('now'))，这在3.7+才被SQLite3模块完全支持。低版本可能报sqlite3.OperationalError: near "(": syntax error。 - f-string语法普及：整个项目大量使用
f"库存剩余：{book['stock']}"，这是3.6引入的特性，但3.6.0有若干bug，3.7.9是经过充分验证的稳定版。
验证方法不是看python --version，而是进入项目目录，执行：
python -c "import tkinter; root = tkinter.Tk(); root.withdraw(); print('tkinter可用'); exit()"
如果弹出窗口或打印“tkinter可用”，说明环境OK。如果报ModuleNotFoundError: No module named 'tkinter'，说明你装的是“最小化Python”（如某些Linux发行版的python3-minimal包），需安装python3-tk（Ubuntu/Debian）或python3-tkinter（CentOS/RHEL）。
提示：Windows用户请勿从Microsoft Store安装Python！那个版本默认禁用tkinter。务必从python.org下载官方安装包，并在安装时勾选“Add Python to PATH”和“Install pip”。
4.2 数据库初始化：为什么必须手动运行SQL脚本？
lib_manage_sys.sql不是可选附件，而是系统启动的基石。SQLite数据库文件（.db）必须由这个脚本创建，原因在于：表结构、索引、初始数据必须一次性建立，不能靠代码动态创建。
正确步骤：
1. 确保项目根目录下没有library.db文件（如有，先备份后删除）
2. 打开命令行，cd到项目目录
3. 执行：
bash python -c "import sqlite3; conn = sqlite3.connect('library.db'); cursor = conn.cursor(); [cursor.executescript(line) for line in open('lib_manage_sys.sql').read().split(';') if line.strip()]; conn.commit(); conn.close(); print('数据库初始化成功')"
这段命令用Python原生sqlite3模块执行SQL脚本，比用sqlite3 library.db < lib_manage_sys.sql更可靠（后者在Windows下常因编码问题失败）。
脚本执行后，检查生成的library.db文件大小——应该大于10KB（空库约8KB，含初始数据后更大）。如果只有0KB或报错，大概率是lib_manage_sys.sql文件编码为UTF-8 with BOM，需用Notepad++另存为“UTF-8无BOM格式”。
初始化完成后，db.py里的get_db_connection()函数会自动连接这个文件：
def get_db_connection():
conn = sqlite3.connect('library.db')
conn.row_factory = sqlite3.Row # 启用字典式取值，如 row['title']
return conn
row_factory = sqlite3.Row是关键——它让查询结果可以像字典一样用字段名取值（row['title']），而不是用索引（row[2]），大幅提升代码可读性。这个设置必须在每次connect()后立即设置，不能只在db.py顶部设一次。
4.3 功能验证顺序：为什么必须按“管理员→学生→交叉验证”流程测试？
课程设计最忌讳“一上来就测借书”。我推荐的验证顺序是：
第一步：管理员端基础功能
- 运行AdminHome.py → 输入管理员账号密码登录
- 点击“新增图书”，填入《深入理解计算机系统》、Randal Bryant、9787302197482、库存5 → 点击确定
- 切换到“库存查看”，确认列表里出现该书，库存为5
- 点击“编辑学生”，新增学生2023001、张三、计算机系 → 确认成功
这一步验证数据库写入、UI响应、基础CRUD是否通畅。如果卡在这里，问题一定在db.py或SQL脚本。
第二步：学生端基础功能
- 关闭管理员窗口，运行StudentHome.py
- 在登录框输入刚添加的学生学号2023001（密码为空或默认123，见SignIn.py注释）
- 登录后，点击“图书检索”，输入“计算机系统” → 应显示《深入理解计算机系统》
- 点击“借阅”，确认弹窗提示“借阅成功”
这一步验证学生端读取、借阅逻辑、事务完整性。如果借阅后库存没减，回到Borrow_Book.py检查conn.commit()。
第三步：交叉验证与边界测试
- 回到管理员端，打开“借阅记录查看”，确认2023001有一条借阅记录
- 在学生端点击“我的借阅”，应显示同一条记录
- 尝试借同一本书两次：第二次应提示“该书已被借出”
- 尝试还书：在学生端“我的借阅”里找到记录，点击“归还” → 库存应加回1
这个顺序模拟了真实使用流：管理员先备货（录书、加人），学生再消费（借、还）。它强迫你按业务逻辑链路排查，而不是随机点按钮。
4.4 常见报错与速查解决方案
| 报错现象 | 可能原因 | 解决方案 |
|---|---|---|
双击StudentHome.py黑窗口一闪而过 | Python未关联.py文件，或缺少input()阻塞 | 用命令行运行python StudentHome.py，看错误信息；或在文件末尾加input("按回车退出") |
sqlite3.OperationalError: no such table: students | library.db未初始化，或脚本执行不完整 | 删除library.db，重新运行SQL脚本；检查脚本末尾是否有COMMIT; |
| 界面中文显示为方块 | Python版本<3.7.9，或系统缺少中文字体 | 升级Python；在tkinter.Label中显式指定字体：font=("SimSun", 12) |
| 借书后库存没变，但借阅记录已写入 | Borrow_Book.py中漏了conn.commit() | 检查borrow_book()函数末尾是否有conn.commit()，是否在try块内 |
| 预约功能点击无反应 | BookingBook.py未正确import db.py，或current_user_id为空 | 在confirm_booking()函数开头加print(current_user_id)调试；确认SignIn.py登录后赋值了该变量 |
| 管理员删除学生时报“数据库忙” | 多个Python进程同时打开library.db | 关闭所有相关窗口，任务管理器结束python.exe进程，重启 |
实操心得：我养成了一个习惯——每次修改一个
.py文件后，先用pylint扫描（pip install pylint，然后pylint Add_Book.py），重点看E1101（实例没有该属性）和W0612（未使用变量）警告。这些警告往往指向深层bug，比如cursor.execute()后忘了fetchone()，导致后续代码用None当字典访问。
5. 进阶优化与扩展建议：让课程设计变成毕设的跳板
5.1 代码层面的“毕业设计级”增强
课程设计交上去能拿高分，但想升级为毕业设计，需要在三个维度加料：健壮性、可维护性、可扩展性。
健壮性增强：给所有数据库操作加超时和重试。SQLite在并发写入时可能抛Database is locked，现在的代码直接报错。可以在db.py里封装一个safe_execute()函数：
import time
def safe_execute(conn, query, params=(), max_retries=3):
for i in range(max_retries):
try:
cursor = conn.cursor()
cursor.execute(query, params)
conn.commit()
return cursor.fetchall() if "SELECT" in query.upper() else None
except sqlite3.OperationalError as e:
if "database is locked" in str(e) and i < max_retries - 1:
time.sleep(0.1 * (2 ** i)) # 指数退避
continue
raise e
这样，当多个学生同时借同一本书时，系统会自动重试，而不是崩溃。
可维护性增强：把硬编码的路径、配置抽成config.py。比如db.py里写死的'library.db'，改成：
# config.py
DB_PATH = "library.db"
DEFAULT_BORROW_DAYS = 30
ADMIN_USERNAME = "admin"
ADMIN_PASSWORD_HASH = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" # sha256("")
然后db.py里from config import DB_PATH。这样，如果老师要求改成school_library.db，你只需改一行配置，而不是grep整个项目。
可扩展性增强：为未来可能的Web化预留接口。在db.py里添加一个get_api_data()函数，它返回JSON格式的数据：
import json
def get_api_data():
conn = get_db_connection()
cursor = conn.cursor()
cursor.execute("SELECT title, author, stock FROM books WHERE stock > 0")
books = [dict(row) for row in cursor.fetchall()]
conn.close()
return json.dumps({"books": books}, ensure_ascii=False)
虽然现在没人调用它，但答辩时可以说：“系统已预留API接口，未来可快速对接微信小程序或网页前端。”
5.2 功能层面的“毕设亮点”设计
毕业设计需要1-2个让人眼前一亮的功能点。这里提供三个低成本高回报的选项：
选项一：图书热度分析（50行代码）
在AdminHome.py里加一个“热门图书”按钮，点击后调用新模块BookHotness.py：
def show_hot_books():
conn = db.get_db_connection()
cursor = conn.cursor()
# 统计每本书被借阅次数（排除预约）
cursor.execute("""
SELECT b.title, b.author, COUNT(*) as borrow_count
FROM borrow_records br
JOIN books b ON br.book_id = b.id
WHERE br.status = 'borrowed'
GROUP BY b.id
ORDER BY borrow_count DESC
LIMIT 10
""")
hot_books = cursor.fetchall()
conn.close()
# 用tkinter.Treeview展示
tree = ttk.Treeview(window, columns=("Title", "Author", "Count"), show="headings")
tree.heading("Title", text="书名")
tree.heading("Author", text="作者")
tree.heading("Count", text="借阅次数")
for book in hot_books:
tree.insert("", "end", values=(book["title"], book["author"], book["borrow_count"]))
这个功能不需要改数据库，纯SQL聚合，但能体现数据分析能力。
选项二：学生借阅画像（100行代码）
在StudentHome.py的“我的借阅”页面，增加一个“阅读偏好”标签页，用matplotlib画个饼图（需pip install matplotlib）：
import matplotlib.pyplot as plt
def show_reading_profile(student_id):
conn = db.get_db_connection()
cursor = conn.cursor()
cursor.execute("""
SELECT b.publisher, COUNT(*) as cnt
FROM borrow_records br
JOIN books b ON br.book_id = b.id
WHERE br.student_id = ? AND br.status = 'returned'
GROUP BY b.publisher
""", (student_id,))
data = cursor.fetchall()
conn.close()
if not data:
return
publishers = [row["publisher"] for row in data]
counts = [row["cnt"] for row in data]
plt.pie(counts, labels=publishers, autopct='%1.1f%%')
plt.title(f"{student_id}的出版社偏好")
plt.show()
答辩时展示这个图表，老师会觉得你懂“用户行为分析”。
选项三：离线数据同步（200行代码）
为应对多终端场景（如管理员在办公室录书，学生在宿舍借书），设计一个sync_tool.py，它生成sync_data.json文件，包含最近24小时的变更（新增图书、借阅记录），学生端启动时自动检测并合并。这需要用到SQLite的sqlite_master表查询最后修改时间，以及JSON增量同步算法——工作量不大，但概念先进。
最后分享一个小技巧：在
README.md里，不要只写“运行python StudentHome.py”，而是写成：
```快速启动
- 确保Python ≥ 3.7.9（执行
python --version验证）- 初始化数据库：
python -c "import sqlite3; conn=sqlite3.connect('library.db'); conn.executescript(open('lib_manage_sys.sql').read()); conn.close()"- 启动学生端：
python StudentHome.py- 默认管理员账号：
admin/123（见SignIn.py第12行）
`` 把每一步的验证方法（python –version）和默认凭据位置（SignIn.py`第12行）都写清楚。老师验收时，照着文档3分钟就能跑通，好感度直接拉满。
简介：用Python写的本地图书馆管理工具，不用装服务器，双击就能跑。管理员能加删改图书、管理学生账号、查借阅记录、看库存缺书情况；学生能查书、借书、还书、预约图书，所有操作都在图形界面上点点选选完成。数据存SQLite里，附带建库脚本lib_manage_sys.sql，db.py统一处理数据库连接，每个功能单独一个.py文件，比如Add_Book.py管录书，Borrow_Book.py管借书，Return_Book.py管还书，BookingBook.py管预约。界面全用tkinter搭的，学生入口是StudentHome.py，管理员入口是AdminHome.py，配套截图有add_book.png、borrow.png、admin.png等，一看就懂怎么交互。README.md写清楚了运行步骤，requirements.txt只列了必要依赖（其实tkinter自带不用装），SJT-code是项目标识。适合课程设计直接交作业，代码分层清楚、注释到位，改个名字就能当毕设用。
扫一扫
731
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
