高校读书分享系统，在Python Web开发的学习圈子里几乎成了“标配级”的实战题目。我最初看到“Python flask flask高校读书分享系统的设计与实现 - vue pycharm django”这个标题时，第一反应是：Flask和Django怎么同时出现在一个题目里了？后来仔细想了想，这种情况并不罕见——要么是课题需求文档把两套框架都列成了候选，要么是作者在前期调研时都接触过，最终敲定用Flask作为落地主线。不管哪种情况，这个题目真正想表达的核心是：用Python后端框架快速搭出一个支持图书管理、读书笔记分享、互动评论的完整Web系统。

这类型系统要解决的现实问题很直观。传统高校里，读书活动往往靠线下打卡、纸质表格登记，参与度难以追踪，优质读书笔记也沉淀不下来。做成在线系统后，学生可以检索馆藏图书、发布读书感悟、互相点赞评论，管理员能够统一管理书目和用户内容，整个“读—写—评”的闭环就完整了。适合人群也比较广：正在准备课程设计或毕业设计的同学、想通过前后端分离项目练手的前端准全栈开发者，以及所有对Flask框架有基础、想让项目从零完整落地的人。读完这篇文章，你可以直接拿着里面的表结构和代码思路，改造出自己版本的系统。

1. 项目全景与技术选型拆解

1.1 Flask与Django同框？先理清选型逻辑

标题里同时出现Flask和Django，说白了就是一个选型问题。很多初学者在定技术栈时，都会在这两个Python Web框架之间犹豫，我见过不少课程设计的题目描述干脆把两个都写上，表示“用哪个都行”，但真正动手写代码时还是只能二选一。

从框架定位上看，Flask和Django走了完全不同的路线。Django号称“全家桶”，自带ORM、Admin后台、用户认证、表单处理等一整套基础设施，项目结构比较固定，适合中大型系统，约定大于配置。Flask则像一块精钢骨架，核心只保留路由和请求响应，其余能力全部通过扩展组装，轻量、灵活、透明，代码到哪儿都清清楚楚呈现在你面前。

以这个高校读书分享系统为例，我更推荐拿Flask来做，理由有三个方面。第一，系统规模完全可控，校内用户量级通常几千人，并发压力不大，Flask配合SQLAlchemy完全扛得住。第二，学习价值更高，Flask的项目结构需要你自己搭，路由、蓝图、ORM初始化、Request Hook这些底层概念都会被逼着亲手过一遍，比在Django里直接命令行生成项目要容易理解得多。第三，Django的Admin后台虽然自动生成很方便，但一旦默认界面满足不了定制需求，你要去覆盖模型管理器的默认行为，反而比Flask从零写一个管理接口更费劲。

1.2 为什么选Vue做前端，而不是Jinja2模板

Flask原生支持Jinja2服务端模板渲染，那为什么题目要求用Vue？核心原因是“前后端分离”的开发模式。

如果只用Jinja2，整个项目的页面跳转、表单提交、数据渲染全部压在Flask这一层，前端代码和后端逻辑交织在同一批文件里。项目规模小的时候还好，一旦功能模块多起来，维护体验会很痛苦。换用Vue做前端后，Flask只专心提供JSON格式的API接口，前端页面通过axios异步请求数据，再通过Vue的双向绑定刷新视图，职责划分很清晰。

Vue对新手同样友好。它不需要一上来就掌握全家桶全部内容，只用Vue Router做路由控制、Pinia或Vuex做状态管理、axios做网络请求，已经能支撑一套像样的前端工程。而且Vue的组件化开发让页面复用变得方便，图书卡片、评论列表、用户信息这种高频组件，写一次就能到处引用。

1.3 系统功能地图与核心用户场景

在设计之前，先把系统的角色和功能边界划清楚。这个项目我划分成三类角色：普通用户、图书管理员、系统管理员。普通用户是核心角色，负责看书、写笔记、互动；图书管理员侧重书目维护；系统管理员控制人员权限与内容审核。

各模块功能点整理如下：

用户场景也很典型：访客可以浏览公开书单和笔记，但注册登录后才能发布内容；学生登录后搜索某本专业书，查看馆藏状态，读完后写一篇阅读感悟并附上个人评分；管理员在后台看到用户举报笔记后，可以执行下架处理。把这样一个闭环跑通，系统就算真正成型了。

