二手书交易平台这种题目，算是计算机毕业设计里长盛不衰的经典款。每年都有大量同学选它，因为场景足够贴近生活，功能拆解起来也清楚，难易度刚好在一个“认真做完能学到东西，但不会做不出来”的位置上。如果你拿到的题名是“NodeJS二手书籍交易平台”，那我可以负责任地说，这个选题下限有保底、上限也够你发挥，关键是看你怎么把Node.js这一套技术栈真正吃透并用起来。

1. 项目动机与需求拆解

1.1 为什么二手书交易是个好选题

大学校园里教材迭代快，考研考公的资料一年一换，毕业生离校前大量书籍无处安放，而新生开学又需要低成本获取学习资料——这个供需链天然存在。相比闲鱼这类综合平台，校园场景下的二手书交易有几个明显特点：同城交易方便、信任成本相对低、书籍分类清晰（教材、考试资料、小说、专业书）、客单价低但频次不均匀（开学季、期末季是高峰）。

从毕设角度说，这个选题的好处在于：功能模块边界明确，用户端要买书卖书、管理端要审核管理，权限体系一拆就明白；业务流程不算复杂，但又有核心的订单状态流转可以深挖；数据模型清晰，用户、图书、订单、收藏这几个核心实体就是整个系统的主干。认真做下来，前端后端都能展示出工作量。

1.2 核心角色与功能边界

这套系统的用户模型拆成三种角色：游客、注册用户、系统管理员。各自权限边界我用一张表理清楚：

这个权限设计其实是模拟现实中平台“轻监管”的定位：用户自主发布、自主交易，管理员只做违规内容和风险订单的处理。这样既控制复杂度，又能让管理端有实际功能可做，而不是摆设。

2. 技术选型与架构设计

2.1 为什么是Node.js

题目已经把技术栈定在了Node.js这边，这是好事。Node.js做毕设项目有几个实际优势：

第一，语言门槛低。如果你已经学过JavaScript，那前后端可以共用一种语言，思维切换成本低。很多同学选Java要做Spring Boot那一套配置，光环境问题就能卡好几天；Node.js这边npm装好依赖就能跑起来。

第二，生态成熟。做Web平台无非就是HTTP服务、路由、数据库操作、文件上传、用户鉴权这几件事，npm上的Express、Mongoose、jsonwebtoken、multer这些库都是久经考验的稳定方案。

第三，异步模型贴合IO密集场景。二手书平台这种应用，大量操作是读数据库、查图片、传JSON，属于IO密集而不是计算密集，Node.js的事件驱动模型在这个场景下性能完全够用。

2.2 整体架构：前后端半分离

毕设项目我不推荐搞太重的微服务架构，但要完全套模板渲染也有点落后。折中方案是：后端用Express提供RESTful API返回JSON，前端页面用服务端模板引擎（如EJS）加少量原生JavaScript或Vue CDN来做交互。

为什么这么选？

• 全用前后端分离（Vue + Node API）固然现代，但意味着你要维护两套工程、处理跨域、额外打包，对毕设节奏来说负担偏重；
• 全用服务端渲染（EJS模板）又不太好展示你“有API设计能力”；
• 半分离方案是：用户浏览页面由模板引擎渲染，登录注册、订单操作、图书发布这些交互动作通过fetch或axios调用接口完成。

这套做法的实际好处是：你既能在答辩时讲清楚RESTful API的设计思路，又不必额外花时间搭前端构建工具链，工作量刚好控制在毕业设计的合理范围。

2.3 数据存储方案：MongoDB还是MySQL

Node.js的天然搭档是MongoDB，Mongoose这个ODM用起来非常顺手。但也有不少学校老师更认可关系型数据库，感觉MySQL“严谨”。我的建议是：看题目要求，题目没硬性规定就用MongoDB，理由有三：

