每年毕业设计季，总会有学弟学妹拿着同一个题目来找我：“学长，Node.js校园图书二手交易网站这个题目到底怎么做？”说实话，这个题目听起来很普通，但它绝不是简单套一个图书管理系统的模板就能蒙混过关的。它是一个带交易属性、带角色权限、带订单状态流转、还带文件上传和条件搜索的完整Web应用，毕设评分里最看重的综合能力点，它基本全占了。

这篇文章我把这个项目从头到尾拆开讲一遍，从选题逻辑、技术选型、数据库设计，到核心功能实现、前后端联调、论文写作和现场答辩，都会覆盖到。不管你是已经确定这个题目、正在写代码，还是刚拿到题目还没来得及动手，都能从里面找到可以“抄作业”的实操内容，也能避开我当年踩过的那些坑。

1. 项目定位、需求分析及功能边界

1.1 毕业设计选这个题，背后到底在考什么

每年计算机毕业设计的题目库中，“XX管理系统”占了很大比例，比如图书管理系统、学生管理系统、班级管理系统。但“校园图书二手交易网站”完全不是那个套路，它的核心差别在于带着“交易”二字。普通管理系统只需要做增删改查，而交易系统必须有商品发布、商品检索、下单、订单状态迁移、卖家确认、收货完成，还有用户权限划分。也就是说，它不只是数据层面的操作，而是流程层面的控制。

再从另一个角度看，这个题目的工作量是“弹性”的。基础版可以做成一个发布图书信息、展示图书列表、线下联系交易的小网站；升级版可以做登录鉴权、订单状态管理、图片上传、收藏功能、后台管理；进阶版甚至可以做站内消息通知、支付模拟、信用评价、定时任务。这个特点对毕业设计非常友好：学得扎实的同学能展示复杂业务建模能力，基础薄弱的同学也能先完成一个跑得通的版本。评分老师在验收时，通常不是看你是不是用了热门框架，而是看两条：第一，系统里的业务逻辑是不是完整闭环；第二，有没有思考过程和工作量体现。这个题目天然适合这两条标准。

还有一个现实原因：校园场景本身就是二手教材交易的高频场景。每到开学季和毕业季，学长学姐的书需要处理，学弟学妹需要低价教材，这叫真实需求。你把真实场景搬进系统里，需求分析写起来非常顺，答辩时老师说“为什么要做这个系统”，你不需要编一套空话。

1.2 用户角色与核心业务流程梳理

在写第一行代码之前，我建议你把角色和流程画在一张A4纸上。这个项目里至少有两种角色，如果你做了后台管理，就是三种：学生用户（包含买家和卖家身份）、管理员。

学生的核心操作路径是这样的：注册登录后，可以在“发布图书”页面填写书本信息，包括书名、作者、ISBN、原价、售价、成色、交易地点、封面图片，然后提交上架。其他学生可以在首页按照关键词、分类、价格区间来搜索图书，点进详情页看到卖家联系方式或留言按钮。如果用户看中这本书，可以点击“下单购买”，这时候订单状态变成“待卖家确认”。卖家登录后看到待确认订单，确认无误后点击“确认交易”，订单状态变成“待完成”。线下完成交付后，双方都可以在系统中确认完成，订单状态变成“已完成”。

这还没完，还有一个很容易被忽略的流程：图书库存状态。一本书从发布到被购买，它的状态要跟着变化。初次上架时是“在售”；被下单后应该锁定成“已预订”，防止别人下单同一本；卖家确认后是“已售”；如果用户取消订单或者卖家关闭订单，则回滚为“在售”。很多初次做这个题目的同学，把书挂在页面上就不管了，订单生成了但书还是可以被继续购买，这就是业务逻辑上的明显漏洞。答辩老师稍微一追问，项目就露馅。

管理员的职责通常是用户管理、图书管理、公告管理和基础的数据统计。图书管理不只是删除违规信息，还包括对敏感书名的审核下架、对重复发布内容的处理。用户管理至少要支持禁用账号。这些功能不复杂，但能体现出“权限”意识。

1.3 技术栈选择：为什么是Node.js，而不是Java或PHP

先说结论：如果这个题目放在五年前，大多数人会选Java Web或PHP；放在今天，Node.js是一个非常合理的选择，尤其适合毕业设计这个特殊阶段。