2. 数据库与核心模块设计解析

2.1 表结构总览：人、书、笔记、互动四条线

数据库设计是这类系统最容易返工的部分。我的建议是：不要急着写代码，先在纸上把“人、书、笔记、互动”四条业务线画清楚。整个项目我规划了六张核心表，外加一张图书分类表。

• users：用户表，字段包括id、用户名、加密密码、邮箱、头像、角色、创建时间
• categories：图书分类表，字段包括id、分类名、描述
• books：图书表，字段包括id、ISBN、书名、作者、出版社、封面URL、简介、分类外键、库存总数、可借数量
• notes：读书笔记表，字段包括id、用户外键、图书外键、标题、正文、浏览量、点赞数、创建时间、更新时间
• comments：评论表，字段包括id、用户外键、笔记外键、评论内容、创建时间
• likes：点赞关联表，字段包括id、用户外键、笔记外键、创建时间，其中用户和笔记联合唯一
• collects：收藏表，字段包括id、用户外键、图书外键、创建时间

这套表结构最关键的一点是，笔记同时持有user_id和book_id两个外键。这样设计的好处是，页面可以按“某人读过哪些书、写过哪些笔记”来聚合，也可以按“某本书下有哪些人的书评”来聚合，两种查询路径都能通过外键索引高效完成。

2.2 用户模块设计：密码安全与JWT鉴权

用户模块的安全底线是密码绝不明文存储。在Flask里我直接用werkzeug自带的密码哈希工具，调用generate_password_hash对明文密码进行加盐哈希后存入数据库，校验时使用check_password_hash比对。哈希后的字符串长度较长，数据库字段记得预留255个字符，用64长度的同学后面特别容易遇到迁移改字段的麻烦。

登录状态管理方面，推荐用JWT（JSON Web Token）而不是传统的Session方案。原因在于前后端分离后，Session默认依赖Cookie穿透跨域场景，处理CSRF防护也比较顺手；JWT则是无状态的，后端只需要验签，前端把token存在localStorage或返回数据里，请求时放在Authorization请求头里即可。

JWT的具体做法是：登录成功后把用户id和过期时间放进payload，用SECRET_KEY签名签发；后端写一个token_required装饰器，解析请求头里的token，校验通过后把当前用户对象挂到请求上下文里，后续接口直接取用。过期时间我通常设置成24小时，太长不安全，太短又会影响体验，这个值可以按校内使用场景调整。

2.3 读书笔记与互动模块：为什么点赞要单独建表

读书笔记模块是系统的内容核心，设计时要注意和图书、用户的关系紧密绑定。一篇笔记只有同时关联book_id和user_id，才能实现图书详情页展示“这本书的所有读者笔记”，以及个人主页展示“我发布过的全部笔记”这两个高频需求。

点赞功能则建议单独用likes表，而不是在note表里只维护一个like_count数字。初学者最容易踩的坑就是直接在note表里加个计数字段，结果用户是否点过赞完全判断不了，也没办法做取消点赞。正确的做法是建立一个关联表，用user_id和note_id的联合唯一约束来避免重复点赞。每次点赞操作时，通过一条事务同时更新关联表和计数，从而保证数据一致性。同理，收藏功能也单独建表，一张表同时服务“收藏列表”和“是否已收藏”两个查询场景。

评论表我先做成一级评论，也就是所有评论直接挂在笔记下，不做楼中楼。原因是课程设计阶段“被评论的评论”会引入额外的parent_id递归查询逻辑，复杂度和收益不成正比。等系统跑起来后，如果想加楼中楼，再在comments表增加parent_id字段做扩展也不迟。

2.4 设计中的经验教训：冗余字段与时间格式

like_count属于典型的冗余字段。冗余的好处是查询列表页面时不用每次count子查询，性能更好；代价是每次点赞/取消点赞需要维护它与明细表的一致性。我的处理方案是：明细表是唯一事实来源，计数做冗余，所有写操作放在事务内完成，count字段用一个原子加减表达式更新，避免并发下读写冲突。

