我至今记得 Day 21 当天的感受。前二十天把 Python 基础语法过了一遍列表、字典、字符串方法、while 循环、函数定义……每节课都觉得听懂了关上教程一合上笔记脑子里的知识全变成了散装零件。Day 21 的题目就一句话用 Python 写一个图书管理系统。它看起来一点都不时髦不做爬虫、不碰量化但它几乎覆盖了基础篇所有语法点而且写完之后我才真正理解“会语法”和“会写程序”之间隔着多远。这篇内容完整记录了那天的设计思路、代码实现和踩坑过程。如果你刚学完 Python 基础想找项目练手可以直接照着这个思路写一遍如果你已经写了但出了各种诡异问题我后面单独整理的三个 BUG 排查实录应该能帮你少走不少弯路。1. 为什么基础篇的收官项目必须选“图书管理系统”1.1 学完基础语法之后最缺的是“把知识串起来”的练习学 Python 前二十天的体验很像拿到一堆上好的零件有列表、字典、循环、条件判断、函数但没人告诉我这些零件应该怎么拼成一台能转的机器。单独练列表切片会了单独练函数参数会了可一打开空白编辑器脑子也一片空白。图书管理系统好在它是一个“综合应用题”。它要求你同时处理用户输入、数据结构设计、流程控制、函数封装、文件读写、异常处理。难度刚好卡在不依赖第三方库的前提下而且任何一个环节写坏了程序都能直观地表现出问题——要么崩溃要么数据错乱要么退出后什么都存不住。这种失败反馈非常直接比做一百道语法题都有用。1.2 图书管理系统对应的基础知识点清单我把它覆盖的知识点全部列了一张表做完之后回头一看基础篇里那些孤立的知识点几乎全被用上了而且是用在合理的业务场景里不是硬凑系统功能用到的 Python 基础内容图书数据的组织字典嵌套列表books [{id: 1, ...}]菜单循环while Trueif/elif分支用户输入input() 字符串去空格 类型转换添加、删除图书列表的append()、remove()、按索引修改查询图书for遍历 if匹配 lower()统一大小写借书/还书字典键值修改、字段状态流转数据保存/读取文件读写 json模块的dump/load功能拆分函数定义、参数与返回值、global变量异常保护try / except处理输入错误和文件损坏很多人问为什么不用 MySQL 或者 SQLite 做存储。我的理由很简单Day 21 的时候你才刚学完基础语法压根没有数据库概念强行上数据库会把注意力从“熟练基础语法”转到“学习数据库环境配置”上两个目标混在一起哪个都学不踏实。而 JSON 文件天然就是 Python 字典的文本形式读写都不用考虑数据库连接、表结构这些额外负担。等后面学到 SQL 再迁移还能顺便体会一下“同一业务两种持久化方案”的差异。1.3 为什么不选爬虫、量化那些热门方向热搜上关于 Python 的高频词爬虫、量化交易策略代码、各种花式小游戏常年霸榜。但它们的共同问题是上手太早就要去处理网络请求、数据处理、第三方库兼容性这类超出基础篇范围的东西。一旦爬虫请求报错、量化回测数据格式不对你根本不知道是基础语法问题还是环境问题挫败感直接把人劝退。图书管理系统没有网络、没有图形界面、没有外部依赖它的复杂度天花板刚好卡在基础篇的边界线上往下能让你跑起来往上还有足够的进化空间——后面加类、加界面、加数据库循序渐进这才是一个合理的学习阶梯。2. 动手前先定三个关键决策不然后面全是返工这个项目真正让我学到的不是语法本身而是动手前必须先做设计决策。我当时闷头写了两小时结果因为存储方案没想清楚推倒重来了一遍。现在把决策过程完整说清楚。2.1 存储方案为什么 JSON 文件打败了 TXT 和 SQLite写图书管理系统数据必须持久化不然程序一退出辛辛苦苦录入的书全没影了。我对比过三种方案TXT 文本每一行存一本书字段用逗号分隔。看着简单但图书标题里一旦出现逗号或书名号读取的时候就会把字段切错数据直接错位。CSV 文件比手写 TXT 好一点但依然要考虑转义而且 Python 基础篇还没系统地讲csv模块。JSON 文件json.dump()把整个books列表原样写进文件json.load()再原样读回来。字典转字符串、字符串转字典全程不需要关心字段分隔规则。JSON 本身就是给 Python 这类语言做数据交换的格式中文支持靠ensure_asciiFalse也很好解决。我的结论很明确只要基础篇没讲数据库JSON 就是最合理的存储选择没有之一。它把你从“解析文本格式”这种低价值劳动里解放出来把精力留给核心业务逻辑。2.2 数据结构先定义清楚“一本书”长什么样数据结构的第一个版本我踩了坑。我当时图省事用三个平行列表分别存书名、作者、状态结果添加一本书要往三个列表各append()一次删除一本书要同步删除三处忘了任何一个列表数据就全乱了。第二次改成字典嵌套列表这个问题彻底消失books [ { id: 1, title: Python编程从入门到实践, author: Eric Matthes, year: 2016, status: 可借 }, { id: 2, title: 流畅的Python, author: Luciano Ramalho, year: 2017, status: 借出, borrower: 张三 } ]一个字典就是一本完整的书字段见名知意status负责可控状态borrower记录借出时是谁拿走的。所有增删改查只要围着books这一个列表转数据的一致性天然就有了保障。这种结构对新手最友好books[0]是第一本书books[0][title]是第一本的书名下一级数据永远能顺着路径摸到。2.3 代码组织全部堆在main()里还是拆成函数一开始我的写法是全部逻辑平铺在while True循环里菜单分支里直接塞增删改查代码。写了大概 150 行以后发现一个问题想加一个“查询后直接修改”的功能光在菜单分支里找对应代码就得翻半天。后来我把它拆成一个个独立函数add_book()只管添加delete_book()只管删除main()只保留菜单分发逻辑。每个函数只做一件事参数和返回值清清楚楚。可能有人问为什么不直接用面向对象、写一个Library类我的想法是基础篇阶段你对类的理解还不深强行用类会把问题的重心从“熟练语法”变成“理解类的封装与实例化”对 Day 21 来说目标错位了。先用函数把功能跑通等后续升级到面向对象时再重构。函数版的每个函数体和类方法体几乎一模一样到时候你会有一种“原来类就是把散装函数收编成组”的通透感。3. 核心功能逐段实现先跑通再优化这一部分是完整可跑的代码走读我按实际书写顺序分成主循环、添加图书、查找联动三块来讲每一段都会说明我为什么这么写。3.1 主循环为什么菜单编号用字符串比较不做int()转换程序入口长这样import os import json DATA_FILE books.json books [] def show_menu(): print( * 40) print(图书管理系统) print(1. 添加图书) print(2. 删除图书) print(3. 修改图书) print(4. 查询图书) print(5. 借书) print(6. 还书) print(7. 显示所有图书) print(8. 退出程序) print( * 40) def main(): load_data() while True: show_menu() choice input(请输入操作编号).strip() if choice 1: add_book() elif choice 2: delete_book() elif choice 3: modify_book() elif choice 4: search_book() elif choice 5: borrow_book() elif choice 6: return_book() elif choice 7: show_all_books() elif choice 8: save_data() print(数据已保存感谢使用图书管理系统) break else: print(无效输入请重新输入) if __name__ __main__: main()注意input()返回的是字符串所以我直接用字符串1、2去比较没有转成int。很多新手习惯写choice int(input(...))这会导致用户手滑输入abc时程序直接崩溃。用字符串比较就完全不用考虑这个分支——反正菜单编号 1 到 8 用字符串比较也是精确匹配。这个细节虽小但能帮你少写一个try/except。3.2 添加图书图书 ID 为什么不能写成len(books) 1添加图书是整个系统第一个真正的业务功能代码如下def add_book(): title input(请输入书名).strip() author input(请输入作者).strip() if not title or not author: print(书名和作者不能为空) return # 生成唯一ID new_id max([b[id] for b in books], default0) 1 year_str input(请输入出版年份直接回车跳过).strip() year 0 if year_str: try: year int(year_str) except ValueError: print(年份不是数字已按0处理) books.append({ id: new_id, title: title, author: author, year: year, status: 可借 }) print(f添加成功图书编号{new_id})这里最容易被忽略的是new_id的生成逻辑。我第一次写的是new_id len(books) 1看起来没毛病但你删掉三本书之后再添加len(books)变小了新书的 ID 就会和之前某本已被删掉的书重复。在图书管理这种业务里ID 是唯一标识一旦重复后面借书、还书时按 ID 查找就会定位到错误的数据。max([b[id] for b in books], default0) 1的意思是把所有现有书籍的 ID 取出来求最大值再加一。删掉的书 ID 不参与计算所以新 ID 永远不会重复而且只比当前最大值大 1可读性也高。3.3 查找、修改、删除的联动设计查询和修改、删除不能做成各自独立的孤岛。更自然的交互方式是用户先搜索系统列出匹配结果用户看到结果后在结果列表里选序号再执行修改或删除。搜索函数先做一个通用方法def search_books(keyword): keyword keyword.strip().lower() results [] for b in books: if keyword in b[title].lower() or keyword in b[author].lower(): results.append(b) return results之所以统一转lower()是为了让英文书名的大小写搜索都能命中。搜中文时这个方法不受影响等于无成本兼容了英文场景。展示结果时按 1 到 N 编一下号用户输入的idx减 1 就是results里的真实下标然后再映射到books里的原件def show_book_list(items): for index, book in enumerate(items, start1): print(f{index}. 《{book[title]}》 - {book[author]} f({book[year]}) [{book[status]}])修改函数的核心逻辑def modify_book(): keyword input(请输入要查找的书名或作者关键词).strip() results search_books(keyword) if not results: print(没有找到匹配的图书) return show_book_list(results) choice input(请输入要修改的图书序号回车取消).strip() if not choice: return try: idx int(choice) if idx 1 or idx len(results): print(序号超出范围) return except ValueError: print(请输入数字) return book results[idx - 1] # 这里拿到的字典本来就是 books 里的对象 new_title input(f书名当前{book[title]}回车保持不变).strip() if new_title: book[title] new_title new_author input(f作者当前{book[author]}回车保持不变).strip() if new_author: book[author] new_author save_data() print(修改完成)这里有一个 Python 引用语义的红利results里的元素和books里的元素是同一个字典对象改book[title]就是直接改原列表里的数据不需要再手动找回下标二次赋值。但很多新手在这里反而容易写出“改完没变化”的 bug具体原因我放到第 6 节单独讲。删除函数的流程类似只是多了删除确认防止误操作def delete_book(): keyword input(请输入要删除的书名或作者关键词).strip() results search_books(keyword) if not results: print(没有找到匹配的图书) return show_book_list(results) choice input(请输入要删除的图书序号).strip() ... book results[idx - 1] confirm input(f确认删除《{book[title]}》输入 y 确认).strip() if confirm.lower() y: books.remove(book) save_data() print(删除成功)4. 借书还书一个状态字段牵动的连锁设计4.1 为什么必须加borrower字段很多新手做借书功能只改status把“可借”改成“借出”就觉得完事了。但图书管理系统是给人用的你不记借书人回头书架上少了一本书你连找谁问都不知道。“借出”本身只是一个状态它必须携带上下文信息所以我给字典加了一个borrower字段默认在“可借”状态下不出现一旦借出就记录谁拿走了。这个字段在本项目的还书功能里还有大用——还书时不仅要确认书存在还要确认借书人是不是当初那个人能不能对上号。4.2 借书逻辑防重复借出是硬需求借书代码如下def borrow_book(): keyword input(请输入要借的书名关键词).strip() results search_books(keyword) if not results: print(没有找到匹配的图书) return show_book_list(results) choice input(请输入借阅图书序号).strip() ... book results[idx - 1] if book[status] 借出: print(f抱歉《{book[title]}》已被 {book.get(borrower, 未知)} 借走) return borrower input(请输入借书人姓名).strip() if not borrower: print(借书人姓名不能为空) return book[status] 借出 book[borrower] borrower save_data() print(f《{book[title]}》已借给 {borrower})if book[status] 借出这行判断是借书功能的灵魂。如果不判断同一本书可以被两个人同时借走数据直接乱套。判断完之后如果书本来就是“借出”状态你还能从book.get(borrower, 未知)里把借走的人显示出来这个细节瞬间让程序的真实感上了一个档次。4.3 还书逻辑要连带清理借阅信息还书时对应的清理动作很容易被漏掉def return_book(): keyword input(请输入要还的书名关键词).strip() results search_books(keyword) if not results: print(没有找到匹配的图书) return show_book_list(results) choice input(请输入还书序号).strip() ... book results[idx - 1] if book[status] ! 借出: print(f《{book[title]}》本来就在馆内无需归还) return book[status] 可借 book.pop(borrower, None) # 清除借阅人不留脏数据 save_data() print(f《{book[title]}》归还成功)注意最后一行book.pop(borrower, None)。它的作用是归还后把borrower字段从字典里移除。如果不移除列表展示的时候虽然你设置“按状态显示”可以藏住它但数据里一直残留上次借阅人的名字迟早会串数据。pop第二个参数None是保险就算字典里没有这个字段也不会抛异常。借书还书功能写完之后我才意识到一个业务规律凡是需要“登记状态”的功能都要想清楚状态变化时哪些字段随之更新、哪些字段需要清空。这个经验后来写任何带状态机的程序都用得上不只是图书管理。5. 数据持久化JSON 读写和教程里没写明的三个坑5.1 读取文件要处理“第一次运行”和“文件损坏”程序第一次运行的时候books.json文件根本不存在所以load_data()不能一上来就打开文件。我的做法是先判断文件是否存在def load_data(): global books if not os.path.exists(DATA_FILE): books [] return try: with open(DATA_FILE, r, encodingutf-8) as f: books json.load(f) except json.JSONDecodeError: print(检测到数据文件损坏系统已重置为空列表) books [] except Exception as e: print(f读取数据时发生错误{e}) books []这里的重点是try/except。文件在你编辑的时候被误改、半途断电写入中断、或者你手动往 JSON 里多加了一个逗号都可能导致json.load()解析失败。如果不对这个异常做保护程序每次启动都会崩在读取这一行上你说不出原因也很难排查。现在捕获JSONDecodeError后重置为空列表至少系统还能继续用只是数据丢了而数据丢失本来就是因为文件已经坏了。5.2 保存文件ensure_asciiFalse和indent4缺一个都难受保存函数只有两行但两个参数都值得单独解释def save_data(): with open(DATA_FILE, w, encodingutf-8) as f: json.dump(books, f, ensure_asciiFalse, indent4)ensure_asciiFalse的意思是不要把中文字符转成\u4e2d\u6587这种转义形式。我第一次写的时候漏了这个参数保存后打开books.json看到满屏的\u4e2d\u6587差点以为写坏了。其实数据没丢只是 JSON 模块默认用 ASCII 编码保存非英文字符导致人没法直接阅读文件。加了这个参数文件里直接就是正常中文排数据问题时能直接打开肉眼检查。indent4是缩进 4 个空格让 JSON 文件呈现漂亮的分层结构。没有它所有数据会挤在十行之内找问题是灾难。indent4没有业务含义纯粹是给人类看的。5.3 保存时机每次操作后保存还是退出时统一保存我一开始做的是只在退出时保存一次。做完借书/还书功能就发现不对如果程序断电或者用户在操作中直接关掉终端今天做的所有变更加上之前录入的几百条数据全没了。所以后来我把save_data()的调用散到每一次数据变更之后添加成功、删除成功、修改成功、借书成功、还书成功立刻写盘。这个项目数据量小根本没有性能压力换来的是“任何一步完成了数据就是想丢都丢不掉”的安心感。5.4 文件路径用相对路径还是和脚本绑定DATA_FILE books.json用的是相对路径它依赖你在哪个目录启动脚本。如果哪天你把项目文件夹挪了个位置或者从别的目录执行python books.py文件会在启动目录下新建一个空的books.json你原来的数据看起来就像蒸发了一样。稳妥的做法是把路径和脚本文件本身绑定BASE_DIR os.path.dirname(os.path.abspath(__file__)) DATA_FILE os.path.join(BASE_DIR, books.json)这样无论从哪个目录执行脚本都会去脚本所在目录读写books.json。这个细节很不起眼但在你使用“双击运行”或者定时任务执行脚本时特别重要。6. 三个典型 BUG 的排查实录新手最容易卡住6.1 BUG 之一删除后添加新书ID 重复了现象很明确删掉 ID 为 2 的书之后再添加一本新书新书的 ID 变成了 2和列表里可能还存在的其他旧书 ID 概念上冲突了虽然books列表里暂时没有第二本 ID 为 2 的书但后续按 ID 查找的逻辑全部不可信。排查过程从打印books列表开始。我看到新书 ID 是 2又看到len(books)是 2立刻意识到我的 ID 是用len(books) 1算的。问题就出在“用列表长度代替业务 ID”上列表长度的意义是“当前有多少本书”而 ID 的意义是“这本书的编号”两者根本不是一回事。删掉一本书列表长度变小但编号不应该回退。正确做法就是前面写的max(...) 1。我这里想强调的不是这行代码本身而是排查思路看到数字不对先问自己“这个数字的业务含义是什么”再问“我的代码用的真实数据是什么”两个对不上bug 就浮出水面了。6.2 BUG 之二JSON 文件里全是被转义的中文现象很好笑系统运行正常但打开books.json想看数据满屏\u4e2d\u6587。我当时先是怀疑编码方式错了尝试把w改成wb没用最后去查json.dump()的官方文档才注意到ensure_ascii参数默认是True。Python 的json模块为了兼容不同语言环境默认会把所有非 ASCII 字符转成\uXXXX形式。这个设计本身没问题但对中文使用者极不友好。修一个参数就好ensure_asciiFalse。这个 bug 的收获是凡是遇到“文件里内容不对”先别急着改逻辑把官方文档对应模块的参数从头到尾看一遍很多答案就在默认值里。6.3 BUG 之三修改完一本书列表却一点变化都没有这个 bug 最有教学价值。当时的代码是这样写的for b in books: if b[id] target_id: b {id: b[id], title: 新书名, ...}执行完show_all_books()列表里的书纹丝不动新书名根本没替换进去也没报任何错误。排查时我先打印b的内存地址再打印books里对应元素的内存地址发现循环里的b一开始确实指向原字典但一旦执行b {...}b就被重新绑定到一个全新的字典对象上原列表里的字典一点没受影响。这就是 Python 里“引用 vs 赋值”的经典陷阱b只是指向原对象的变量名给它赋新值等于让这个变量名改指其他对象而不是修改原对象。正确的改法应该是对原字典做原地修改for b in books: if b[id] target_id: b[title] 新书名 b[author] 新作者或者用索引直接覆盖列表元素for i, b in enumerate(books): if b[id] target_id: books[i] {...}这个 bug 让我彻底记住了“赋值到新对象”和“修改原对象”的区别也让我理解了为什么字典作为可变对象时修改它的子字段不需要重新赋值回列表。如果你也遇到“循环里改了但没变”先用id()函数打印检查一下内存地址保你三分钟定位问题。7. 这版系统还能怎么长三条既有价值又不超纲的升级路线Day 21 这个版本整体是“函数式 JSON 文件存储”。如果你练完手还想再进一步不需要去追热点项目就在这个系统上做三次重构收益极大。第一条路线是面向对象化。定义一个Book类和一个Library类把add_book、modify_book这些东西收编为Library的方法把单本图书的字段收编为Book的属性。这个过程能帮你真正理解类的作用代码复用、结构清晰、状态分组。第二条路线是图形界面化用 Python 自带的tkinter把菜单循环变成按钮点击。你会发现同样的业务逻辑从命令行搬到 GUI 唯一要改的只是输入输出层而业务层的函数基本原样保留。这就是“界面与逻辑分离”最直观的体验。第三条路线是数据库迁移。等学到 SQL 基础再用 SQLite 替换 JSON 存储你会发现查找、统计、排序的效率比在 Python 列表里遍历高了一个量级而且代码结构不用大改只需把save_data()和load_data()换成INSERT INTO和SELECT。这种“只换存储层不动业务层”的重构体验比再写十个新项目都更接近真实开发。我的个人感受是图书管理系统这种小项目真正的价值不在于它有多华丽而在于它逼着你把所有基础知识放到一个真实场景里去调度。写完它的那一刻你才会发现 Python 基础篇你不再是“学过”而是“会用了”。