我的理由有四个。第一，语言心智负担低。JavaScript的内核语法相对简洁，你不需要花大量时间理解Spring里的IOC容器或事务传播机制，可以更专注于业务流程本身。第二，前后端语言统一。现在前端页面多多少少都要用一点JavaScript，你用Node.js做服务端，前后端都处在同一套语言体系里，联调时候排查代码逻辑会顺畅很多。第三，生态成熟。Express框架的中间件机制非常适合快速搭建REST API，Mongoose这种OOM工具也让MongoDB的操作变得像操作普通对象。第四，展示效果好。Node.js社区有大量轻量级库，比如用multer做上传、用jsonwebtoken做鉴权、用socket.io做消息推送，你可以利用这些库把系统扩展出很多亮眼模块，工作量却不会失控。

需要说明的是，Node.js并不适合非常高并发、强事务的场景，但对于校园二手交易网站这样的中小型应用绰绰有余。如果你所在学校更倾向于MySQL，那也可以使用Express + MySQL + sequelize的组合，逻辑大体一样，只是数据层换了一套库。我在下面的内容里主要以MongoDB为例展开，但整体的设计思路是通用的。

2. 数据库设计与工程初始化

2.1 核心数据模型及字段设计思路

我把数据库模型拆成五个核心集合：用户、图书、订单、收藏、留言公告。这里重点说用户、图书和订单三个。

用户集合的字段设计要精简但全面。包含用户名、学号（可选）、手机号、邮箱、密码哈希、头像URL、角色（user/admin）、信用积分或评价数、创建时间、禁用状态。手机号是交易双方线下联系的主要凭据，建议注册时必填，并在个人中心隐藏中间四位，保证隐私。密码字段绝对不能存明文，需要保存的是经过bcrypt加盐哈希后的字符串，这一点我在后面会详细展开。

图书集合是系统里最复杂的模型。除了书名、作者、出版社、出版年份、ISBN、原价、售价、描述、分类外，我还建议加入下面几个关键字段：cover（封面图路径）、images（多图数组）、condition（成色，比如九成新/有笔记）、campus（校区或交易地点字段）、status（在售/已预订/已售/下架）、seller（用户ID引用）、viewCount（浏览量）、createdAt。status字段特别重要，它是订单流程和图书列表展示的纽带。在列表页，你只需要查询status为“在售”的图书；在个人中心，用户可以查看自己发布的所有书及对应状态。

订单集合是偏交易系统的核心。字段包括orderNo（唯一订单号）、bookId、buyerId、sellerId、price（下单时的成交价）、status（待确认/待完成/已完成/已取消/已关闭）、remark（备注）、createdAt、updatedAt。这里有两点值得注意：第一，订单号不要用自增数字，可以用时间戳加随机数生成字符串，方便用户记忆和客服对单；第二，price字段要在下单时从图书的快照数据里拷贝一份，而不是在订单详情里实时去查图书表，因为卖家可能改价或折扣，但订单一旦生成，价格就要固定下来。

2.2 订单状态机设计

很多同学在实现订单模块时会陷入混乱，原因就是没有提前画状态机。我建议你把这个状态迁移图画在一张纸上，贴在你写代码时能看到的地方：

在售 --(用户下单)--> 已预订 --(卖家确认)--> 已售 ^ | |----(用户取消/超时)-----| 在售 --(卖家下架)--> 下架

订单部分对应的状态迁移更复杂一点：

待买家确认 --(确认订单)--> 待交付 | | | | (取消订单) (确认交付) | | v v 已取消 已完成

为什么非要设计成两段式？很多同学把订单做成“下单后立即成功”，这不符合二手交易的真实场景。二手交易有两个角色，买卖双方都需要对订单有掌控权。买家下单后，卖家可能发现这本书已经卖给别人了，所以需要“卖家确认”这一个闸门；确认后，双方线下见面交付，还需要“确认交付”这个动作来关闭订单。两段式状态机虽然只比“下单即成功”多看两个状态，但整条业务链的逻辑完整度完全不同。而且订单状态一旦复杂，你就能引出很多值得写进论文里的点：并发控制、状态校验、权限控制、数据一致性。

2.3 工程目录结构与初始化步骤

初始化项目不需要用什么重型脚手架，用npm初始化即可。这里给一个简洁但合理的目录结构：

book-secondhand/ ├── app.js // 服务入口，初始化Express ├── config/ // 配置项：密钥、数据库连接、上传路径 ├── models/ // Mongoose模型定义 │ ├── User.js │ ├── Book.js │ └── Order.js ├── controllers/ // 业务逻辑控制器 │ ├── userController.js │ ├── bookController.js │ └── orderController.js ├── routes/ // 路由定义 ├── middleware/ // 鉴权、错误处理中间件 ├── public/ // 前端静态资源 ├── uploads/ // 上传图片保存目录 └── package.json