时间字段同样是一个容易出问题的地方。数据库统一存储UTC时间，创建记录时使用datetime.utcnow()而不是datetime.now()。前端展示时再统一转成本地时间，避免因为部署服务器时区不同导致用户看到的时间差八小时。

3. Flask后端核心实操

3.1 环境准备与项目初始化

实操部分从环境准备开始。开发工具用PyCharm，可以省去很多折腾解释器的时间。打开PyCharm新建项目后，直接勾选Virtualenv环境，然后在终端执行安装：

python -m venv venv source venv/bin/activate # Windows下执行 venv\Scripts\activate pip install flask flask-sqlalchemy flask-migrate flask-cors pymysql PyJWT python-dotenv

这里有个版本问题需要提醒：Flask 2.x和3.x在部分API上有细微差异，我在项目里用Flask 3.0.x配合SQLAlchemy 2.x，整体比较稳定。建议写一个requirements.txt把版本固定下来，避免换机器后依赖漂移。PyCharm自带的解释器选择器可以直接绑定虚拟环境，运行配置里选上venv里的Python即可。

3.2 项目目录结构与蓝图划分

整个后端工程采用工厂模式加蓝图的组织方式，目录结构如下：

app/ __init__.py # 应用工厂 models.py # SQLAlchemy模型 extensions.py # db与migrate初始化 api/ __init__.py auth.py # 注册登录 books.py # 图书接口 notes.py # 笔记接口 comments.py # 评论接口 utils/ auth_utils.py # JWT装饰器 config.py # 配置 run.py # 启动入口 seed.py # 种子数据脚本

用Blueprint的目的很直接：几百行代码堆在一个文件里，后面排查问题时定位困难。一个路由模块对应一个蓝图，注册时统一加上/api前缀，接口的语义路径就是/api/auth/login、/api/books这种，风格清晰，也方便前端统一处理。

__init__.py中的应用工厂是核心入口：

from flask import Flask from .extensions import db, migrate from .api.auth import auth_bp from .api.books import books_bp from .api.notes import notes_bp def create_app(): app = Flask(__name__) app.config.from_object('config.Config') db.init_app(app) migrate.init_app(app, db) app.register_blueprint(auth_bp, url_prefix='/api/auth') app.register_blueprint(books_bp, url_prefix='/api/books') app.register_blueprint(notes_bp, url_prefix='/api/notes') return app

3.3 核心代码实现：注册登录与JWT鉴权

先看用户模型：

from werkzeug.security import generate_password_hash, check_password_hash from .extensions import db class User(db.Model): __tablename__ = 'users' id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(64), unique=True, nullable=False) password_hash = db.Column(db.String(255), nullable=False) email = db.Column(db.String(120), unique=True) avatar = db.Column(db.String(255)) role = db.Column(db.String(16), default='student') created_at = db.Column(db.DateTime, default=db.func.now()) def set_password(self, password): self.password_hash = generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password)

注册接口处理逻辑很直接：前端提交用户名、密码、邮箱，后端先查用户名是否被占用，如果通过则创建用户对象并调用set_password存入密码哈希。

@auth_bp.route('/register', methods=['POST']) def register(): data = request.get_json() if not data or not data.get('username') or not data.get('password'): return jsonify({'code': 1, 'msg': '用户名和密码不能为空'}), 400 if User.query.filter_by(username=data['username']).first(): return jsonify({'code': 1, 'msg': '用户名已存在'}), 400 user = User(username=data['username'], email=data.get('email', '')) user.set_password(data['password']) db.session.add(user) db.session.commit() return jsonify({'code': 0, 'msg': '注册成功'})

登录接口除了校验密码，还要签发JWT。PyJWT的写法如下：

import jwt from datetime import datetime, timedelta @auth_bp.route('/login', methods=['POST']) def login(): data = request.get_json() user = User.query.filter_by(username=data.get('username')).first() if not user or not user.check_password(data.get('password', '')): return jsonify({'code': 1, 'msg': '用户名或密码错误'}), 401 token = jwt.encode( {'user_id': user.id, 'exp': datetime.utcnow() + timedelta(hours=24)}, current_app.config['SECRET_KEY'], algorithm='HS256' ) return jsonify({'code': 0, 'data': {'token': token, 'username': user.username, 'role': user.role}})

鉴权装饰器是承接所有受保护接口的关键：