• 图书信息字段不固定（有的书有ISBN，有的没有；有的有出版社，有的只有作者），文档型数据库不用频繁改表结构；
• 对毕设来说，JSON格式的查询结果和JavaScript对象直接互通，少一层转换；
• MongoDB的聚合管道做统计（比如管理端要按分类统计图书数量）非常直观。

但如果你所在学校老师明确要求关系型数据库，或者你感觉用MySQL自己心里更踏实，那Node.js配MySQL也完全成熟（mysql2 + sequelize），不必担心。

我下面讲的实例是以MongoDB + Mongoose为主，不过核心的接口设计和业务逻辑思路是通用的。

3. 数据库设计与核心数据模型

3.1 用户集合（User)

{ username: { type: String, required: true, unique: true }, password: { type: String, required: true }, // bcrypt加密后的密文 nickname: { type: String, default: '' }, avatar: { type: String, default: '' }, // 头像URL phone: { type: String, default: '' }, role: { type: String, enum: ['user', 'admin'], default: 'user' }, status: { type: Boolean, default: true }, // false表示被封禁 credit: { type: Number, default: 100 }, // 信用分，违规扣分 createdAt: { type: Date, default: Date.now } }

这里有几个设计要点要展开说：

密码绝对不能明文存，连毕设也不能。用bcrypt库做哈希加密，bcrypt是自带盐的，同一个密码每次加密结果都不同，安全性远好过MD5这种可查表破解的方案。实际调用就一行：bcrypt.hashSync(password, 10)。

status字段是给管理员用的。出现恶意用户或者交易纠纷比较多的账号，可以直接封禁，封禁后该用户无法登录。

credit信用分是加分项设计。可以做成：用户被投诉一次扣10分、完成一笔交易加1分，低于60分限制发布。这种细节说出去会让评委觉得你想到了实际业务中的问题。

3.2 图书集合（Book)

{ title: { type: String, required: true }, // 书名 author: { type: String, default: '' }, isbn: { type: String, default: '' }, category: { type: ObjectId, ref: 'Category' }, // 关联分类 description:{ type: String, default: '' }, // 书籍描述 condition: { type: Number, min: 1, max: 10 }, // 成色评分 1~10 originalPrice: { type: Number, default: 0 }, // 原价 price: { type: Number, required: true }, // 二手售价 coverImage: { type: String, default: '' }, images: [String], // 多图支持 seller: { type: ObjectId, ref: 'User' }, // 卖家ID status: { type: String, enum: ['on_sale', 'reserved', 'sold', 'off_shelf'], default: 'on_sale' }, browseCount: { type: Number, default: 0 }, createdAt: { type: Date, default: Date.now } }

图书状态机是整个系统的关键。一本二手书的生命周期是：on_sale（在售）→ reserved（已预约/锁定）→ sold（已成交），或者由卖家主动操作off_shelf（下架）。为什么要多一个reserved状态？因为真实交易场景里，买家下单后需要时间线下联系、当面交易或者邮寄，这段时间不能让其他买家再下单——人与人之间有先来后到，系统中要有锁定机制。

seller字段关联用户，查询时用.populate('seller', 'nickname phone')把卖家信息带出来，这样详情页可以直接展示卖家昵称和联系方式。

browseCount用来做热榜排序，管理员首页可以展示“浏览最多的10本书”，这个数据也能在写报告时当亮点。

3.3 订单集合（Order)