初始化时，我用的是下面这组命令和依赖。先说基础依赖，后说开发辅助依赖：

npm init -y npm install express mongoose jsonwebtoken bcryptjs multer cors npm install nodemon --save-dev

• express：Web框架，提供中间件和路由
• mongoose：操作MongoDB的模型库
• jsonwebtoken：生成和校验JWT令牌
• bcryptjs：密码哈希加密，比纯md5方案可控得多
• multer：处理文件上传
• cors：解决开发阶段前后端分离的跨域问题
• nodemon：开发环境文件变更自动重启

在app.js里，最基本的中间件挂载顺序是：设置静态资源目录 -> 挂载cors -> 解析JSON请求体 -> 挂载路由 -> 定义错误处理中间件。静态资源目录要同时挂载public和uploads两个，否则前端页面里引用的图片路径会404。这个问题很多新手第一次跑通后端接口后就栽在那里。

3. 核心功能模块的实现细节与操作要点

3.1 用户登录注册与JWT会话鉴权

用户模块看起来是标准操作，但磨人的细节特别多。先说密码安全，这是我最想强调的一件事。如果你在BCrypt出现之前做过Web项目，一定用过MD5加盐的方案，后来发现彩虹表之类的东西很容易把普通密码破出来。BCrypt的设计初衷是故意让哈希计算变得慢，这样暴力破解成本直线上升。调用bcryptjs时，建议使用10到12的saltRounds，这是安全性和性能的平衡点。代码路由可以这样写：

const bcrypt = require('bcryptjs'); const saltRounds = 10; router.post('/register', async (req, res) => { try { const { username, phone, password } = req.body; if (!username || !phone || !password) { return res.json({ code: 400, msg: '参数不完整' }); } const hash = await bcrypt.hash(password, saltRounds); const user = await User.create({ username, phone, password: hash }); res.json({ code: 200, data: { userId: user._id }, msg: '注册成功' }); } catch (error) { res.status(500).json({ code: 500, msg: '服务器错误' }); } });

登录成功之后，服务端返回一个JWT令牌。JWT有一个好处和一个坏处：好处是服务端不用存会话记录，天然适合分布式；坏处是它一旦签发，在过期前无法服务端主动失效。对毕设项目来说，JWT完全够用，我建议把过期时间设为24小时，并让前端在axios拦截器里统一把token放到请求头。格式是“Authorization: Bearer ”。在服务端用一个中间件解析这个头，解析成功之后把用户ID挂到req上，后面每个需要鉴权的接口都可以直接拿到当前用户。很多同学问我为什么前端拿到了token之后，后面的接口还是总返回401，十有八九是请求头格式写错，或者中间件里校验了错误的字段。

3.2 图书发布、图片上传与封面路径

图书发布是用户最常使用的核心功能，它也是唯一一个涉及文件存储的模块。图片上传我用multer，存储方式选择diskStorage，把文件写到uploads目录下，文件名用时间戳加随机数重新生成，避免中文文件名乱码，也避免重名覆盖。一定要做三件事：限制文件类型白名单，限制单文件最大体积，给前端返回可访问的相对路径。代码如下：

const storage = multer.diskStorage({ destination: (req, file, cb) => { cb(null, path.join(__dirname, '../../uploads')); }, filename: (req, file, cb) => { const ext = path.extname(file.originalname).toLowerCase(); cb(null, Date.now() + '_' + Math.round(Math.random() * 1e9) + ext); } }); const upload = multer({ storage, limits: { fileSize: 2 * 1024 * 1024 }, fileFilter: (req, file, cb) => { const allow = ['.jpg', '.jpeg', '.png', '.webp']; const ext = path.extname(file.originalname).toLowerCase(); cb(null, allow.includes(ext)); } });

发布接口接收文本字段加封面文件字段。这里有一个坑：前端如果用FormData提交，req.body的字段和req.file不能直接混用，你需要分别取，再在控制器里拼接。发布成功后在数据库里保存的是books表的cover字段，值为“/uploads/xxx.jpg”。列表页只需要在img标签里引用这个路径即可。如果你做了前后端分离，而前端站点跑在8080端口，服务端跑在3000端口，你需要在图片URL前拼上服务端的地址，比如http://localhost:3000 + cover。