from functools import wraps import jwt def token_required(f): @wraps(f) def decorated(*args, **kwargs): auth_header = request.headers.get('Authorization') if not auth_header or not auth_header.startswith('Bearer '): return jsonify({'code': 401, 'msg': '登录状态失效，请重新登录'}), 401 token = auth_header.split(' ')[1] try: payload = jwt.decode(token, current_app.config['SECRET_KEY'], algorithms=['HS256']) current_user = User.query.get(payload['user_id']) if not current_user: return jsonify({'code': 401, 'msg': '用户不存在'}), 401 except jwt.ExpiredSignatureError: return jsonify({'code': 401, 'msg': '登录已过期'}), 401 except jwt.InvalidTokenError: return jsonify({'code': 401, 'msg': '无效凭证'}), 401 return f(current_user, *args, **kwargs) return decorated

这个装饰器返回的current_user会作为参数传给被装饰的视图函数，后面发布笔记、点赞、评论等接口都可以直接拿当前用户对象。

3.4 核心代码实现：图书与笔记接口

图书列表接口需要支持分页、关键词搜索和分类筛选，SQLAlchemy的查询链式写法能很好地应对：

@books_bp.route('', methods=['GET']) def list_books(): page = request.args.get('page', 1, type=int) size = request.args.get('size', 10, type=int) keyword = request.args.get('keyword', '') category_id = request.args.get('category_id', type=int) query = Book.query if keyword: query = query.filter(db.or_( Book.title.like(f'%{keyword}%'), Book.author.like(f'%{keyword}%'), Book.isbn.like(f'%{keyword}%') )) if category_id: query = query.filter(Book.category_id == category_id) pagination = query.paginate(page=page, per_page=size, error_out=False) items = [book.to_dict() for book in pagination.items] return jsonify({'code': 0, 'data': { 'items': items, 'total': pagination.total, 'page': page, 'size': size }})

这里的to_dict()是模型里定义的序列化方法，只暴露前端需要的字段，避免把数据库所有字段暴露出去。

发布笔记接口放在蓝图里，结合token_required装饰器使用：

@notes_bp.route('', methods=['POST']) @token_required def create_note(current_user): data = request.get_json() if not data.get('book_id') or not data.get('content'): return jsonify({'code': 1, 'msg': '图书和笔记内容是必填项'}), 400 book = Book.query.get(data['book_id']) if not book: return jsonify({'code': 1, 'msg': '图书不存在'}), 404 note = Note( user_id=current_user.id, book_id=book.id, title=data.get('title', ''), content=data['content'] ) db.session.add(note) db.session.commit() return jsonify({'code': 0, 'msg': '发布成功', 'data': {'id': note.id}})

点赞与取消点赞用同一套接口简化前端逻辑：

@notes_bp.route('/<int:note_id>/like', methods=['POST']) @token_required def toggle_like(current_user, note_id): note = Note.query.get_or_404(note_id) like = Like.query.filter_by(user_id=current_user.id, note_id=note_id).first() if like: db.session.delete(like) note.like_count = db.func.max(note.like_count - 1, db.literal(0)) else: db.session.add(Like(user_id=current_user.id, note_id=note_id)) note.like_count = note.like_count + 1 db.session.commit() return jsonify({'code': 0, 'data': {'liked': like is None, 'like_count': note.like_count}})

这段代码的核心价值在于，就是否点赞的两种状态做了原子切换，同时把计数维护在同一个事务里。

3.5 数据库迁移与初始化数据

模型定义好后，使用Flask-Migrate管理数据库结构变更：

flask db init flask db migrate -m "init tables" flask db upgrade

三个命令分别负责创建迁移目录、根据模型生成迁移脚本、将迁移应用到数据库。后续调整表结构时，重复执行后两步即可。需要注意，执行迁移命令前要先设置环境变量FLASK_APP=run.py，否则Flask不知道从哪个入口加载配置。

初始化数据也是不能忽视的一环。我写了一个seed.py脚本，数据内容包括管理员账号、图书分类、一批经典图书和几个示范读书笔记。这样系统跑起来后，前端页面有内容可看，不用每次临时手动录入。

4. Vue前端对接与联调

4.1 前端工程搭建与技术栈配置

