做毕设选型的时候，纠结是一件特别正常的事。基于Node.js的微信小程序美食点评系统，是我这几年看下来投入产出比很稳的一个选题方向。它既有用户端的完整交互，也有后端的真实接口逻辑，做出来之后不管是答辩演示还是作品集展示，都比单纯的静态页面要有分量得多。这个项目要解决的问题很明确：让用户在小程序里浏览餐厅、查看评分和用户评价，能按分类和关键词搜索，还能自己发评价、收藏喜欢的店，把“找店—看评—评价—收藏”这条闭环完整跑通。
谁适合参考这篇东西？第一类是选了这个题、需要一套完整落地方案的毕业设计同学；第二类是学过前端基础、但一直没做过全链路项目的自学者；第三类是手里已经有一堆零散demo、想攒一个拿得出手的小程序项目的人。下面我把这套系统的架构思路、数据设计、核心代码、调试心得和扩展方向一次讲清楚，不是零散贴代码，而是让你看完之后能独立把它搭起来。
1. 项目整体设计与技术选型
1.1 为什么后端选了Node.js
这个题目最常被问的就是“为什么后端用Node.js而不是Java”。我实际做完之后的体会是：对毕业设计来说，Node.js的优势不是性能，而是“心智负担小、链路短”。整个后端就是一个Express应用，写接口的逻辑和写前端事件处理的思路几乎一样，回调、Promise、async/await这些只要熟悉JavaScript就能直接上手。这对很多后端基础薄弱的同学来说，意味着不用重新学一套语言体系。
而且Node.js生态里的轮子非常齐全：接口框架用Express，数据库操作用Mongoose，登录态用jsonwebtoken，HTTP请求用axios，参数校验有现成中间件。写起来效率很高。后端方案我建议这样定：Node.js + Express + MongoDB。MongoDB比MySQL更贴合这个场景的原因是数据形态灵活。比如餐厅的标签、营业时间、评分这些字段，不同餐厅结构不完全一致，文档型数据库不用做复杂的表关联。假如你所在学校强制要求MySQL，也能做，就是多几张关联表，查询逻辑稍微啰嗦一点。
1.2 功能边界：该砍的砍、该留的留
毕设最忌讳的就是把题想得太大。我见过有人一开始列功能清单就要带团购、优惠券、商家入驻、骑手配送，列完之后自己先被吓退了。这个美食点评系统的合理边界应该是这样的：
- 用户端：微信登录、餐厅列表、分类筛选、关键词搜索、餐厅详情、评价发布、评分展示、收藏管理、个人中心。
- 后端：统一鉴权、餐厅与评价的数据接口、收藏状态接口、统计接口。
- 管理端（可选加分）：一个简单的后台页面，用于餐厅数据录入和评价审核。
砍掉的是支付、订单、商家开店、聊天消息这类重业务。为什么砍？因为毕业设计的评审重点往往在“你会不会设计数据表、会不会写接口、前后端能不能联调通”，而不在于你的业务有多完整。把核心链路做扎实，比堆一堆跑不通的页面要实在得多。
1.3 核心流程梳理
整个系统最核心的一条操作链路是：
用户打开小程序 → 微信登录拿openid → 获取token → 浏览餐厅列表 → 点进详情看评价 → 发表评价或收藏餐厅 → 在个人中心管理记录。
这里面每一步都有对应的数据表和接口，开发的时候沿着这条主线安排顺序。我先写后端把数据和接口跑通，再写小程序页面去对接。这么做的好处是，前端每个页面都有真实数据可渲染，联调效率比两头同时开工高很多。
2. 架构与数据模型设计
2.1 系统架构怎么分层
代码层面我习惯分三层，这个分法在答辩时也特别好讲。
- 展示层：微信小程序端，负责页面渲染和用户交互，数据全部通过wx.request从后端拿。
- 接口层：Node.js的Express路由，负责接收前端请求、做参数校验、调用数据层、返回JSON结果。
- 数据层：MongoDB里的若干集合，通过Mongoose的Schema实现数据结构约束。
这三层之间不要越级调用。小程序页面不要直接拼查询语句或直接操作数据库，后端接口也不要堆大段业务逻辑，尽量保持“路由薄、逻辑清晰”的样子。答辩时老师翻你代码，最看重的就是这一层关系是不是清楚。
2.2 数据集合怎么设计
数据库我实际建了四个核心集合：用户、餐厅、评价、收藏。下面把关键字段列一下，照这个建就能覆盖所有页面需求。
用户表：openid、昵称、头像、创建时间。openid是微信用户在当前小程序下的唯一标识，登录之后靠它识别身份。
餐厅表：名称、分类标签（火锅、川菜、日料等）、地址、经纬度、人均消费、评分、评价数、营业时间、封面图、创建时间。这里有两个字段要特别注意：评分和评价数。它们是“冗余字段”，每次用户新增评价时由后端同步更新，这样列表页不用每次都实时去聚合评价表，用空间换时间，列表加载会明显变快。
评价表：所属用户、所属餐厅、评分（1到5分）、文字内容、图片列表、创建时间。每条评价必须挂到用户和餐厅下，在Mongoose里用ObjectId字段引用。
收藏表：所属用户、所属餐厅、创建时间。一个用户对一个餐厅只能有一条收藏记录，靠联合唯一索引去重，这是特别容易踩的一个坑。
这套设计在答辩的时候很好展开：你讲清楚为什么评分和评价数是冗余字段、为什么收藏要建联合索引，老师就知道你是真写过数据库，不是背概念背出来的。
2.3 接口协议与返回格式
接口格式我建议统一成下面这种结构：
{ "code": 0, "message": "success", "data": {} }code为0表示成功，非0表示业务错误，message是给前端展示的错误信息，data是业务数据。前端拿到之后先判断code再渲染，错误处理和正常逻辑不会混在一起。我实际踩过的坑是：有人写接口时成功直接返回数据本体、出错时返回一段错误对象，前端解析逻辑越写越乱。统一响应体这个习惯越早养成越好。
核心接口清单大致如下：
| 方法 | 路径 | 功能说明 |
|---|---|---|
| POST | /api/auth/login | 微信登录，code换token |
| GET | /api/restaurants | 餐厅列表，支持分页、分类、关键词 |
| GET | /api/restaurants/:id | 餐厅详情，包含评价列表 |
| POST | /api/reviews | 发布评价 |
| POST | /api/favorites/toggle | 收藏或取消收藏 |
| GET | /api/favorites | 获取我的收藏 |
| GET | /api/user/info | 获取个人信息 |
这样一组接口就能把小程序端所有页面都喂饱，后面调试或扩展的时候思路也很清晰。
3. 核心功能实现与代码解读
3.1 微信登录打通：从code到token的完整链路
小程序登录是很多人一开始就卡住的地方。它的整体逻辑是：小程序端调用wx.login拿到一个一次性code，把code传给后端，后端带着code、小程序的appid和secret去请求微信接口换取openid，然后后端自己维护一个登录态，把自定义token返回给小程序。后续请求都带这个token，后端通过中间件解析出用户身份。
后端核心代码：
router.post('/auth/login', async (req, res) => { const { code } = req.body; if (!code) { return res.json({ code: 1, message: 'code不能为空' }); } const result = await axios.get('https://api.weixin.qq.com/sns/jscode2session', { params: { appid: APPID, secret: SECRET, js_code: code, grant_type: 'authorization_code' } }); const { openid } = result.data; if (!openid) { return res.json({ code: 2, message: '微信登录失败' }); } let user = await User.findOne({ openid }); if (!user) { user = await User.create({ openid, nickname: '微信用户' }); } const token = jwt.sign({ userId: user._id }, SECRET_KEY, { expiresIn: '7d' }); res.json({ code: 0, data: { token, userId: user._id } }); });有几个细节必须提醒。code只能用一次，如果前端因为网络原因重复提交，要重新调用wx.login生成新code，不能让同一个code反复请求后端。token有效期设7天比较合理，太短用户老是要重新登录，太长又不够安全。解析token的逻辑统一放在中间件里做，这样所有需要登录的接口只要挂上这个中间件，就能从请求头里直接取出userId。
小程序端的调用捷径是，App启动时先调wx.login，后端返回token后存到storage。之后每个请求都在header里带上token，后端中间件统一校验。
3.2 餐厅列表、分页与搜索的实现
餐厅列表是流量最大的接口，做的时候要特别注意分页。小程序端用滚动加载，每次请求一页，不要一次性全查出来，否则数据量大起来页面会明显卡顿。
分页查询的写法：
router.get('/restaurants', async (req, res) => { const page = parseInt(req.query.page) || 1; const pageSize = parseInt(req.query.pageSize) || 10; const keyword = req.query.keyword || ''; const category = req.query.category || ''; const condition = {}; if (keyword) { condition.name = { $regex: keyword, $options: 'i' }; } if (category) { condition.category = category; } const list = await Restaurant.find(condition) .skip((page - 1) * pageSize) .limit(pageSize) .sort({ avgScore: -1, reviewCount: -1 }); const total = await Restaurant.countDocuments(condition); res.json({ code: 0, data: { list, total, page, pageSize } }); });这里我踩过一个很实际的坑：一开始只按评分倒序排，结果很多只有一两条评价的餐厅因为满分排在很前面，用户点进去发现内容很空，体验很差。后来改成先按评价数过滤、再按评分排，或者直接按“评价数×评分”的综合分排序，效果明显好很多。答辩时提这个是很好的加分点，说明你考虑过真实排序场景，而不是只会order by。
前端分页的通用写法是：页面触底时触发下一页加载，用page变量控制，并且要在“数据加载完毕且还有更多数据”时才继续请求，防止重复请求给后端造成无谓压力。
3.3 评价发布与平均分更新机制
评价功能是这个项目的灵魂，也是体现数据库设计能力的地方。发布评价时前端传餐厅ID、文字内容和1到5分的评分，后端做两件事：插入评价记录，然后更新餐厅表的冗余字段。
推荐用聚合管道一步算完，不要写循环累加：
router.post('/reviews', async (req, res) => { const userId = req.userId; const { restaurantId, content, score } = req.body; if (!restaurantId || !content || !score) { return res.json({ code: 1, message: '参数不完整' }); } await Review.create({ userId, restaurantId, content, score }); const agg = await Review.aggregate([ { $match: { restaurantId: mongoose.Types.ObjectId(restaurantId) } }, { $group: { _id: '$restaurantId', avg: { $avg: '$score' }, total: { $sum: 1 } } } ]); await Restaurant.updateOne( { _id: restaurantId }, { avgScore: agg[0].avg.toFixed(1), reviewCount: agg[0].total } ); res.json({ code: 0, message: '评价成功' }); });有一个细节是评分校验。前端用星星组件限制了1到5，但后端一定还是要校验一遍，防止有人跳过前端直接请求接口。虽然毕业答辩时老师大概率不会恶意测你的接口，但代码里有没有这层校验，一眼就能看出来，也符合真实项目里“后端不信任前端”的底线原则。
另外建议把评价图片上传一起做了。小程序端用wx.uploadFile传到后端，后端存到本地静态目录或对象存储，评价列表里用image组件展示。图片能传能看，项目的完整度会显著提升，很多评审老师看到这一条就觉得已经非常完整了。
3.4 收藏功能与状态同步
收藏的逻辑看起来简单，但状态同步这个细节一定要处理好。用户在一个餐厅详情页点了收藏，回到收藏列表要能看到；再次进详情页，按钮状态必须是“已收藏”。
我用的方案是toggle接口，前端每次点击都调用，后端判断当前是否存在记录，存在就删除，不存在就创建，并把最新状态返回给前端：
router.post('/favorites/toggle', async (req, res) => { const userId = req.userId; const { restaurantId } = req.body; const exist = await Favorite.findOne({ userId, restaurantId }); if (exist) { await Favorite.deleteOne({ _id: exist._id }); return res.json({ code: 0, data: { isFavorite: false } }); } await Favorite.create({ userId, restaurantId }); res.json({ code: 0, data: { isFavorite: true } }); });餐厅详情页加载的时候，同时请求“餐厅详情”和“当前用户是否收藏”，两个接口并行发，用Promise.all合并结果，比串联请求少一半等待时间。收藏列表页用独立接口返回，列表项要带餐厅的名称、封面和评分，这部分在Mongoose里用populate一次性填充，不要在前端拿两个列表自己拼装，否则又慢又容易出错。
4. 调试运行全流程实录
4.1 本地开发环境搭建三步走
很多人拿到项目第一步就问“怎么跑起来”。本地环境的搭建归纳起来就是三步：装依赖、连数据库、改配置。
第一步，后端目录下执行npm install，把Express、Mongoose、axios、jsonwebtoken这些依赖装齐。第二步，本地要有MongoDB，装完之后能连上默认的mongodb://localhost:27017就行。第三步，改配置文件，把微信小程序的appid和secret填进去，这是登录功能能不能通的关键。
小程序端这边在微信开发者工具里导入项目，然后在“详情 → 本地设置”里勾选“不校验合法域名”。这一步不做的话，所有请求都会因为域名校验失败而直接被拦掉，新手十有八九卡在这里。顺带提醒一句，这只是在开发环境下的调试手段，正式上线时必须在微信公众平台把真实域名配成合法域名。
4.2 联调阶段最容易出问题的三个点
前后端联调的时候，建议按这个顺序排查问题，能省大量时间。
第一，先确认后端接口用Postman或Apifox能调通，再去看小程序端。后端都返回不了数据，前端再怎么调试都是白搭。第二，确认小程序端请求的URL是后端真正监听的地址，最常见的错误是后端监听3000端口、前端却写成了3001。第三，确认请求方法一致，后端写的是POST，前端用成了GET，有些场景会直接404或报错。
真机调试要注意一个经典问题：手机访问电脑本地服务时，localhost指向的是手机自己，访问不到电脑，要改成电脑在局域网里的IP地址。而且手机和电脑必须在同一个WiFi下，不然还是不通。这个问题在答辩现场特别常见，提前用真机预演一遍比临场慌了再查要稳得多。
4.3 部署上线的取舍建议
毕业设计其实不强制要求部署到线上。如果学校只要求“能演示运行”，我建议答辩时用本地环境演示就够，把后端和数据库都在自己电脑上起好，小程序用开发者工具打开，这是最稳妥的方式。
如果你想让项目随时随地被访问，可以考虑把后端部署到云服务器，数据库用云数据库，再把小程序的请求域名配置到合法域名。不过这套流程涉及备案、HTTPS证书等，折腾周期不短，如果只是为了答辩，不是必需的。我的建议始终是：先保证本地能跑通，有余力再折腾部署，不要本末倒置。
5. 常见问题与排查技巧实录
实际操作中，我帮不少同学排查过这个项目，把出现频率最高的几个问题整理成一张速查表，按“现象—原因—解法”列出来，遇到问题可以先对号入座：
| 现象 | 原因 | 解法 |
|---|---|---|
| 小程序请求后端全部报“网络错误” | 开发者工具未勾选“不校验合法域名” | 详情 → 本地设置里勾选 |
| 登录接口返回登录失败 | appid或secret配置错误，或code重复使用 | 核对配置，用wx.login重新生成code |
| 列表页一直显示加载中 | 前端请求的URL端口写错 | 对照后端监听端口修改配置 |
| 真机预览请求不通 | localhost指向了手机自身 | 改成电脑的局域网IP，保持同一WiFi |
| 收藏功能偶发重复记录 | 未对联合字段做唯一索引 | 给favorites加联合唯一索引 |
| 平均分显示不更新 | 前端用了旧字段名或本地缓存 | 刷新缓存，核对返回字段名 |
| 图片上传失败 | 后端未配置静态资源目录 | 用express.static挂载上传目录 |
这里重点说下唯一索引的事。在MongoDB里给收藏表建联合索引的方式是：
favoriteSchema.index({ userId: 1, restaurantId: 1 }, { unique: true });建完这个索引之后，即使前端因为防抖没做好连续触发了两次请求，数据库层也能挡住重复记录，从根上杜绝了收藏列表里出现同一家店的问题。
还有两个容易被忽略的小问题。一个是时间字段的时区问题，Mongoose存的日期默认是UTC，前端展示的时候要转成东八区，否则会发现评价时间比实际慢了8个小时。另一个是图片路径问题，开发阶段上传的图片如果存的是相对路径，没做处理的话真机访问时路径会失效，建议上传时直接返回完整的可访问URL。
6. 从合格到加分：几个值得做的扩展方向
6.1 数据统计让项目显得更有深度
如果基础功能做完了还有时间，我强烈建议加一个“餐厅数据概览”模块。后端写统计接口，按分类统计餐厅数量、按评分区间统计分布、按评价数排行，小程序端用简单的图表组件展示几张统计图。这个扩展不复杂，但它在答辩时能展示你对数据聚合的理解，属于性价比很高的加分项。
6.2 位置排序提升真实感
MongoDB支持地理位置索引，餐厅表里只要存了经纬度，就能用$geoNear实现“按距离排序”的查询。打开小程序显示附近的餐厅，这个功能非常贴近美食点评类应用的真实使用场景，也让页面交互更有说服力。实现时需要注意经纬度格式要和微信端的地图组件保持一致，别把经度和纬度存反了，这个错在界面上非常难看出来，但距离计算会完全离谱。
6.3 文档、注释和演示脚本是隐形分
很多同学做完功能就以为万事大吉，其实答辩成绩往往差在“表达”。我建议在项目里留一份README，写清楚环境要求、启动步骤、接口说明、功能清单；代码里的核心模块加注释，讲清楚“这一段为什么这么写”；有条件的话再准备一份演示脚本，把要操作的路径提前走一遍。这些不起眼的细节，在老师眼里就是你做事靠谱的信号。
最后说点我自己的感受。这个项目做完之后给我最大的收获，不是学会了多少框架API，而是完整走通了一遍“前端—接口—数据库”的全链路。以前写页面只是自己跟自己玩，数据都是mock的，做了这个项目之后才知道什么叫真实的数据流——怎么设计数据、怎么保证一致性、怎么排查线上问题。如果你也在做这个题目，我特别建议不要只照着源码敲一遍，而是自己动手把登录、评价、收藏这几条链路从头到尾跟着写一遍，哪怕慢一点也值得。踩过一次坑，比看十遍教程都长记性。等答辩那天，你自己心里有底，讲出来的东西也会比背稿子踏实得多。
