Python Django构建图书管理系统：从模型设计到部署实战

1. 图书管理系统，为什么我选了Django这套组合

先说结论：如果你手里有一个图书管理类的项目需求，不管是为了课程设计、个人练手，还是小团队内部确实需要一个能用的借阅工具，Python + Django + SQLite/MySQL这套组合，是我反复对比之后认为性价比最高的方案。

这个项目并不复杂，核心就是围绕图书的增删改查、借阅归还、读者管理和统计报表。但你真动手去做，会发现"不复杂"和"好做"完全是两码事。图书管理系统的难点从来不在写代码，而在数据关系怎么设计、借阅状态怎么流转、权限怎么控制、后期怎么维护——这几个点恰恰是Django的强项。

Django自带Admin后台，意味着你不用先写管理界面就能快速验证数据模型；自带ORM，意味着你能用Python代码操作数据库，不用写一行SQL；自带认证体系，用户登录、权限分组、Session管理全都有现成实现。对于一个以业务逻辑为主、技术难点相对集中在中后期的系统来说，这能帮你省掉至少三分之一的工作量。

另外，网上大量现成的开源图书管理系统要么是PHP写的，要么代码停留在好几年前的Django 1.x，数据库和模板语法都过时了。用新版本Django从零搭建，反而比改老代码省事。这篇文章我从头到尾理一遍，覆盖系统设计、模型定义、核心功能实现、数据库初始化、常见坑点、部署和文档编写，文章末尾会给出我认为最有价值的几个细节习惯，直接拿走就能用。

2. 系统整体设计：先画清楚三条线

一个图书管理系统，表面上看是"书"的管理，拆开之后其实是三条业务线在并行：图书线、读者线、借阅线。

图书线最简单，就是书的基本信息维护：书名、作者、ISBN、分类、馆藏数量、可借数量、存放位置。注意"馆藏数量"和"可借数量"必须是两个字段，不能用一个字段算出来，因为存在"书还在馆但已被预约"的情况，这个我在后面详细说。

读者线是用户管理：读者编号、姓名、联系方式、借阅权限、状态（正常/挂失/黑名单）。这里要考虑一个边界情况——如果一个读者借了书不还，账号被停用了，他之前在借的书怎么处理？所以读者状态和借阅记录不要直接硬关联，而是用"借阅时校验状态"的方式处理。

借阅线是核心中的核心：借出、归还、续借、逾期、预约。这条线最容易踩坑的地方在于状态流转，比如一本书被借出后，在归还之前不能被另一人借走；一本书被预约后，归还时应该优先通知预约者而不是直接上架。这些规则如果不在一开始就理清，后面写业务逻辑时一定会挂一漏万。

我建议画一张简单的状态流转图：可借 → 已借出 → 已归还（可借）→ 预约中 → 待取书，把每个状态下系统允许的操作列出来，再开始写模型。这一步花不了多少时间，但能让你少走很多弯路。

2.1 功能模块划分：三个角色各看各的

按角色划分，系统一般拆成三个端：

管理员端：图书录入、编辑、下架，读者管理，借阅异常处理，系统数据统计。管理员需要的是一目了然的后台，不是花哨的交互。

读者端：检索图书、查看详情、借书、还书、查看个人借阅历史。读者端负责高频操作，性能要跟得上，页面要轻量。

系统端（自动任务）：逾期提醒、预约通知、图书状态自动更新。这部分用Django的定时任务实现，不需要用户干预。

三个端的数据模型是同一套，但接口和页面权限不同。我用Django自带的Group做粗粒度权限控制，Admin后台只给管理员用，前台登录区分读者和管理员，API层面再用装饰器做校验，简单够用，没有额外引入复杂的权限框架。

2.2 为什么不用Flask或Node.js

不是说Flask不好，但图书管理系统是一个典型的多表关联系统——书、作者、出版社、读者、借阅记录，互相之间有外键关系。Flask需要你自己选ORM（SQLAlchemy）、自己配迁移工具（Alembic）、自己搭Admin、自己写认证。每一样都不难，但加起来就是一笔不小的成本。

Django则是"全家桶"，模型、迁移、Admin、认证、表单、模板全部内置，而且接口设计高度一致。对于一个业务逻辑型项目来说，这种一致性比灵活性重要得多。Node.js也行，但Express生态太碎片化，不该把时间花在"选型"而不是"实现"上。