前端工程我用Vite创建，相比Vue CLI，Vite的冷启动速度和热更新体验好很多：

npm create vite@latest frontend -- --template vue cd frontend npm install npm install axios vue-router@4 pinia

项目结构里views目录放页面组件，router目录配置路由表，api目录统一管理接口请求。Pinia可以管理登录状态和用户信息，避免跨页面传值。

4.2 axios请求封装与拦截器

所有请求统一走封装好的axios实例，核心是拦截器逻辑。请求拦截器负责从localStorage取token并注入请求头，响应拦截器负责统一处理后端返回的错误码，尤其是401场景：

import axios from 'axios' const service = axios.create({ baseURL: '/api', timeout: 8000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) service.interceptors.response.use( response => { if (response.data.code !== 0) { // 业务错误统一提示 return Promise.reject(new Error(response.data.msg)) } return response.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(error) } )

把401统一放在拦截器里处理，所有页面都不会出现重复代码，这是联调阶段最有价值的封装之一。

4.3 跨域问题的两种解法

前后端分离开发时，跨域是必然碰到的问题。前端开发服务器跑在5173端口，Flask跑在5000端口，两者直接请求会被浏览器拦截。我在项目中同时采用了两种方案：

方案一是Vite开发代理，在vite.config.js里配置：

export default defineConfig({ plugins: [vue()], server: { proxy: { '/api': { target: 'http://localhost:5000', changeOrigin: true } } } })

这样前端发/api/xxx请求，Vite会自动转发到后端5000端口，浏览器视角是同源请求，不会有CORS报错。方案二是后端配置Flask-CORS扩展，允许跨域：

from flask_cors import CORS CORS(app, resources={r"/api/*": {"origins": "*"}})

实际开发中，我推荐开发阶段用Vite代理，上线部署用Nginx统一转发，后端不要轻易全开CORS，减少不可控的风险。

4.4 页面组件与接口对接示例

以图书列表页为例，核心代码很简洁：

<script setup> import { ref, onMounted } from 'vue' import { bookList } from '@/api/books' const books = ref([]) const loading = ref(false) onMounted(async () => { loading.value = true try { const res = await bookList({ page: 1, size: 12 }) books.value = res.data.items } finally { loading.value = false } }) </script> <template> <div class="book-grid"> <BookCard v-for="book in books" :key="book.id" :book="book" /> </div> </template>

发布笔记页需要book_id和用户token，组件挂载时通过route.query或pinia存储读取。

4.5 前后端联调常见对接坑

联调过程中最容易出问题的地方主要有三个。第一个是字段名冲突，比如后端返回like_count，前端写成likeCount，列表页面看着像数字却统计不出来，排查半天发现是小驼峰命名的锅。我的建议是接口契约里统一用snake_case字段命名，前后端开发前把接口文档对齐。第二个是日期格式，后端返回UTC时间字符串，前端直接渲染会带个尾巴，格式化时要转本地时区。第三个是上传图片与静态文件路径，详见下一部分问题排查。

5. 常见问题与排查技巧实录

5.1 前端请求接口报CORS错误怎么处理

最典型的报错是一大段英文，核心是“has been blocked by CORS policy”。排查方向按顺序来：先确认开发期是否已经配置了Vite代理，如果用了代理浏览器里应该看不到跨域报错；再确认后端Flask-CORS是否挂上了；最后检查请求路径是否真的走到了代理规则覆盖的/api前缀。

有个细节需要特别注意：没有经过代理时，前端直接请求http://localhost:5000/api/xxx，后端CORS配置里的origins不能写*且同时带credentials: true，两者组合会被浏览器直接拦截。最简单的方案就是开发阶段全程走Vite代理，上线走Nginx。

5.2 flask db migrate检测不到模型变化

很多同学照着教程执行flask db migrate，发现生成的是空的迁移脚本。原因在于Flask-Migrate要读取模型类，而应用工厂里的模型模块没有被导入。解决办法是在app/__init__.py中显式导入model模块：

from . import models

另外确认环境变量FLASK_APP指向正确入口，Windows PowerShell下可以执行$env:FLASK_APP="run.py"，再执行迁移命令。

5.3 SQLite在并发写入时提示database is locked

本地开发用SQLite非常方便，但并发较高时会出现写入锁冲突。高校系统并发量并不高，但也有可能多个用户同时写入导致锁等待超时。两种处理办法：一种是SQLAlchemy连接串加上超时参数：

sqlite:///./app.db?timeout=15

另一种是直接切换MySQL，连接串改成：

SQLALCHEMY_DATABASE_URI = 'mysql+pymysql://user:password@localhost/reading_system?charset=utf8mb4'

如果项目计划部署上线，建议直接选用MySQL，SQLite在Windows生产环境下的文件占用和迁移权限问题会让你多踩不少坑。

5.4 图片上传后前端显示404

上传头像或图书封面最常出现的问题：文件已经保存成功，但访问地址返回404。原因通常是Flask默认只服务static目录下的静态文件，而上传目录在项目根目录的uploads文件夹中。解决方案是把上传目录配置为静态资源路径：

import os UPLOAD_FOLDER = os.path.join(os.path.dirname(__file__), 'uploads') app = Flask(__name__, static_folder='static', static_url_path='/static')

上传接口保存文件时，返回的URL建议采用/uploads/xxx.png形式，再为uploads目录挂一个静态视图或由Nginx直接映射该路径。如果你用Nginx部署，最简单的是把uploads目录软链到Nginx的静态根目录下。

5.5 JWT过期后前端页面不对用户做跳转

有一种情况是接口已经返回401，页面依然停留不动，用户以为系统瘫了。问题出在前端没有在拦截器统一处理401状态码，每个页面单独请求接口，失败了也不跳转登录页。解决方式就是文章前面提到的响应拦截器统一判断：

if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') }

再加一个优化点：axios拦截器处理401时，用一个全局标志位防止多个接口同时过期时反复跳转。这个细节在并发的管理后台请求中特别常见。

5.6 常见问题速查表

6. 部署上线与扩展方向

6.1 Nginx加Gunicorn部署Flask后端

本地调试通过后，部署是很多同学觉得陌生的一块内容。先说后端，Flask内置的开发服务器只适合调试，生产环境必须换成Gunicorn：

pip install gunicorn gunicorn -w 4 -b 127.0.0.1:5000 run:app

-w 4表示启动四个worker进程，能利用多核CPU提升并发处理能力。要注意run.py里是通过create_app()工厂创建应用实例的，Gunicorn加载入口时对应的是run:app，这个app就是工厂函数创建出来的实例对象。

6.2 Nginx统一托管前端与反向代理API

前端项目构建后生成静态文件，Nginx把它们托管起来，再通过反向代理把/api请求转发给Gunicorn：

server { listen 80; server_name your_domain; root /path/to/frontend/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:5000/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /uploads/ { alias /path/to/backend/uploads/; } }

这个配置的核心价值是：前端静态资源和后端API走同一个域，彻底解决跨域；同时图片和上传文件也有独立的静态映射路径。

6.3 后续功能扩展方向

项目跑通基础版本后，可以朝几个方向扩展。第一个是消息通知，新增系统通知表，用户被点赞、被评论时收到站内信通知。第二个是数据统计报表，管理后台增加按日活跃量、热门图书、笔记量趋势图表，这些用Vue的图表库很容易实现。第三个是阅读计划功能，用户可以选择图书设置每日阅读目标和完成进度，配合定时提醒，这能有效提升系统的用户粘性。

我个人的建议是：先别急着扩功能，把基础闭环打磨扎实。我在实际开发中体会最深的一点是，这个题目的难点从来不是某个框架的API记不记得住，而是能不能把“用户注册登录—检索图书—发布笔记—互动管理”这个完整业务闭环拆成数据库表、REST接口和前端页面三个层次。第一次做Flask加Vue前后端分离项目时，卡住我的不是写接口，而是联调时各种边界问题：跨域、token过期、时间格式不一致，单独开发都没事，一连起来全是事。

最后分享一个小技巧。前后端各模块开发前，先把接口文档按“路径、方法、请求参数、返回结构”四列写成表格，发给团队或自己留存。字段命名、状态码、时间格式提前统一，后面联调能省掉一大半沟通成本。项目做完后再回头看，你会发现这套读书分享系统不只是一份可以交作业的代码，更是训练工程化思维的一个好起点。