微信小程序+Node.js+Vue前后端分离校园系统实战详解

做过几个完整的微信小程序前后端分离项目之后再回过头来看“node基于微信小程序的云校园系统”这类项目我的第一反应是这名字听着像毕业设计但骨架和思路其实完全可以按商用项目的标准来做。微信小程序端给学生和老师用Vue管理后台给教务和后勤用Node.js做接口层和业务层前后端分离代码结构清晰调试流程顺畅。这套组合几乎是目前校园信息化项目里最主流、也最适合入门到进阶的实战路线。这个项目真正解决的是什么问题说白了就是校园里那些高频的“琐事”查课表、查成绩、看公告、报修宿舍设施、请病假事假、提交活动报名。过去这些事靠群消息、纸质表、Excel汇总现在统一收进一个系统里学生打开小程序就能办老师在后台点几下就能批所有数据沉淀在数据库里随时能查能统计。如果你正在找课设选题、毕业设计方向或者刚学完Node和Vue想找一个完整的全栈练手项目这套系统是非常合适的切入点业务场景清晰、技术栈主流、代码量适中前后端分离的结构也能让你把Web开发和小程序开发两边的技能都过一遍。下面我把这套系统的完整设计和实操过程拆开讲清楚从架构思路到模块细节从环境搭建到踩坑排查尽量按我自己实际开发的顺序来写。1. 项目全景先搞明白这个系统到底由几部分组成很多人拿到项目源码第一件事就是急着点开跑起来结果前端后端配置文件一堆环境变量没设数据库没导启动顺序反了折腾半天也没跑通。动手之前先把项目结构在脑子里过一遍后面基本不会出大乱子。1.1 三端分离的整体结构这套“云校园系统”站在代码层面是三个相对独立的工程分别对应三类使用场景微信小程序端给在校学生和授课老师用包含登录、课表、成绩、公告、报修、请假、个人信息等功能。小程序端通过wx.request调用后端HTTP接口拿到JSON数据后渲染页面。Vue管理后台给教务处、后勤处、辅导员这类管理人员用包含用户管理、课表管理、公告发布、报修工单处理、数据统计等功能。同样是走HTTP接口只是页面形态是PC端后台组件体系更重表格、表单、弹窗、图表。Node.js服务端核心业务逻辑全部在这里负责小程序和后台的数据中转与业务校验连接MySQL数据库统一做鉴权、参数校验、错误处理。这三个工程建议分成三个独立目录比如miniprogram/、admin-web/、server/。根目录放README、数据库初始化SQL脚本和部署文档版本管理各建各的仓库或在一个仓库里分目录管理都行。前后端分离的优势在这里体现得很直接小程序、后台管理系统、服务端可以完全独立开发、独立部署只要接口约定不变任何一端升级都不影响另外两端。1.2 核心业务模块与数据流转刚接触这类项目的人容易把功能表堆得很长但真正常用的核心模块就四个账号权限、教务信息课表/成绩、校园服务公告/报修/请假、后台管理。做一个按学生视角走一遍数据流转的例子学生打开小程序先微信授权登录拿到自己的openid后由后端签发token进来看到首页课程卡片点击课程进入详情页提交一个宿舍灯管报修单填上文字描述、传两张图片提交后数据落到工单表管理员在后台的工单列表里看到这条记录点“受理”状态变成“处理中”维修师傅办完事点“完成”学生小程序端收到状态更新可以评价。整个过程看起来简单但每条业务数据的产生、变更、状态推进都要有对应的数据库表、API接口和前端页面去承接。做项目时最忌讳的就是只盯着某个页面写不看整条链路。拿报修举例单写“调用后端的report接口提交表单”确实能完成任务但少想了几件事用户身份怎么识别从哪里拿用户ID、图片怎么传字段怎么拼接、状态谁更新权限区分管理员和用户、未登录能不能提交token校验。这些都是在看到数据库设计表和接口设计文档时应该主动去推演的。1.3 这套结构带来的学习价值从实战角度看这套项目把所有主流前后端知识点都串起来了小程序的组件生命周期和API使用、Vue的路由守卫与状态管理、Node的中间件机制和JWT鉴权、MySQL的表设计和联表查询。做完这个项目你再去看企业里常见的“客户端 管理端 服务端”三层应用架构基本不会觉得陌生。甚至往细了说数据库表结构的设计思路、接口返回格式的统一约定、登录态的全局维持策略这些经验换个业务场景照样可以直接迁移。2. 技术选型每个选择背后都是有原因的技术选型这部分不是拍脑袋定的我接触过不少同类项目也踩过把技术栈用歪的坑我把每个核心选择的原因展开说说方便你决定要不要照着用。2.1 为什么后端选Node.js而不是Java或Python同类校园系统用Java Spring Boot的也不少但Node.js在这类项目里有三个非常实际的优势。第一是生态语言一致。前端已经全是JavaScript/TypeScript小程序端也是JS语法体系后端再选Node.js你只需要吃透一门语言就能跑通全栈。学生开发者刚上手时不用在“Python写业务逻辑没问题但部署环境配置麻烦”和“Java各种注解和类结构处理起来繁琐”之间纠结Node从启动到接收请求出JSON心智负担小得多。第二是I/O密集型场景匹配。校园系统的日常请求都是查询课表、查询成绩、提交表单这类操作背后是对数据库的读写属于典型的I/O密集型。Node基于事件循环的非阻塞模型在并发请求量不是极端高的情况下性能和稳定性完全够用。有人可能担心Node单线程会不会崩实际上这类业务系统瓶颈在数据库查询和网络I/O不在CPU计算只要代码里不写同步阻塞的耗时操作问题不大。第三是npm生态成熟开发效率高。登录鉴权用jsonwebtoken文件上传有multerORM选sequelize或prisma配置校验用joi这些库都是现成的几行代码就能接入。相比从零手写登录鉴权和参数校验省下的时间能做不少业务功能。具体框架层面Express和Koa是主流个人建议从Express入手。Express的中间件模型简单直观教程多、资料全遇到奇怪的问题搜索一下基本有答案。Koa的洋葱模型更优雅但一些中间件需要自己组合新手调试难度略高。如果项目源码已经是Koa写的照着Koa的思路理清中间件执行顺序即可。2.2 小程序端为什么用原生开发现在市面上有uni-app、Taro这类跨端框架一套代码编到微信、支付宝、H5多端。但这类校园系统我建议直接用微信原生小程序开发框架。原因有三一是原生框架对微信API的封装最直接。蓝牙打印小票、订阅消息、地理位置、扫一扫这些能力原生框架的调用路径最清晰跨端框架有时要写条件编译或者等待平台适配处理起来反而绕。二是项目本身不需要跨多端。既然使用场景就是微信校园生态没必要为了“将来可能出App”提前引入跨端框架的复杂度。三是原生WXML/WXSS语法本身不复杂。只要是写过HTML/CSS的人转到小程序基本无缝衔接学习成本并不高。你需要额外适应的只是小程序生命周期onLoad/onShow/onReady和setData驱动视图更新这个心智模型。2.3 管理后台用Vue的理由后台管理系统是典型的“增删改查”密集型应用Vue在这类场景里有天然优势。组件化开发可以把用户表格、弹窗表单、状态标签封装成公共组件代码复用性高。配合Element UI或Element Plus这类桌面端组件库表格拖过来、表单拽过来、弹窗加个配置属性页面写起来飞快。Vue 2和Vue 3的选择要看项目源码基础。如果后端和数据库都是老项目结构源码用的是Vue 2 Element UI那就保持一致没必要强行升级稳定跑通比追求新版本重要。如果是新起项目直接上Vue 3 Vite Element Plus PiniaVite的冷启动速度和热更新体验比webpack时代好太多。核心逻辑路由守卫、token拦截、axios封装在两个版本间差别不大迁移成本可控。这里需要说明一点项目标题里标了“vue”在实际项目里Vue通常只承担管理后台小程序端是原生开发。如果你看到源码里小程序端也是Vue相关文件那可能是用了uni-app或者小程序web-view嵌H5要留意区分别把两端结构搞混。2.4 数据库为什么用MySQLMySQL在这个项目里属于“最稳的不会错的选择”。校园系统的数据结构高度结构化学生、教师、课程、班级、公告、工单每类实体都有清晰的字段定义实体之间有明确的关系“学生选课”“教师授课”都是经典的多对多关联。这类业务用关系型数据库天经地义MySQL又比Oracle轻量比SQLite适合多用户并发访问配合Navicat或DBeaver管理数据直观方便。从学习角度MySQL让你必须认真设计表结构、外键逻辑、索引方案这些能力是后端开发的基本功。MongoDB这类NoSQL虽然在灵活度上有优势但做课表和选课关系时反而容易把数据越存越乱。一句话关系型数据用关系型数据库不要为了酷炫换赛道。2.5 接口设计规范的核心约定前后端分离项目的协作基石是接口文档。不夸张地说接口设计得好不好直接决定联调效率。这套项目里我建议统一遵循如下约定接口路径RESTful风格资源用名词复数比如/api/v1/announcements、/api/v1/work-orders。统一返回格式后端所有接口返回{ code: 200, message: ok, data: {...} }。code非200的业务错误前端统一判断处理避免每个接口各自搞一套返回值。鉴权方式前端登录后拿到token存到storage每次请求在header里带Authorization: Bearer token。后端用中间件统一校验。分页参数列表接口统一page和pageSize参数返回体带total字段方便前端分页组件使用。这些约定在前端封装axios/wx.request时落地请求拦截器自动附token响应拦截器统一处理code错误和401跳登录。一套约定走到底后面写页面的时候你会很爽不用每个页面都写一遍错误处理逻辑。3. 核心模块实现拆解从登录到工单全套细节这一部分是全文的重头戏。我挑几个关键模块把数据库设计、接口定义、前端处理逻辑串起来讲每一个都能照着重现。3.1 微信登录与JWT鉴权小程序的登录链路和传统Web不一样传统Web登录是用户名密码验证后种Session小程序登录则是微信开放平台体系小程序端调用wx.login()拿到临时code传给后端后端用这个code调用微信官方接口code2session换来用户的openid和session_key。openid是用户在微信生态里对这个小程序的唯一标识相当于业务系统的“身份证号”。拿到openid后后端去用户表查这个人是否存在不存在就以openid为账号自动注册一个基础账号存在则直接走登录流程。成功以后后端通过JWT签署一个token返回给前端。token里有userId和role角色值student/teacher/admin下次请求带上token后端中间件就能解析出“谁在请求、他是什么角色”从而做权限控制。这里有个容易踩的坑JWT天然无法在服务端主动作废。如果用户改了密码或管理员封禁了某个账号旧token在到期前依然有效。解决方案可以是维护一个token黑名单表/MemoryCache或者把token有效期设短一点靠refresh_token刷新续期。校园系统这类低并发内部系统建议token有效期设置7天即可黑名单机制可以先不加把精力放在核心功能上。数据库用户表设计参考如下users - id BIGINT PRIMARY KEY AUTO_INCREMENT - openid VARCHAR(64) UNIQUE - role ENUM(student,teacher,admin) DEFAULT student - name VARCHAR(32) - avatar_url VARCHAR(255) - student_no VARCHAR(20) NULL -- 学号 - phone VARCHAR(20) NULL - created_at DATETIME - updated_at DATETIME接口侧主要是POST /api/v1/auth/login body: { code } - 返回 { token, userInfo } GET /api/v1/users/me 需带token - 返回当前用户信息小程序端每个请求都要带token常见做法是在utils/request.js里封装一个请求函数request头带Authorization响应401时清除登录态并跳到登录页。别小看这个封装后面所有页面都靠它维持登录态写好了能省大量重复代码。3.2 课表查询一周课程的数据怎么组织和计算课表是校园系统最典型的“看起来简单、做起来有细节”的模块。数据库不能只存一个课程表因为课程和上课时间是多对多的关系。我用的表结构是三张核心表再加一张关联表courses - id, name, credit, teacher_id, location, week_start, week_end, day_of_week, start_section, end_section字段解释一下teacher_id关联用户表标识哪位老师授课week_start / week_end课程从第几周上到第几周比如1到16周day_of_week周几上课0代表周日或1代表周一约定好就行start_section / end_section第几节开始、第几节结束上午4节下午4节晚上3节是常规分段这样设计之后一条课程记录就完整定义了一个“在何时何地上什么课”。如果一门课一星期有两节不连续的时间就拆成两条记录或者再用一张schedule关联子表去存多时间点。学生查询课表时后端根据当前登录学生的选课列表关联课程表过滤出本周有效课程按星期和节次分组返回给前端。接口设计示例GET /api/v1/schedule?week5 返回{ code:200, data: [ { day: 1, sections: [ { course_name:高数, location:教学楼201, teacher:张老师 } ] } ] }小程序端渲染课表时用scroll-view横向滚动 纵向列表的网格布局数据结构搞定之后页面渲染只是按day分行的体力活。一个重要细节是周次计算。每学期从开学第一天算第1周今天是第几周需要后端结合学期表计算不能靠前端拍脑袋算。实际实现时可以在数据库放一个semester表存学期开始日期和总周数后端根据日期差算出当前周再传给前端。如果不做自动算周也可以做一个“本周”和“下周”切换按钮通过URL参数把week传后端由后端过滤。这个小场景很值得亲手做一遍因为很多系统到最后都会发现“周次算错”这种基础bug影响面极大。3.3 公告系统富文本存储和已读状态怎么设计公告模块是管理端发布、小程序端查看的典型场景。这里有两个技术细节值得重点处理。第一个是富文本的存储和渲染。管理后台的公告编辑器会让管理员填标题、正文、上传封面图正文往往是带格式的内容。实现方案有两种简单方案编辑器输出HTML片段直接存到数据库的content TEXT字段小程序端用rich-text组件渲染HTML。要注意rich-text对小程序的标签支持不够充分部分样式如class、id会被过滤图片尺寸也容易溢出屏幕。最佳实践是后端在保存时对图片URL做一次处理要求上传图片时服务端统一拼完整域名rich-text渲染时给图片加modewidthFix属性或CSS约束。推荐方案编辑器输出筛选过的HTML片段PHP或Node服务后端做一次XSS过滤和图片懒加载处理再存库。展示层用rich-text渲染时自带div stylemax-width:100%包裹基本能绕开图片溢出问题。第二个是已读状态。公告表announcements存标题、内容、发布者、发布时间。已读记录单独建一张关联表announcement_reads - id, announcement_id, user_id, read_at用户查看公告详情时后端记录一条已读。列表接口通过EXISTS查当前用户是否已读前端在标题旁显示“新”标签。已读未读数据分离维护成本低后面统计“某条公告多少人没看”也就是一个count的事。3.4 报修工单状态机驱动的业务流报修模块是校园系统里最能体现“业务逻辑完整”的功能。一张工单从用户提交到最终办结要经历 待受理 - 处理中 - 已完成 - 已评价 四个状态。后端需要设计一张work_orders表work_orders - id BIGINT - user_id BIGINT -- 报修人 - title VARCHAR(100) -- 故障标题 - description TEXT -- 详细描述 - images JSON -- 图片URL数组 - status TINYINT -- 0待受理 1处理中 2已完成 3已取消 - handler_id BIGINT -- 处理人管理员/维修人员 - created_at DATETIME - updated_at DATETIME接口定义POST /api/v1/work-orders 用户提交工单 GET /api/v1/work-orders/my 用户查看自己的工单列表 GET /api/v1/work-orders/all?status0 管理员查看指定状态的全部工单 POST /api/v1/work-orders/:id/accept 管理员受理工单 POST /api/v1/work-orders/:id/complete 管理员完成工单 POST /api/v1/work-orders/:id/cancel 用户取消工单状态流转的核心写法是在后端Service层做状态校验只有“待受理”状态能受理只有“处理中”能完成用户取消只能取消“待受理”中的工单。这个状态校验不写会出现用户取消已完成工单的诡异数据这个一定要防。图片上传这块小程序端用wx.chooseMedia选图后走wx.uploadFile上传到后端/api/v1/upload接口后端接收文件后保存到本地或云存储返回URL。注意uploadFile不支持自定义header时附带业务参数所以上传接口建议做成不需要登录鉴权或者把用户身份放到URL query参数里传。也可以先走普通request获取上传凭证再上传校园项目做到第一档就够用。3.5 管理后台的关键实现权限路由和表格联动Vue管理后台的核心不是页面多而是权限模型和列表数据流要清晰。权限这块前端用动态路由配合用户角色实现用户登录后拿到角色信息根据角色动态注入他允许访问的路由。管理员角色能看到用户管理、权限分配、班级管理等全部菜单辅导员能看到学生列表、请假审批、报修列表后勤人员只能看到报修工单。后端接口也要做角色校验双重保障前端隐藏菜单只是体验优化真正的安全边界必须由后端守住。列表页面用Element Plus的el-table和el-pagination配合axios请求拿到分页数据。用户管理、公告管理、工单管理三个页面的骨架非常相似可以封装一个通用的PageTable组件把搜索表单、表格列、分页操作都做成配置型组件减少大量重复模板代码。数据统计模块可以加一个仪表盘页面用ECharts画每日报修工单数量折线图、各类型故障占比饼图、近七日活跃用户柱状图。这部分不是必需品但有它在项目答辩或演示时效果拉满也能让你熟悉图表组件的接入流程。4. 实操过程从环境搭建到跑通完整项目流水我按“后端启动 - 小程序联调 - 后台联调 - 部署上线”的顺序写一套最省时的操作流程。每一步都直接给结论和参数跟着做基本能跑通。4.1 环境准备清单Node.js 16.x 或更高版本建议LTS别追最新大版本部分依赖可能没跟上npmNode自带或 cnpm / pnpm 都行国内网络环境建议用pnpm或cnpm换镜像安装依赖MySQL 5.7 或 MySQL 8.x数据库编码统一utf8mb4微信开发者工具自己注册个测试号或个人AppID即可不需要企业主体Vue CLI如果是Vue 3推荐直接用Vite更快Apifox 或 Postman用来调试后端接口4.2 后端启动和数据库初始化先确认MySQL服务已启动新建空数据库CREATE DATABASE campus_cloud DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;然后导入项目根目录的SQL文件一般叫campus_cloud.sql或init.sql。导入完成后检查后端项目的.env或config.js里的数据库连接信息确保账号密码和你本地一致DB_HOSTlocalhost DB_PORT3306 DB_USERroot DB_PASSWORDyour_password DB_NAMEcampus_cloud JWT_SECRETyour_secret_key PORT3000接着安装依赖并启动cd server npm install # 如果install报错优先看是不是node版本太高或太低nvm切换版本重试 npm run dev建议开发阶段用nodemon监听文件变化自动重启。控制台出现类似Server running at http://localhost:3000的日志就说明后端起来了。用Postman随便测一个/api/v1/health健康检查接口确认服务正常。4.3 小程序端导入与本地调试打开微信开发者工具选择“导入项目”找到小程序目录填自己的AppID。调试阶段最关键的一步在微信开发者工具的“详情-本地设置”里勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”。否则小程序会拦截所有对http://localhost:3000的请求。小程序端如果有appid配置打开app.js或config.js确认baseUrl指向后端地址const BASE_URL http://localhost:3000修改完编译小程序用一个测试账号走通登录流程。如果登录失败优先看后端日志code2session调用失败通常是AppID或AppSecret配置错误或服务器无法访问微信接口。4.4 管理后台启动与联调cd admin-web npm install npm run serveVue项目默认跑在8080端口浏览器访问控制台输出的地址。管理后台的登录账号在数据库初始化SQL里一般预置了一个admin账号比如admin / 123456一个教师账号一个学生账号。登录进去先后台跑一跑发一条公告、处理一张工单、新增一个用户。如果出现跨域报错浏览器Console红色的CORS错误说明后端没有开启CORS。Express项目加cors中间件npm install corsconst cors require(cors) app.use(cors())或者用Vite的代理server.proxy把/api转发到后端端口生产环境推荐后者更安全。4.5 联调过程中的核心调试技巧前后端联调阶段我经常遇到“前端报错但不知道错在哪”的情况这里分享几个高效的定位手段接口层验证用Apifox/Postman。前端页面报错先在后端接口文档里拿同样的参数在Apifox里跑一遍如果Apifox正常而前端报错问题在前端传参格式如果Apifox也报错问题在后端逻辑或数据库数据直接看后端控制台堆栈。小程序端看Network面板和vConsole。微信开发者工具的Network面板能看到每个请求的request和response定位是否返回401、500。vConsole是移动端调试利器真机预览时在页面上直接看到 console 输出。后端日志分级。开发阶段在关键位置登录、下单、状态流转加上console.log打印关键参数和耗时。不要只在catch里打一行“error”要把请求参数、错误message、堆栈都打出来排查效率翻倍。数据库直接查验证。有些接口返回数据不对前端和后端代码看半天没问题其实根因是数据库里脏数据。用Navicat直接查表看字段值是否和预期一致能快速排除这类干扰。4.6 前后端分离部署要点本地跑通后如果要把项目挂到服务器上前后端分离部署有几个关键环节后端用PM2守护进程避免进程意外退出npm i -g pm2 pm2 start app.js --name campus-server pm2 save pm2 startupMySQL数据从本地迁移到服务器时用mysqldump导出再导入mysqldump -u root -p campus_cloud campus_backup.sql # 服务器上导入 mysql -u root -p campus_cloud campus_backup.sql前端后台构建后产物是静态文件。用Nginx托管并配置反向代理server { listen 80; server_name your_domain.com; location / { root /var/www/admin-web/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:3000; } }小程序端上线必须在微信公众平台配置合法域名且必须HTTPS协议。如果没有企业主体的服务器和域名最简单的是保持开发模式继续调试或者用微信自带的上传体验版给内部测试真机预览时打开“不校验合法域名”即可仅限于开发调试阶段使用。5. 常见问题与排查技巧实录这部分是我和多个做同类项目的同学交流后整理出来的高频问题按“现象 - 原因 - 解决”的结构列成速查表建议你遇到问题直接对号入座。5.1 真机预览请求失败开发工具正常表现原因解法真机预览所有请求全部报request:fail小程序真机环境强制校验域名合法性且要求HTTPS开发阶段真机预览时勾选工具里“不校验合法域名”但真机预览本身不能完全绕过需上传体验版并在手机打开调试开关工具正常、真机空白本地服务只监听了localhost或127.0.0.1启动后端时监听0.0.0.0确保手机和电脑同一局域网用电脑内网IP访问如http://192.168.x.x:3000HTTPS请求提示证书无效个人测试服务器没有可信SSL证书购买或使用免费证书配置到Nginx小程序正式版要求HTTPS证书链完整5.2 跨域问题现象管理后台登录成功但后续数据列表请求全部失败浏览器Console提示CORS policy。原因后台静态页面运行在http://localhost:8080接口在http://localhost:3000浏览器同源策略拦截了跨域请求。解法开发环境最省事的方式是在Vite配置代理把/api前缀转发到后端前端代码里所有请求都走相对路径/api/xxx生产环境Nginx配置proxy_pass。如果非要后端开CORS注意允许的origin别用*配合credentials模式会失效指定具体域名更稳。5.3 登录后token立即失效或反复弹登录框现象登录成功跳转首页一刷新页面又被踢回登录页。原因多半是前端请求拦截器没有把token带上去或者token存错了storage键名。也可能是token有效期设置得太短比如几十分钟就过期。解法打开Network面板查看请求头确认Authorization字段是不是带上去了。前端所有请求统一走封装好的request方法别在业务代码里直接调wx.request或axios裸发。token有效期建议至少7天配合后端在响应头里返回新token做续期。5.4 富文本图片显示不全现象后台发布的公告小程序里正文图片宽度溢出屏幕或者图片直接裂开。原因rich-text组件对HTML标签的class样式支持有限图片原尺寸过大超出屏幕宽度图片URL是相对路径或带了内网IP。解法保存公告内容时后端把图片URL统一替换成完整可公网访问的地址。渲染时在rich-text的容器上设置word-break: break-all图片可以统一在数据库存的时候转为宽度适配的格式或者在前端用一个自定义过滤函数给img标签加style。最省事的办法是公告编辑器上传图片时提前约束尺寸比如服务端返回剪裁后的URL。5.5 数据库连接过多导致服务卡死现象运行一段时间后后端所有请求耗时飙升控制台报Too many connections或connect ETIMEDOUT。原因没有使用连接池每来一个请求新建一个数据库连接或者连接池配置的connectionLimit太小并发高时排队。另一个常见原因是循环里忘关查询连接。解法用mysql2库 连接池const mysql require(mysql2/promise) const pool mysql.createPool({ host: process.env.DB_HOST, user: process.env.DB_USER, password: process.env.DB_PASSWORD, database: process.env.DB_NAME, waitForConnections: true, connectionLimit: 10, queueLimit: 0, })所有查询统一走pool.query()不要自己手动创建连接再释放连接池会自动管理。5.6 图片上传失败或上传成功但在线访问404现象小程序端wx.uploadFile返回成功但把返回的URL粘贴到浏览器访问404。原因文件虽然保存到了服务器本地但Nginx或后端静态资源路径没配置。解法Express中要托管静态目录app.use(/uploads, express.static(path.join(__dirname, uploads)))Nginx里对应加一个locationlocation /uploads/ { alias /var/www/campus-server/uploads/; }注意检查上传目录的写入权限Linux下常见Permission denied导致文件压根没写进去。5.7 数据库中文乱码现象插入数据后表里中文全是???。原因数据库、表、字段字符集不一致连接串没指定utf8mb4。解法统一在连接池配置里设置charset: utf8mb4建库时用CREATE DATABASE ... DEFAULT CHARACTER SET utf8mb4表结构在Navicat里确认也是utf8mb4。这个坑一旦踩到改起来牵涉面广最好初始化时就统一约定好。5.8 并发冲突问题现象抢课或报名的瞬间两个学生同时提交数据出现重复记录或者报名人数超出班级容量限制。原因典型的并发写竞争先查再写不是原子的。解法对关键业务增加唯一索引兜底比如选课表加UNIQUE KEY (student_id, course_id)。对于报名人数限制用事务 行锁或乐观锁实现简单方案是给课程表增加一个selected_count字段事务内先UPDATE ... SET selected_count selected_count 1 WHERE id ? AND selected_count max_count判断affectedRows是否大于0再插入选课记录。这套思路在“先判断再插入”的业务里通用。6. 做好这个项目的一些额外建议项目跑通以后如果想在简历上写得更扎实或者答辩时更有底气可以再补两个锦上添花的点。第一个是给系统加一个数据看板。后台的仪表盘页面不要只放空表格把“本周报修工单数据”折线图、“各故障类型占比”饼图、近7日活跃用户数放上去数据直接从后端聚合接口拿。这不只是好看它逼着你写聚合SQLGROUP BY、COUNT、DATE_FORMAT这些是后端面试高频考点。每次面试官问我“你做过数据统计吗”我都能把这段经历说得很具体。第二个是接入微信订阅消息。报修工单状态变成“处理中”或“已完成”时给用户推送一条订阅消息。用户提交工单时请求订阅授权后端在状态变更时调用微信订阅消息接口。这个功能需要企业主体的小程序才能正常推送个人开发者在开发阶段可以先调通没权限就用console.log模拟发送。接入过程涉及access_token缓存、模板ID配置、用户openid绑定一套走完你对微信开放平台的理解会深很多。我个人在实际操作中最深的感受是这类校园系统项目代码写起来并不难难的是把业务流程彻底想清楚再动手。数据库表设计多花一小时推敲后面写接口能省三小时改代码的返工。带着这个思路去推进你会发现自己不仅会写一个项目更会设计一个项目了。最后再分享一个小技巧开发阶段把后端接口的返回数据格式打印到控制台用不同颜色区分成功和异常响应调试时一眼就能看出问题比盲改前端代码高效得多。希望你也能在这个项目里找到自己熟悉的节奏把前后端分离这套玩法彻底打通。