图书发布还有一个细节：在提交前，最好做ISBN的简单校验。ISBN-10和ISBN-13的校验规则并不复杂，但毕设阶段不需要把校验逻辑写得太复杂，只需要校验长度和数字格式即可，防止用户乱填。库存这个概念也要想清楚。系统本身不需要做真实库存扣减，但状态流转必须严谨。通过更新条件覆盖状态来防止重复下单，详见3.3。

3.3 交易流程与订单核心逻辑

交易模块是这个项目的心跳。刚才说过，一本书从“在售”到“已售”至少经过两个阶段。我先写下单这个动作的代码逻辑，让你直观理解并发控制的重要性：

const book = await Book.findOne({ _id: bookId, status: '在售' }); if (!book) { return res.json({ code: 400, msg: '这本书当前不可购买' }); } // 创建订单，同时把书锁定为已预订 const order = await Order.create({ ... }); await Book.updateOne( { _id: bookId, status: '在售' }, { status: '已预订' } ); // 还需要检查更新结果

这是一个典型的“先查后改”场景，在单用户操作时没问题，但如果两个用户同时点击购买同一本书，就可能出现两个订单都创建成功的情况。更稳妥的做法是用Mongoose的findOneAndUpdate把“条件更新”作为原子操作，先抢到状态变更的人才能创建订单：

const locked = await Book.findOneAndUpdate( { _id: bookId, status: '在售' }, { $set: { status: '已预订' } }, { new: true } ); if (!locked) { return res.json({ code: 400, msg: '这本书已经被预订了' }); } const order = await Order.create({ orderNo: 'B' + Date.now() + Math.random().toString(36).slice(-4), bookId, buyerId: req.userId, sellerId: locked.seller, price: locked.price, status: '待卖家确认' });

订单状态迁移也一样，每一次状态变更都必须在更新条件里带上“当前状态”，比如确认交付时，更新条件就必须是“状态=待交付，且操作者是买家”。这样哪怕页面被用户快速重复点击，也只会成功一次。这段逻辑还能带来一个额外的好处：在任何状态迁移发生之前，你都能通过条件判断当前状态是否合法，天然的防呆设计。

3.4 搜索、筛选、分页与索引优化

图书列表页不是无脑find出来全部数据，那样数据一多页面就会慢，答辩时也会被挑战。搜索接口需要支持几个维度：关键词（匹配书名、作者、出版社）、分类筛选、价格区间、上架状态。如果是MongoDB，关键词过滤用正则表达式即可：

const query = { status: '在售' }; if (keyword) { const regex = new RegExp(escapeRegex(keyword), 'i'); query.$or = [{ title: regex }, { author: regex }]; } if (category) { query.category = category; } if (minPrice && maxPrice) { query.price = { $gte: Number(minPrice), $lte: Number(maxPrice) }; } const books = await Book.find(query) .sort({ createdAt: -1 }) .skip((pageNum - 1) * pageSize) .limit(pageSize);