3. 数据模型设计：建表之前先把关系想清楚

数据模型是整个系统的地基，模型设计错了，后面写再多业务代码都是补救。我来说说这套系统里最核心的几张表和它们之间的关系。

3.1 核心表结构拆解

图书表（Book）：主键ID、书名、作者、出版社、ISBN、分类、简介、封面图、馆藏数量、可借数量、上架时间、状态。ISBN最好加唯一约束，但注意有一些老书可能没有ISBN或者有重复的，需要在录入时做校验而不是盲目地加唯一索引。

读者表（Reader）：主键ID、读者编号（自己生成的唯一编码）、姓名、性别、联系电话、邮箱、注册时间、状态。

借阅记录表（BorrowRecord）：主键ID、图书外键、读者外键、借出时间、应还时间、实际归还时间、续借次数、状态（借出中/已归还/逾期）。这张表是系统里记录量最大的表，一定要给"图书外键"和"读者外键"加索引，否则数据量大了之后查询会很吃力。

分类表（Category）：主键ID、分类名称、父分类外键（自关联，为了做二级分类）、排序值。

这四张表的关系可以概括为：一本书属于一个分类，一个分类下有多本书；一条借阅记录关联一本书和一个读者，一个读者有多条借阅记录。

3.2 为什么借阅记录要单独建表而不是在图书表里加状态

这是很多新手容易犯的错误——直接在图书表里加一个"是否借出"的字段，借出就置为True，还回来置为False。看起来简单，但一旦要查"这本书上个月被谁借过"，就完全无从下手了。借阅记录是行为数据，图书是实体数据，两种数据应该分开存。

单独的借阅记录表还能天然支持后续扩展：比如统计分析"哪本书被借阅次数最多""哪个读者借书最勤"，这些需求全部能从BorrowRecord里统计出来，不需要额外设计表。

3.3 字段设计时那些容易踩的细节

我踩过最典型的坑是时间字段。借阅应还时间如果用DateTimeField，后面计算逾期天数时会出现时区问题。Django的TimeZone支持开启后，数据库存的是UTC时间，如果你在计算"应还日期 - 今天"时没做时区转换，会有整天的偏差，用户看到的逾期天数是错的。

我的处理是：USE_TZ = False，统一用本地时间。如果你的系统只在单一地区使用，这个方案简洁直接；如果需要跨时区，那就要用Django的timezone.localtime()转换后再计算。

另一个细节是金额和数字字段。如果有人要做"借阅超期罚款"，金额字段不要用FloatField，应该用DecimalField，否则浮点精度问题会让你在计算总罚款时出现0.1 + 0.2 = 0.30000000000000004这种诡异结果。

4. 核心功能实现：从列表页到借阅闭环

模型设计好之后，进入功能实现阶段。我按照"用户使用路径"来组织功能开发顺序，而不是按代码模块去写——这样更贴近实际项目节奏。

4.1 图书检索：ORM查询怎么写才优雅

图书检索是用户使用频率最高的功能。我的检索页面包含三个条件：关键字（书名、作者、ISBN模糊匹配）、分类、借阅状态（全部/可借/借出）。

Django的ORM查询，用Q对象组合条件：

from django.db.models import Q def search_books(keyword, category_id, status): queryset = Book.objects.filter(is_active=True) if keyword: queryset = queryset.filter( Q(title__icontains=keyword) | Q(author__icontains=keyword) | Q(isbn__icontains=keyword) ) if category_id: # 如果选了父分类，连带查子分类下的书 category_ids = [category_id] child_categories = Category.objects.filter(parent_id=category_id) category_ids.extend([c.id for c in child_categories]) queryset = queryset.filter(category_id__in=category_ids) if status == 'available': queryset = queryset.filter(available_count__gt=0) return queryset.select_related('category').order_by('-created_at')

这里的Q对象可以自由组合"与"和"或"条件，比多次filter()串联干净得多，尤其是当条件里有"或"的时候只能靠Q。

几个细节值得注意：

第一，select_related('category')是必须的，因为列表页要展示分类名称。如果不加，Django会为每一本书单独查一次分类表，100本书就是100条额外SQL，加了之后直接JOIN，一次搞定。数据量不大的时候体感不明显，数据量上了1000就有差距了。