{ orderNo: { type: String, required: true, unique: true }, // 订单编号，如20240601+时间戳 book: { type: ObjectId, ref: 'Book' }, // 买的哪本书 seller: { type: ObjectId, ref: 'User' }, buyer: { type: ObjectId, ref: 'User' }, price: { type: Number, required: true }, // 成交价，下单时的快照 status: { type: String, enum: ['pending', 'completed', 'cancelled', 'refunded'], default: 'pending' }, contactPhone: { type: String }, // 买家的联系电话，自填 remark: { type: String, default: '' }, createdAt: { type: Date, default: Date.now }, completedAt: { type: Date } }

price字段要特别注意，它必须是下单那一刻的成交价快照，而不是通过查询图书表动态获取的价格。因为卖家可能在买家下单后就修改了这本书的价格，如果我们动态取价，订单金额就会飘——这在实际交易系统中是大忌。

3.4 收藏与评论

收藏（Favorite）是个简单的关联表：{ user, book, createdAt }，唯一索引{ user: 1, book: 1 }防止重复收藏。

评论（Comment）建议做成非必须模块。如果时间紧张，评论功能可以精简成“留言/笔记”的形式，即买家下单后可以给卖家留言备注，而不是公开评论——这样更贴近校园二手交易的交流模式，同时避开公开评论的审核问题。

4. 核心功能模块与接口设计

4.1 用户认证：JWT方案

现代Web应用做登录鉴权，JWT（JSON Web Token）是主流方案。思路是：用户登录成功后，后端生成一个签名字符串返回给前端，前端在后续请求时把它放进请求头Authorization: Bearer <token>，后端用中间件解析token，识别当前用户身份。

在Express里实现非常直接：

// 生成token const jwt = require('jsonwebtoken'); const token = jwt.sign( { userId: user._id, role: user.role }, process.env.JWT_SECRET || 'your-secret-key', { expiresIn: '7d' } ); // 鉴权中间件 function authMiddleware(req, res, next) { const header = req.headers.authorization || ''; const token = header.startsWith('Bearer ') ? header.slice(7) : null; if (!token) return res.status(401).json({ message: '未登录' }); try { const decoded = jwt.verify(token, process.env.JWT_SECRET || 'your-secret-key'); req.userId = decoded.userId; req.userRole = decoded.role; next(); } catch (e) { return res.status(401).json({ message: '登录状态已失效' }); } }

注意JWT_SECRET不能写死在前端代码里，在毕设里可以和演示环境共用同一个常量，但配置文件要单独放出来，答辩的时候可以提一句生产环境的密钥应该走环境变量管理。

token过期时间设置7天，对毕设项目来说体验和安全的平衡点比较合适。设置太短会让用户频繁登录，太长了则有安全隐患。

4.2 图书发布与图片上传

发布图书的页面是买家端最重要的表单，涉及的文件上传这一块最容易出坑。我的建议是用multer库，它会处理multipart/form-data格式的上传请求，保存图片到本地的uploads目录，然后返回可访问的URL。

const multer = require('multer'); const path = require('path'); const storage = multer.diskStorage({ destination: function(req, file, cb) { cb(null, path.join(__dirname, '../public/uploads/')); }, filename: function(req, file, cb) { const uniqueName = Date.now() + '-' + Math.round(Math.random() * 1e9); const ext = path.extname(file.originalname); cb(null, uniqueName + ext); } }); const upload = multer({ storage: storage, limits: { fileSize: 5 * 1024 * 1024 }, // 单张限制5MB fileFilter: function(req, file, cb) { if (/^image\/(jpeg|png|webp|gif)$/.test(file.mimetype)) { cb(null, true); } else { cb(new Error('仅支持图片文件格式')); } } }); // 路由中使用 router.post('/books', authMiddleware, upload.array('images', 5), bookController.createBook);

这里三个细节直接关系到能不能正常跑起来：

• public/uploads目录必须提前创建好，代码不会自动帮你建目录；
• Express要挂载静态资源：app.use('/uploads', express.static(path.join(__dirname, 'public/uploads')))，否则前端拿到/uploads/xxx.jpg这个路径根本访问不到文件；
• 文件名用时间戳+随机数拼出来，避免中文文件名和重名覆盖问题。

4.3 图书检索与筛选

二手书平台的搜索场景比一般电商简单，前端给一个关键词参数就够，但后端查询要支持多种条件组合：

// GET /api/books?keyword=JS&category=60f7c3&minPrice=10&maxPrice=50&sort=price_asc&page=1&pageSize=12 const query = { status: 'on_sale' }; if (req.query.keyword) { const keyword = req.query.keyword.trim(); query.$or = [ { title: new RegExp(keyword, 'i') }, { author: new RegExp(keyword, 'i') }, { isbn: new RegExp(keyword, 'i') } ]; } if (req.query.category) { query.category = req.query.category; } if (req.query.minPrice || req.query.maxPrice) { query.price = {}; if (req.query.minPrice) query.price.$gte = Number(req.query.minPrice); if (req.query.maxPrice) query.price.$lte = Number(req.query.maxPrice); } let sort = { createdAt: -1 }; if (req.query.sort === 'price_asc') sort = { price: 1 }; if (req.query.sort === 'price_desc') sort = { price: -1 }; if (req.query.sort === 'hot') sort = { browseCount: -1 }; const page = Math.max(parseInt(req.query.page) || 1, 1); const pageSize = Math.min(parseInt(req.query.pageSize) || 12, 50); const books = await Book.find(query) .populate('seller', 'nickname avatar') .populate('category', 'name') .sort(sort) .skip((page - 1) * pageSize) .limit(pageSize); const total = await Book.countDocuments(query);

用RegExp(keyword, 'i')做模糊搜索，性能对毕设数据量完全没问题。如果要追求更专业的方案，也可以引入MongoDB的文本索引，但对一个几千条数据的平台来说属于杀鸡用牛刀。

还有一个细节：列表页默认只查status: 'on_sale'，这就保证了下架的和已售的不会出现在前台。卖家自己的“我发布的”页面则用另外的接口去查，不受这个过滤条件限制。

4.4 下单与流程状态流转

买家点击“立即购买”后，后端要做的事不只建一条订单记录。核心代码如下：

async function createOrder(req, res) { const { bookId, contactPhone, remark } = req.body; const book = await Book.findById(bookId).populate('seller'); // 校验：书是否存在、是否在售 if (!book || book.status !== 'on_sale') { return res.status(400).json({ message: '该图书已下架或已售出' }); } // 校验：不能买自己的书（除非你想展示这个逻辑错误） if (book.seller._id.toString() === req.userId) { return res.status(400).json({ message: '不能购买自己发布的图书' }); } // 生成订单号：时间戳 + 随机数 const orderNo = Date.now().toString() + Math.floor(Math.random() * 1000); // 创建订单 const order = await Order.create({ orderNo, book: book._id, seller: book.seller._id, buyer: req.userId, price: book.price, contactPhone, remark, status: 'pending' }); // 锁定图书 book.status = 'reserved'; book.reservedBy = req.userId; await book.save(); res.json({ message: '下单成功', orderId: order._id }); }

为什么下单后要同步把书改成reserved？这是整个系统最关键的一步，不做的话就会出现“两双眼睛盯上同一本书”的问题——两个买家同时下单，订单都建成功了，但书只有一本，后面肯定要扯皮。顺序是先建订单再锁书，这个顺序保证了任何时刻最多只有一笔有效订单能锁定同一本书。

图片上给买家展示的是“已下单”，给卖家展示的是“有买家啦，请尽快联系”。等双方线下完成交易，由任意一方点击“确认完成”，订单流转为completed，图书状态变为sold。

4.5 管理端功能

管理端的接口要单独校验admin角色，可以用一个adminMiddleware套在authMiddleware外面，也可以直接在路由上写router.get('/admin/stats', authMiddleware, requireAdmin, adminController.getStats)。

管理后台核心功能我建议做成这四块：

• 用户管理：筛选用户、查看用户发布的图书数量、封禁/解封用户；
• 图书管理：按关键词/分类/状态筛选图书、强制下架违规图书；
• 订单管理：查看全部订单状态流、处理纠纷标记（如果时间够）；
• 数据概览：图书总数/用户总数/成交订单数/成交金额，用MongoDB聚合管道统计。

聚合统计示例：

const dashboardData = await Promise.all([ User.countDocuments(), Book.countDocuments(), Order.countDocuments({ status: 'completed' }), Order.aggregate([ { $match: { status: 'completed' } }, { $group: { _id: null, totalSales: { $sum: '$price' } } } ]) ]);

这个统计结果可以直接给管理端首页的四个数字卡片用，实现成本低，展示效果却很好。

5. 目录结构与实现细节

一套清晰的目录结构，不仅自己写代码舒服，答辩和写报告的时候也容易讲清楚层次。我推荐这种组织方式：

nodejs-book-platform/ ├── app.js # 应用入口，配置中间件、路由挂载 ├── config/ │ └── db.js # 数据库连接配置 ├── models/ │ ├── User.js │ ├── Book.js │ ├── Category.js │ └── Order.js ├── routes/ │ ├── auth.routes.js # 注册/登录 │ ├── book.routes.js # 图书CRUD/搜索 │ ├── order.routes.js # 下单/订单管理 │ ├── favorite.routes.js # 收藏/取消收藏 │ └── admin.routes.js # 管理端接口 ├── controllers/ │ ├── auth.controller.js │ ├── book.controller.js │ ├── order.controller.js │ ├── favorite.controller.js │ └── admin.controller.js ├── middlewares/ │ ├── auth.middleware.js │ └── upload.middleware.js ├── public/ │ ├── css/ │ ├── js/ │ └── uploads/ ├── views/ │ ├── index.ejs │ ├── detail.ejs │ ├── publish.ejs │ ├── profile.ejs │ └── admin.ejs ├── .env # 环境变量（密钥、端口、数据库地址） └── package.json

这个结构的核心思想是路由只做转发，不写业务逻辑；控制器处理请求与响应，调用模型层拿数据。哪怕代码量不大，这种分层的架构意识在答辩时非常加分——很多同学一上来把全部逻辑堆在入口文件里，老师一看就问“如果模块多了怎么维护”。

数据库连接写在config里，app.js入口通过mongoose.connect来连接：

const mongoose = require('mongoose'); const dbUrl = process.env.MONGODB_URI || 'mongodb://127.0.0.1:27017/book_platform'; mongoose.connect(dbUrl, { useNewUrlParser: true, useUnifiedTopology: true }).then(() => console.log('数据库连接成功')) .catch(err => { console.error('数据库连接失败：', err.message); process.exit(1); });

注意MongoDB的地址我写的是127.0.0.1而不是localhost，这是因为在本机环境里localhost可能被解析成IPv6地址::1，偶发情况下MongoDB没监听IPv6会导致连接失败，这个坑我见过很多次。

6. 部署与演示环境搭建

6.1 本地开发环境

• Node.js 14 以上版本（推荐用LTS版，不要追最新）
• MongoDB 4.4及以上（本地安装或用Docker跑都行）
• 开发工具随意，VS Code顺手就行

启动流程三步：

npm install mongod --dbpath ./data/db # 启动数据库 npm run dev # 热更新启动服务，需要nodemon

建议package.json里配好开发脚本：

"scripts": { "start": "node app.js", "dev": "nodemon app.js", "seed": "node scripts/seed.js" }

种子脚本seed.js用来初始化管理员账号和几个分类数据，这个一定要写。因为演示的时候不可能现场注册分类、现场发布几十本书，提前用脚本塞好数据，演示直接展示一个内容丰富的平台，观感完全不同。管理员账号建议设成admin / admin123，答辩时输入方便。

6.2 生产环境部署建议

如果老师要求线上演示，不要自己去买昂贵的云服务器——轻量应用服务器完全够用了。部署的常规路径是：服务器装好Node和MongoDB，拉取代码，npm install --production，用PM2守护进程：

pm2 start app.js --name book-platform pm2 status

再配个Nginx做反向代理和静态资源服务，把/uploads/和静态CSS/JS交给Nginx处理，Node只负责API。这个其实不是必须的，本地直接node app.js也能演示，但答辩时能说出来“生产环境我会用PM2做进程守护，Nginx处理静态资源和反向代理”，说明你理解真实部署链路。

7. 常见问题与排查技巧

7.1 数据库连接失败的排查

这个错误出现频率最高。排查顺序是这样：

• mongod进程是否在跑？Mac/Linux可以用pgrep mongod或者ps aux | grep mongo看，Windows用任务管理器看；
• 连接的端口是否正确？MongoDB默认27017，如果改过端口，连接串里也要对应改；
• 有没有报Authentication failed？MongoDB默认不开启认证，如果开了要带上用户名密码；
• 防火墙会不会拦截？本机开发基本不涉及，如果是部署在云服务器才考虑端口组策略。

7.2 前端图片不显示

图片404是高频问题，原因通常是这个顺序里的某一个：

• uploads目录不存在。解决：手动创建public/uploads，或者fs.mkdirSync做目录初始化；
• Express没有挂载静态资源中间件。缺了app.use('/uploads', express.static(...))，前端能请求到路径但后端不认这个路由；
• 图片上传到了本地但访问URL是HTTP外网地址。开发时可以用相对路径/uploads/xxx.jpg，前端拼接服务器地址；
• multer的destination配置写的是相对路径，但进程工作目录和你以为的不一样。建议用path.join(__dirname, ...)确保路径绝对正确。

7.3 跨域问题

半分离架构如果前端页面和后端服务同源（同一个端口），就没有跨域问题。但如果你本地开了两个端口，一个前端一个API，就会遇到CORS报错。最简单的解法是在app.js里临时加一个允许跨域的中间件，或引入cors包：

const cors = require('cors'); app.use(cors());

7.4 密码加密后无法登录

排查点：注册的时候用的是bcrypt.hashSync(password, 10)，登录比对用的是bcrypt.compareSync(inputPassword, user.password)——compare的第一个参数一定是用户传入的原始密码，第二个参数是数据库里存的哈希串，顺序反了就永远登录不上。另一个坑是如果数据库里存的还是明文（早期测试数据），排序或者过滤的时候可能忘了同步处理，导致旧数据无法登录。建议直接写个迁移脚本清掉老测试数据或者重新跑种子脚本。

7.5 图书状态不同步

下单成功了，但图书还是显示“在售”，或者书显示“已卖出”但订单还在pending。原因一般是忘了在某个流程里更新状态。把状态流转规则写在代码注释里，每次动到状态的地方都检查一遍：

• 下单成功：Book.status → reserved
• 完成订单：Book.status → sold
• 取消订单：Book.status → on_sale
• 卖家手动下架：Book.status → off_shelf

任何一步漏了，前后台数据就会对不上。排查这种问题最实用的方法是看MongoDB里的原始数据，而不是只看页面表现。

8. 演示与答辩经验

8.1 演示流程设计

我见过太多同学答辩时拿着项目从头到尾点一遍，评委看得昏昏欲睡。好的演示设计应该像讲故事——先制造矛盾，再展示解决方案。

我的建议是设计一个完整的交易闭环：注册一个新用户（或者用种子用户）→ 登录 → 发布一本书（现场填表单，展示信息校验和图片上传）→ 在首页搜到这本书 → 另一个用户（事先登录好的窗口）下单 → 原用户收到订单提醒 → 点击完成订单 → 查看个人主页，书已标记为“已出售”。这样一个闭环走下来，系统所有核心模块都被覆盖到了，评委也能跟着你的节奏理解业务逻辑。

还可以加一个亮点演示：在管理端展示数据统计卡片和用户封禁功能——封禁一个用户，然后当场用那个账号登录，登录报错“账号已被封禁”，这个对比效果非常好。

8.2 答辩问题预判与加分项

老师大概率会问这几类问题，提前准备答案：

• “为什么选MongoDB而不是MySQL？”——回答不一定要站队，但要能对比分析：文档模型对变长字段友好、开发效率高、聚合管道方便统计；短板是事务一致性不如关系型，但二手书交易对一致性要求没那么高。能说出权衡过程，比无脑说“我觉得MongoDB好”强十倍。

• “订单并发冲突怎么解决？”——我们已经用状态锁机制解决了核心问题，可以讲：下单时原子更新findOneAndUpdate配合状态条件，保证同一本书不会被下两单。“我做了一个原子的状态更新：where({_id: bookId, status: 'on_sale'}).update({status: 'reserved'})，如果更新的影响行数为0，说明已经被别人抢了。”

• “密码安全怎么做的？”——bcrypt加盐哈希，库层面做好数据库访问控制，生产环境JWT密钥走环境变量。答得简而准。

• “后续可以怎么扩展？”——可以讲：接入支付宝/微信支付完成线上交易、增加站内信协商沟通机制、引入推荐算法按浏览历史推荐图书、增加学区范围内的地理围栏功能。只要听起来合理且有逻辑，老师就会觉得你有独立思考。

表现细节方面，数据预热非常重要。演示前用种子脚本生成20本以上分布合理的图书数据，最好覆盖几个热门分类，搜索结果不要空荡荡的。图片也要准备真实的书籍封面图，不要用占位图，或者用一些免费图库的真实书封图片。

9. 我自己做完这个项目的体会与调试心得

这个项目做完之后最大的收获是对数据模型的理解上了一个台阶。以前写代码总是跟着页面走——先想做哪个页面，再去写对应的表和接口——做完这个项目以后反过来：先把核心实体和状态搞清楚，页面都是数据的投影而已。

调试过程中有几个经验想分享给后来者。

一定要学会看日志和数据库状态，不要靠猜。有一次订单一直创建失败，前端给我报“已售出”，但页面明明显示在售。我花了四十分钟排查，最后发现是测试环境里有一条reserved状态的脏数据（早期手动造数据时改状态改岔了），而普通列表页按on_sale过滤，自然就显示正常。从那以后我在开发时养成了一个习惯：遇到状态问题，第一时间用mongosh查一下这条记录的status字段到底是什么，所有问题其实都在数据里。

写代码之前先把状态机画清楚，胜过写一千行代码。我一开始没做这个工作，结果订单模块改了好几版，每次总有几个边界情况漏掉（比如卖家取消订单不过流、买家下单后卖家把书下架了怎么办）。把状态流转图画全之后，代码反而越写越顺。推荐你也先把这些极端情况理顺再动手：

• 买家下单选了reserved的书 → 提示已被别人锁定
• 买家下单后卖家把书下架 → 创建订单前校验状态，此时应该拒绝
• 卖家下架的书被买家收藏着 → 收藏列表要标记“已下架”，不能跳转到详情页报错

不要迷信“中间件越多越高级”。有个阶段我给系统加了大量自定义中间件做权限校验、日志记录、参数格式化，刚开始觉得很爽，后来发现出问题时需要排查的链路变长了。中间件本身没问题，但不要过度设计，每个中间件都应该有明确职责。毕业设计项目，保持“Router → Middleware → Controller → Model”这条链路干净就够了。

重构永远是值得的，至少提前两到三天做最终整理。答辩前我用了三天时间整理代码：删掉无用的console.log和注释块、把魔法数字提取成常量、路由命名归一、补充缺失的错误处理。这些工作不加新功能，但答辩时老师翻代码的感受完全不一样——整洁的代码本身就是一种证明。

如果把这套系统继续往前推，我下一版想加的能力是：站内私信协商、卖家信用评价、以及基于同校学生身份的学生认证。认证成功后可以看对方的校内身份标识，能进一步降低交易中的信任门槛。这些想法你哪怕只实现一个，答辩时都足够成为独特的记忆点。