这里有个小坑：如果关键词包含正则特殊字符，比如“(”或“.”，不转义的话MongoDB会报错。所以自己封装一个escapeRegex函数，把/[.*+?^${}()|[]\]/g之前加上“\”。分页时要把total字段也返回给前端，方便前端计算总页数。条件多了之后，给常用的查询字段建立索引，比如status、category、seller，在集合数据量大了之后，查询速度会有明显提升。

搜索功能还有一个容易被忽略的点：前端输入框和URL参数要保持联动。用户搜索完“高等数学”，刷新页面后应该还停留在搜索结果页，关键词和页码都不丢失。这意味着前端要把query传给路由，而不是存到组件的state里就算了。答辩演示的时候，评委非常喜欢测试刷新页面后状态是否丢失，我这个坑就曾经当场踩过。

4. 前后端联调、接口规范与常见故障定位

4.1 REST接口设计与统一的返回结构

前后端联调是否顺畅，很大程度上取决于接口设计是否统一。我推荐使用REST风格，语义清晰，也符合大多数人的认知习惯。

每个接口的返回格式我建议统一为：

{ code: 200, msg: "success", data: ... }

code是业务状态码，200表示成功，其他数字表示失败。data是业务数据主体。这样前端不用每次判断HTTP状态码和业务状态码，只需读取code字段即可。HTTP状态码依然可以保留对应关系，比如401表示未登录、500表示服务端异常，但你可以在拦截器里做统一处理。

4.2 跨域、请求头与前端联调禁忌

前后端如果分端口开发，就会遇到CORS问题。在Express里引入cors中间件，配置origin为前端的地址，credentials按需开启即可。不要用“*”，因为之后如果带上Cookie，通配符就不会生效。我这里更推荐直接设置白名单。

跨域解决之后还有一个容易忽略的问题：预检请求。前端发一个带Content-Type为application/json的POST请求，浏览器会先发一个OPTIONS请求。如果你的后端没有对OPTIONS方法做处理，或者路由没有匹配到OPTIONS方法，前端会报“blocked by CORS policy”。Express的cors中间件通常会自动处理OPTIONS，但如果你用了自定义路由中间件，需要确保它放行OPTIONS。

联调时我最常看到的错误，是前端在获取列表数据时习惯用response.data来解析，但后端返回的数据包了一层code、msg、data，这样前端拿到的data其实是整个对象，数据层级就错了。不建议在每一个页面都去剥离一层data，最好对axios做一次封装，在响应拦截器里统一返回response.data，然后前端拿到的是{ code, msg, data }。这样做的好处是，所有接口调用时都只需要再取一层data即可，代码会干净很多。

还有一点需要提前设计：图片文件的请求路径。如果前端页面运行在8080，而图片资源在3000端口，那么img标签里写“/uploads/...”会指向8080端口，全部404。要么用绝对路径拼接，要么通过后端代理转发。对毕设项目来说，我建议前端页面和后端服务放在同一个域名端口下，使用Express托管静态文件，能少掉一半联调烦恼。

4.3 常见问题定位与排查思路

我把开发过程中最常见的故障现象汇总成一张表，这个表也可以直接放进毕业论文的“系统测试”章节里当素材：

这些内容看起来琐碎，但在答辩时，如果你能说出“系统测试中发现的上传失败问题是文件类型白名单导致的”，老师会觉得你做过真实测试，而不仅仅是把代码跑起来截了几张图。

5. 论文结构、演示Demo与答辩准备

5.1 毕业设计论文的骨架与写作重点

这个项目对应的论文，从结构上说和大多数Web类毕设类似：摘要、绪论、需求分析、系统设计、系统实现、系统测试、总结。但很多同学写出来的论文被批“像软件说明书”，原因是用大量篇幅贴代码截图，却很少交代思考过程。我建议走下面几条：

需求分析这一章，要写用户画像、业务流程、功能需求和非功能需求。特别是非功能需求，要有安全性（密码加密、权限控制）、性能（分页、索引）、易用性。老师很喜欢看到“对同一本书并发下单”这个场景的讨论，你可以直接把我们前面讲到的并发控制内容写进去。

系统设计这一章，画ER图和用例图就够了，不要过度堆图。ER图重点表现用户、图书、订单三者的关系，订单和图书是一对一还是多对一，用户和图书是一对多，这些关系在图上要画清楚。我见过很多同学把ER图里的关系线画反了，虽然答辩时没被揪出来，但论文评阅老师一眼就能看出数据建模功底。

系统实现这一章不需要贴完整代码，挑核心算法和关键实现讲。比如下单防重复设计、BCrypt密码加盐、JWT鉴权中间件、上传白名单，这些都是亮点。注意：论文里的代码不能像平时写代码一样堆满注释，建议只保留命名清晰、逻辑分明的核心片段，并在代码下方配上对思路的解释。

5.2 现场演示Demo的技巧与翻车点

毕设答辩的演示环节经常翻车，真不是代码问题，而是准备不足。我建议你提前一周就定好演示脚本，不能用真实数据临时操作，要准备一套演示账号和一批演示图书数据。演示账号至少两个：一个是普通学生用户，一个是管理员。演示图书数据建议有七八本，书名覆盖不同专业，这样才能体现搜索的多样性。

演示前把浏览器缓存清掉，数据库里把冗余数据清理干净。现场网络不稳定是常态，如果你把图片放在外链，可能出现图片加载不出来。我建议所有演示资源放本地，所有环境变量在本地配置好，不要现场把服务器启动时到处找配置。

演示节奏也有讲究。不要从一个函数开始讲代码，要从用户场景开始：比如“我作为大三学生，想找一本操作系统教材”。先演示注册、退出，再登录管理员演示管理端。这样老师跟着故事走，容易理解系统定位。我在演示时最自豪的一个细节是，下单时故意把网络调慢一点，让“状态锁定”的转场被看见，老师能直观理解这本书已经被预定了。这些小设计，远比照着PPT念十页要有感染力。

5.3 答辩高频追问与参考应答思路

答辩时老师大概率会问下面几类问题，提前准备好就行：

“为什么选用MongoDB？” 回答要点：图书的字段可能会动态扩展，文档型数据库适合这种场景；同时通过Mongoose能快速完成建模，提升开发效率。如果真的对MongoDB不熟，可以承认更成熟的关系型方案，但补充说明使用Mongoose做了一个简单的数据访问层封装，后期要切换MySQL理论上更容易替换。

“订单并发时如何保证一致？” 回答要点：先查再更改为条件更新，用findOneAndUpdate锁定图书状态，再加上订单号生成保证唯一，双重防止重复下单。

“JWT过期后怎么办？” 回答要点：JWT过期后前端后端都会收到401，处理方式是让用户跳转登录页重新登录。如果将来想改善体验，可以加刷新令牌机制，但毕业设计现场不用展开。

“你项目的难点是什么？” 这个不能回答说“没有难点”，也不能说“没有难点，都很简单”，那是给自己挖坑。可以挑一个自己真正解决过的小问题，比如上传文件类型校验，或者前端历史记录和搜索参数联动。

6. 避坑清单与项目扩展方向

6.1 代码实现阶段最容易踩的坑

写代码阶段我踩过的几个比较深的坑，这里逐个分享。第一个是Mongoose默认id和前端字段映射问题。前端处理数据时，习惯于item._id去拿到ID，但如果你在模型中定义了自定义主键字段，比如bid，那么通过item._id访问不了。建议你从项目最开始就明确一套：数据库主键用Mongoose默认的_id，业务编号用订单号orderNo，不要让两个概念混在一起。

第二个坑是统一错误处理。很多初学者的代码里每个控制器都有一大段try...catch，非常冗余，而且漏掉一个catch就可能导致进程崩溃。我建议用一个统一的asyncHandler中间件包住所有异步路由，然后集中处理错误。这样代码里冒烟测试时排查问题会省力很多。

第三个坑是删除和假删除。图书被某个订单关联时，物理删除会导致订单详情里显示不了图书信息，从而出现数据不一致。我建议“下架”而不是删除，“禁用”而不是删除用户。数据库里保留记录，只是通过status字段控制可见性。这也更符合真实二手平台的做法，论文里可以写“数据保留策略”。

6.2 如何把普通毕设升级成有亮点的作品

这个题目常见，所以如果你只是把基础CRUD做完，很难拿高分。但也不需要把毕设做得像工业级系统，只需要增加两三个小而亮的功能，就能在答辩时拉开差距。我根据自己的答辩经历给出几个可落地的方向：

第一，增加消息通知。当买家下单后，给卖家发送一条站内消息，提醒“您有一本XX被下单”；卖家确认后，给买家发送通知。最简单的消息模块就是一张通知表加一个列表页面，开发成本很低，但能大幅度提升系统的真实感。

第二，增加收藏功能。用户在看到一本书时点击收藏，在个人中心查看收藏列表，点击可跳转详情。这个东西逻辑极其简单，却能体现“你在替用户考虑”。

第三，增加简单数据统计。管理员后台放几个图表，展示今日发布图书数、累计订单数、各分类图书占比。你可以不用引入专门图表库，用Canvas简单画柱状图即可，但要注意展示的数据要和真实数据库联动，不要写死。

6.3 从毕设到项目的延伸思考

做完这个项目，你会发现毕业设计只是第一步。如果还有精力，把系统部署到云服务器上，写一个简单的部署文档，包括环境安装、项目依赖、PM2启动、Nginx反向代理，这本身就是非常宝贵的实践经验。很多同学用GitHub时只会把整个项目带上node_modules一起传上去，这些都是细节上体现专业感的地方。

部署完成后你会遇到一个之前完全没接触过的问题：MongoDB如何远程访问、服务器端口如何开放、上传目录的权限怎么设置。这些问题比对PPT还难，但它们恰恰是企业开发中最常见的内容。如果你的毕设答辩时间允许，把这些经验在“总结与展望”里写上一段，老师会非常认可。毕设只是一个阶段，这之后你能把动手能力延续到什么程度，才是这个专业真正拉开差距的地方。

最后分享一个我自己用着很顺手的做法：在答辩前一天，把整个项目的数据库导出成一份带演示数据的备份文件，存到U盘里。万一现场数据库连不上，直接恢复一份再起来，全程不超过两分钟。这个备用方案救过我一次，也希望你们都用不上，但一定要准备。