第二，列表页一定要做分页，我用的Django内置Paginator。每页20条，页码参数从URL获取，有上一页下一页。

第三，模糊查询用icontains而不是contains，前者忽略大小写，用户体验更好。但注意icontains会走LIKE '%xxx%'，数据库索引帮不上忙，数据量几十万的级别没问题，再大就要换全文搜索引擎了。图书管理这种场景，万级数据量，完全够用。

4.2 借阅与归还：事务和并发控制

借书操作是整个系统里最容易出并发问题的环节。想象一下：一本书只剩最后一本可借，两个读者同时点击借阅按钮。如果代码是"先查可借数量，大于0就借出，然后减1"，两个请求可能同时查到数量为1，然后同时借出，最后库存变成负数。

解决办法有两个层面：

第一层是事务，用transaction.atomic()保证"检查-修改"作为一个原子操作：

from django.db import transaction @transaction.atomic def borrow_book(request, book_id): book = Book.objects.select_for_update().get(id=book_id) if book.available_count <= 0: raise ValueError("这本书暂时没有可借的库存") # 创建借阅记录 BorrowRecord.objects.create( book=book, reader=request.user.reader, borrow_date=timezone.now(), due_date=timezone.now() + timedelta(days=30), status='borrowed' ) # 减少可借数量 book.available_count -= 1 book.save()

select_for_update()是关键，它会对数据库表中对应的行加锁，直到事务结束，其他查询要等锁释放后才能读到这行数据。注意这个函数必须在事务内使用，单独调用没效果。

第二层是数据库约束，图书表的available_count字段设置>= 0的检查约束，做最后防线。这样即使应用层有BUG，数据库层面也会拒绝负数的产生。

分段加锁的思路其实和超市购物是同一个道理——货架上存了多少货，每个收银台从同一库存里扣减，如果不加锁，最后一件商品可能被卖给两个人。

归还操作的逻辑相对简单，但有一个易错点：归还时不能直接设置available_count += 1，要判断这本书的状态。如果借阅记录已经显示逾期，归还时应该先更新借阅记录状态，再检查是否需要生成罚款记录或扣信用分，最后才增加库存。

我在实际项目中还遇到过一个场景：读者借了书，但是书丢了，要按遗失处理。这时不能走归还逻辑，要走赔偿逻辑——把书状态改成"遗失"，借阅记录标记为"已赔偿"，库存不减（因为这本书物理上已经没了）。这些分支逻辑最好在一开始设计状态机时就想清楚。

4.3 用户认证与权限：不同角色看到不同世界

Django自带的auth应用提供了用户表、登录、Session、密码加密这些基础能力，直接复用即可，不需要自己重写。但在图书管理系统中，用户（User）和读者（Reader）是两个概念——User管登录认证，Reader管业务属性。

我用的方案是OneToOneField关联：

from django.contrib.auth.models import User class Reader(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE) reader_id = models.CharField(max_length=20, unique=True) name = models.CharField(max_length=50) # ...其他字段

这样设计的好处是：认证逻辑全部走Django原生方案，密码加密、登录状态管理、Session过期都交给框架。业务层面才需要关注Reader的属性。

权限控制我分两层：

视图层——用装饰器控制访问：

from django.contrib.auth.decorators import login_required, user_passes_test def is_admin(user): return user.is_staff @login_required def my_borrow_records(request): # 任何登录用户都可以看自己的借阅记录 ... @login_required @user_passes_test(is_admin) def admin_book_list(request): # 只有管理员可以管理图书 ...

模板层——控制页面元素显示：

{% if user.is_staff %} <a href="{% url 'admin_book_add' %}">新增图书</a> {% endif %}

权限控制的原则是"控制器兜底，模板只是隐藏"。模板里加了判断只是让用户看不到入口，但如果用户懂技术，照样可以手动构造URL访问后台接口。所以真正的权限校验必须在视图层做，模板层的判断只是UI优化。

4.4 模板继承和静态文件：一个base模板省一半事

Django的模板继承机制用好了能节省大量重复代码。我建了一个base.html作为所有页面的骨架，包含导航栏、Bootstrap的CSS/JS引用、消息提示区域、页脚。子页面只需要重写{% block content %}部分：

<!-- base.html核心结构 --> <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>{% block title %}图书管理系统{% endblock %}</title> <link rel="stylesheet" href="{% static 'css/bootstrap.min.css' %}"> {% block extra_css %}{% endblock %} </head> <body> <nav class="navbar navbar-expand-lg navbar-dark bg-primary"> {% include 'includes/navbar.html' %} </nav> <main class="container mt-4"> {% if messages %} {% for message in messages %} <div class="alert alert-{{ message.tags }}">{{ message }}</div> {% endfor %} {% endif %} {% block content %}{% endblock %} </main> <script src="{% static 'js/bootstrap.bundle.min.js' %}"></script> {% block extra_js %}{% endblock %} </body> </html>

图书列表页只需要这样：

{% extends 'base.html' %} {% block title %}图书列表{% endblock %} {% block content %} <table class="table table-hover"> <thead> <tr> <th>书名</th> <th>作者</th> <th>分类</th> <th>可借数量</th> <th>操作</th> </tr> </thead> <tbody> {% for book in page_obj %} <tr> <td>{{ book.title }}</td> <td>{{ book.author }}</td> <td>{{ book.category.name }}</td> <td>{{ book.available_count }}</td> <td> <a href="{% url 'book_detail' book.id %}" class="btn btn-sm btn-info">详情</a> {% if book.available_count > 0 %} <a href="{% url 'book_borrow' book.id %}" class="btn btn-sm btn-success">借阅</a> {% endif %} </td> </tr> {% empty %} <tr><td colspan="5">没有找到符合条件的图书</td></tr> {% endfor %} </tbody> </table> {% include 'includes/pagination.html' with page_obj=page_obj %} {% endblock %}

用{% empty %}处理空数据是模板里的好习惯，避免用户看到一个空表格。分页模板抽成includes/pagination.html之后，列表页、借阅记录页、读者管理页都可以复用。

5. 数据库初始化与测试数据：让项目跑起来的第一步

从零开始直接把项目交给别人，对方大概率会卡在数据库这一步。所以我做项目时坚持一个原则：项目代码里必须包含完整的数据库初始化方案和测试数据脚本。

5.1 迁移命令与初始数据

Django的迁移系统是我最喜欢的功能之一。模型定义好之后，执行：

python manage.py makemigrations python manage.py migrate

会生成迁移文件并同步到数据库。这里有一个集体经历过的坑：开发过程中如果直接删掉迁移文件重新生成了，部署时新旧环境的迁移记录对不上，就有可能出现django.db.migrations.exceptions.InconsistentMigrationHistory错误。解决方式是在项目发布前清空确认迁移记录，用migrate --fake重置迁移状态。

我的习惯是初始数据用Fixture，把运行系统必不能少的默认数据（比如管理员账号、基础分类）存成JSON文件，在部署时加载：

python manage.py loaddata initial_data.json

[ { "model": "auth.user", "pk": 1, "fields": { "username": "admin", "password": "pbkdf2_sha256$...", "is_superuser": true, "is_staff": true, "is_active": true } }, { "model": "books.category", "pk": 1, "fields": { "name": "文学", "parent": null, "sort_order": 1 } }, { "model": "books.category", "pk": 2, "fields": { "name": "科幻", "parent": null, "sort_order": 2 } } ]

注意Fixture里面存密码一定要是Django加密后的字符串，不是明文。这样部署好之后你有一个能直接登录的管理员账号，剩下的图书和读者用Admin后台手工添加也行，用脚本批量造也行。

5.2 造测试数据的正确姿势

手工录入测试数据效率太低，我写了一个独立的seed_data.py脚本，用Faker库生成几百本图书和几十个读者：

import os import django os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'library.settings') django.setup() from faker import Faker from books.models import Book, Category, Reader from django.contrib.auth.models import User from django.utils import timezone import random fake = Faker('zh_CN') def create_categories(): categories = ['文学', '科幻', '历史', '计算机', '艺术', '经济'] for name in categories: Category.objects.get_or_create(name=name) print(f'成功创建 {len(categories)} 个分类') def create_books(count=200): categories = list(Category.objects.all()) for i in range(count): isbn = fake.isbn13() # 通过 get_or_create 避免重复 ISBN 导致脚本重跑时报错 _, created = Book.objects.get_or_create( isbn=isbn, defaults={ 'title': fake.sentence(nb_words=4), 'author': fake.name(), 'category': random.choice(categories), 'total_count': random.randint(1, 10), 'available_count': random.randint(0, 10), 'publisher': fake.company(), 'summary': fake.paragraph(), } ) print(f'成功创建 {count} 本图书') def create_readers(count=20): for i in range(count): username = f'reader_{i:03d}' user = User.objects.create_user(username=username, password='123456') Reader.objects.create( user=user, reader_id=f'RD{timezone.now().year}{i:04d}', name=fake.name(), phone=fake.phone_number(), ) print(f'成功创建 {count} 个读者') if __name__ == '__main__': create_categories() create_books() create_readers()

这个脚本可以重复运行，因为用get_or_create避免了主键冲突。造完数据之后，页面有内容可看，借阅流程也能真正跑通，联调效率高很多。

6. 常见问题与排查技巧：这些坑我替你踩过了

这部分内容我给的优先级最高，因为开发中真正浪费时间的地方，不是你不知道怎么写，而是出了问题不知道怎么查。这里列几个实测中出现频率最高的场景。

问题一：静态文件404

开发环境用runserver跑，页面样式加载不出来，最常见的原因是settings.py里STATIC_URL配置了但静态文件路径没写对。Django开发环境中DEBUG = True时会自动服务app/static/目录下的文件，但如果你额外用了一个不存在的目录作为STATICFILES_DIRS，就会看到404。

排查思路：先访问http://127.0.0.1:8000/static/css/bootstrap.min.css，如果404，检查findstatic css/bootstrap.min.css命令的输出路径。

问题二：迁移报错django.db.migrations.exceptions.InconsistentMigrationHistory

这个错误几乎每个Django项目都会遇到一次。原因通常是某个App的迁移记录依赖了另一个App的迁移，但那个App的迁移状态不匹配。最直接的处理办法在开发阶段：手动删掉数据库中的所有迁移记录表，保留数据，重新makemigrations和migrate，或者直接重建数据库。生产环境千万别这么干，要针对每个App单独处理。

问题三：CSRF验证失败

Django自带CSRF保护，默认所有POST请求都需要携带csrf token。前端表单里必须加：

{% csrf_token %}

如果是AJAX请求，要在请求头里加X-CSRFToken。新手最容易忘的就是这个，报了403错误一脸懵。遇到这个错先检查模板里有没有加{% csrf_token %}，注意不是{% csrf %}，拼写要对。

问题四：时间字段获取不到正确的当前时间

如果你在模型里定义了auto_now_add=True，那么创建记录时这个字段会自动设置为当前时间。如果发现时间不对，检查TIME_ZONE和USE_TZ的配置。中国时区设置是TIME_ZONE = 'Asia/Shanghai'，USE_TZ = False（单地区部署）。

问题五：查询N+1问题，页面响应越来越慢

列表页显示图书类型时，如果模板里写了{{ book.category.name }}，但视图没有select_related，Django会在循环里为每条记录发起一次新的数据库查询。100条记录就是101次查询。用django-debug-toolbar一看便知，每次刷新都是100多条SQL。解决方案前面说过了，select_related一把梭。

问题六：数据库锁等待超时

借阅功能上线后出现OperationalError: database is locked。这是SQLite在高并发写入时的经典问题，SQLite对并发写入的支持非常有限，两个事务同时写同一行时会锁库。解决思路：部署时切换到MySQL或PostgreSQL。SQLite适合做开发和演示，正式多用户场景不建议。

我把这些问题整理成一张速查表，方便遇到时快速定位：

7. 部署上线与文档编写：项目能用和项目好用是两码事

系统开发完成只是第一步，真正检验工作质量的还有部署环节和文档质量。

7.1 部署到服务器时的关键配置

部署方案我选了Gunicorn + Nginx，目前Python Web项目最主流的组合。Django自带的runserver并发能力太弱，只适合开发时热重载，生产环境必须换Gunicorn多进程跑。

部署配置分几步：

第一步，收集静态文件。Django的静态文件由各个App分开管理，生产环境需要统一收集到一个目录，由STATIC_ROOT指定，然后执行python manage.py collectstatic --noinput。Nginx直接从这个目录提供静态文件服务，不用经过Python进程。

第二步，配置Gunicorn：

gunicorn library.wsgi:application -w 3 -b 127.0.0.1:8000 --timeout 120

-w 3表示启动3个工作进程处理并发请求，具体数值根据服务器CPU核心数调整，一般建议2 x CPU核数 + 1。--timeout要设置大一点，不然某些耗时操作（比如导出报表）可能被杀掉，报Worker failed to boot。

第三步，Nginx反向代理并托管静态文件：

server { listen 80; server_name your_domain.com; # 静态文件由Nginx直接处理 location /static/ { alias /var/www/library/staticfiles/; } # 其他请求转发给Gunicorn location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

第四步，设置HTTPS和数据库备份。用certbot申请免费证书，数据库每天凌晨用crontab定时备份。图书管理系统的数据量虽不大，但丢了同样麻烦，备份策略不能省。

这里要特别提醒：部署时DEBUG必须设为False。DEBUG = True会在生产环境暴露所有报错详情，包括敏感环境变量，潜在风险极大，而且Django会拒绝服务静态文件，页面直接全裸。同时记得在ALLOWED_HOSTS里配置域名，否则会报DisallowedHost错误。

7.2 什么样的项目文档才真正有用

很多开源项目的文档写了两百页，新用户照着做还是起不来。我自己的经验是，一份"能让人从零跑起来"的文档比什么都重要。我在这份项目的文档里固定了几个板块：

环境要求：Python版本、Django版本、数据库版本，要具体到小版本号。比如Python 3.10和Python 3.12在依赖兼容上就有区别，写清楚能省掉用户大量试错时间。

安装部署步骤：从拉取代码到最后打开浏览器看到首页，每一步都写成可执行的命令。包括虚拟环境的创建激活、依赖安装、数据库迁移、Fixture导入、创建超级用户、启动服务，每一步附带预期输出，方便用户判断是否成功。

目录结构说明：从顶层目录到每个App的职责划分，让人能快速定位代码。

核心业务流程说明：借阅、归还的完整流程，配合状态流转说明。这个对后续接手维护的人特别重要，不然他看不懂为什么代码里要处理那么多状态分支。

常见问题FAQ：把我在第六节整理的排查表直接放进文档里。

文档的写作原则说穿了就一条——站在一个完全不懂项目的人的角度去写，假设程序员的电脑上连Django都没装过。能一句命令解决的，不要写四个步骤。能给出预期输出的，一定要写出来。

8. 我在实际开发中沉淀的几个习惯

最后说几个我在完成这个项目后仍然坚持的习惯，它们帮我省下的时间远超想象。

第一，每个模型都加created_at和updated_at字段。创建时间用auto_now_add=True，更新时间用auto_now=True。刚开始觉得多此一举，后来排查线上问题时全靠这两个字段定位"这条数据是什么时候变的"，再没后悔过。

class BaseModel(models.Model): created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now=True) class Meta: abstract = True

第二，数据库约束和应用层校验一起上。比如说读者表里的手机号，前端可以做格式校验提升用户体验，但数据库层面也要加RegexValidator，双保险。每种校验解决不同层面的问题，前端校验防手误，后端校验防绕过前端。

第三，写日志不是为了给谁看，是为了自己排查问题。Django的日志配置默认不够用，我习惯在项目里这样配：

LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'file': { 'level': 'ERROR', 'class': 'logging.FileHandler', 'filename': 'logs/error.log', }, }, 'loggers': { 'django': { 'handlers': ['file'], 'level': 'ERROR', 'propagate': True, }, }, }

线上环境出问题的时候，我先看日志文件，而不是让用户帮忙截图报错信息，这一点极其重要。

第四，每次字段变更都要额外思考一个问题：存量数据怎么办。新增一个字段，线上已有的几万条记录这个字段的值是什么？需要不需要跑数据迁移脚本补默认值？在开发环境可以随手改模型同步数据没问题，到了有真实数据的生产环境，这个问题躲不开。

这套图书管理系统前后花了两周时间，从需求分析到文档编写。如果让我用一句话总结最重要的经验，那就是：不要只写能跑的代码，要写能维护的系统。数据模型的设计、边界情况的考虑、日志记录的规范、文档的完整度，这些看起来不直接产生功能的投入，最终决定了一个项目是能撑三年还是三个月。