企业官网建设流程全解析

又到了毕业设计选题的季节，每年这个时候总有学弟学妹来问我，Java和Python写烂了，还有什么方向既好过审又能学到真东西。今天分享一个我最近整理完的毕设项目——基于Node.js的实验室教学日志系统小程序，代码、文档、讲解视频全都有，属于那种拿过去改改就能用的完整方案。这套东西覆盖了小程序端、Node.js后端、数据库设计、接口联调全部环节，适合想做全栈方向的计算机专业学生，也适合实验室管理者想找一套轻量化的教学日志管理工具。

为什么推荐这个题目，三个理由：第一，小程序是当前教学管理类工具的热门载体，老师和学生都用得上，演示效果好；第二，Node.js做后端学习曲线比Java全家桶平滑得多，但技术栈又足够撑起毕业论文的架构分析；第三，实验室日志这个场景贴近高校真实需求，答辩时能聊的东西非常多，从需求分析到部署上线是一条完整的链路。

1. 系统整体设计与技术选型

1.1 为什么选小程序加Node.js这个组合

很多同学在选择毕设技术栈的时候会纠结，其实核心评判标准只有两条：一是你能否在三个月内独立做完，二是答辩时有没有足够的技术深度可以展开。小程序加Node.js恰好在这两点上都有优势。

小程序端的优势在于开发门槛低、上线成本小。不需要处理安卓和iOS两套代码，一个WXML加一个JS文件就能搞定页面逻辑，云开发甚至能省掉服务器运维的麻烦。但咱们这个项目用的不是云开发，而是自建Node.js后端，原因很简单——教学日志系统涉及课程管理、学生签到、教师审核这些相对复杂的业务关系，自建后端的表结构和接口设计更能体现你的设计能力，这在毕业论文里是实打实的加分项。

Node.js的优势在于异步I/O模型非常适合这类轻量级管理系统。实验室日志系统的并发量并不会很高，但会有大量的读写操作，比如学生提交日志、教师批量审核、管理员导出统计报表。Node.js的事件循环机制让这些操作不用排队等待，配合MySQL的事务处理，完全能撑住一个实验室的日常使用。

还有一个实际问题：这种规模的系统如果用Spring Boot，光环境配置和依赖管理就能劝退一半新手。Node.js一个npm install就全搞定了，Express框架又简单到文档翻两页就能上手，这才是多数人能够顺利毕业的正确选择。

1.2 核心功能模块拆解

这个系统的业务场景很明确，服务对象分三类：学生、教师、实验室管理员。每一个身份看到的页面和能做的操作完全不同，这也是小程序端需要做权限控制的原因。

学生端的功能相对简单，但都是高频操作。查看本学期的实验课程安排，进入某一门课程后提交当次实验的教学日志，日志内容包括实验项目名称、实验过程描述、遇到的问题和心得体会。还能查看教师对自己的日志反馈，以及自己的累计实验学时和完成进度。

教师端的功能核心是审核与反馈。查看自己名下课程的日志提交情况，逐条审核学生提交的日志，通过或者驳回，驳回时需要填写修改意见。同时教师还能发起临时实验安排，系统自动推送给选课学生，小程序端会收到订阅消息通知。

管理员端是整个系统的中枢。管理教师和学生账号，分配实验室和课程时间段，查看全校实验室的使用率数据，导出各课程的日志汇总表和成绩单。

这个功能切分方式在答辩时的亮点在于，它不是简单地做增删改查，而是把实验室管理的实际业务流程梳理清楚了。每一个功能点都能对应到真实的管理痛点，论文好写，演示好做。

1.3 数据库设计思路

数据库设计直接决定了后面接口好不好写。这个系统一共设计了六张核心表，其实还可以继续拆，但这个规模对毕设刚刚好，既不会太单薄，又不至于把时间耗尽在表关联上。

用户表保存三种角色的公共字段，用户ID、用户名、密码的哈希值、角色标识、真实姓名、学号工号。课程表用来存实验室课程的基础信息，关联教师ID和实验室编号。课程安排表是学生和课程的关联表，也就是选课关系。日志表是核心中的核心，关联学生ID、课程安排ID、实验内容、日志正文、状态字段（待审核、已通过、已驳回）、教师评语和时间戳。通知表存系统消息，反馈表存日志驳回时的修改意见记录。

角色字段的权限控制是在后端接口层完成的，也就是每次请求先校验登录态，再校验角色权限，实现一个简单的RBAC（基于角色的访问控制）模型。这样前端页面即使被绕过，后端接口也有安全防护。

有个经验要分享：日志表里的状态字段一定要做索引。很多同学忽略了这一点，等数据量上来之后，教师端审核列表的查询会明显变慢，到时候排查问题非常痛苦。

2. 核心细节解析与实操要点

2.1 后端API架构与路由设计

后端项目结构推荐采用分层架构，虽然Express本身是轻量框架，但为了后期维护和写论文方便，建议按照controller、service、router、model四个目录来组织代码。

路由的设计遵循RESTful规范，这一点在答辩时是值得拿出来讲的。比如日志相关的接口：

• POST /api/logs 学生提交日志
• GET /api/logs?courseId=xx&page=1 分页查询日志
• PUT /api/logs/:id/review 教师审核日志
• DELETE /api/logs/:id 管理员删除日志

每个接口都对应一个service层的业务逻辑函数，model层统一管理数据库操作。这样分层的好处是接口测试时可以单独调试某个环节，出错了也容易定位。

中间件这一块，核心的有三个：JWT身份认证中间件、角色权限中间件、全局异常处理中间件。JWT（JSON Web Token）的认证流程是，用户登录成功后后端返回一个带签名的token，前端存在storage里，之后每次请求在header里带上这个token。后端解析token并验证签名，通过后把用户信息挂到请求对象上，后续代码直接使用。

代码实现大体是这样：

function authMiddleware(req, res, next) { const token = req.headers.authorization?.split(' ')[1] if (!token) { return res.status(401).json({ code: 401, message: '未登录' }) } try { const decoded = jwt.verify(token, SECRET_KEY) req.user = decoded next() } catch (err) { return res.status(401).json({ code: 401, message: '登录已过期' }) } }

角色权限中间件更简单，从req.user里拿到角色字段做判断就行。这里要注意一个细节，admin的接口最好单独校验，不要和学生端的接口混在一起写，逻辑清晰度完全不同。

2.2 小程序端页面与交互设计

小程序端使用原生框架开发，没有引入额外的UI组件库。虽然这样写会比较累，但原生框架在小程序运行性能上是最好的，尤其是有列表页面的场景，第三方组件库经常会出现渲染卡顿的问题。

页面结构上，底部tabBar放三个页面：首页展示课程列表和通知，日志页是提交和查看日志的主入口，我的页面承载个人信息和设置。每个角色登录后看到的tabBar是不一样的，这需要在小程序启动时根据登录用户的角色动态设置tabBar列表。

日志提交页是这个系统最核心的页面。表单元素包含下拉框选择课程、文本域输入实验内容、图片上传组件传实验结果照片。图片上传用的是小程序的wx.uploadFile接口，后端接multipart/form-data格式。上传前需要对图片做压缩处理，小程序端的wx.compressImage接口可以直接调。

这里有个常见的坑务必注意：小程序的request域名白名单限制。开发阶段在开发工具里勾选“不校验合法域名”就行，但真机调试和上线发布前，必须在小程序管理后台把后端API的域名加入白名单，而且必须是HTTPS协议的域名。很多同学demo跑得好好的，一上线就白屏，原因就在这里。

2.3 日志管理的核心业务逻辑

日志的整体流程是：学生选择课程进入当日实验，填写日志内容并提交，系统将日志状态置为“待审核”。教师登录后在审核列表看到所有待审核日志，点击进入详情，可以查看学生的实验描述和图片，然后选择通过或驳回。驳回时必须填写修改意见，日志会回到学生的待修改列表里，学生修改后重新提交，状态再次变为待审核。

这个看似简单的流程，在代码实现上有一个需要注意的地方：日志版本控制。学生提交、被驳回、修改后再次提交，每一次操作都应该在日志表里留下记录。我后期给一个学弟调试代码时发现，他只是简单覆盖了原日志记录，导致教师端看不到学生修改了哪里，只能看到最终版本，审核体验非常不好。

正确的做法是在日志表加一个version字段，每修改一次版本号加一，同时用一份修改记录表单独存历史快照。这样教师在审核页可以看到“该日志已修改2次，最新版本见正文，历史版本可展开查看”，这一处细节在答辩时的演示效果非常好。

3. 实操过程与核心环节实现

3.1 后端环境准备与项目初始化

先说环境清单：Node.js建议16或18版本，MySQL使用8.0，小程序开发工具用最新稳定版就够了。安装Node.js时要注意，不要装最新的奇数版本，比如21、23这种，很多依赖包会报兼容性错误，到时候你分不清是代码问题还是环境问题。

后端项目初始化用npm init -y创建package.json，接着安装必要的依赖包：

npm install express mysql2 sequelize jsonwebtoken bcryptjs multer cors dayjs

sequelize是ORM框架，用它操作MySQL会比写原生SQL减少很多重复代码，最关键的是模型定义能直接对应论文里的数据库设计章节。bcryptjs用来做密码加密，密码绝对不能明文存数据库，这是答辩时一定会被问到的问题。cors解决小程序端的跨域请求限制，multer处理图片上传。

项目目录初始化后需要建立数据库连接文件。我习惯把数据库配置单独放到一个config文件里，用环境变量的方式读取，这样部署到服务器时不需要改代码，只改环境变量就行。

3.2 数据库初始化与表结构实现

使用Sequelize定义模型时，不使用自动建表功能，而是手写一份初始化SQL脚本。理由很简单，自动建表有时候生成的字段类型和索引不是预期效果，手写SQL能完全控制每一列。把初始化脚本放在sql目录下，首次部署时执行一遍即可。

课程表和日志表的关联是整个数据库设计的重点。日志表持有一个courseScheduleId外键指向课程安排表，课程安排表的主键是联合主键，由课程ID加教师ID加上课时间段组成。这个设计能保证一个教师在同一时间段不会被分配两个实验室，从数据库层面就限制了数据冲突。

写初始化脚本的时候一定要加上样例数据。没有数据的系统，前端页面是空的，调试时还以为是代码出了bug。我在样例数据里放了三个测试账号：管理员账号、一个教师账号、一个学生账号，密码统一为123456，这样拿到手就能直接登录测试。

3.3 小程序端核心代码实现

小程序最核心的请求封装放在utils/request.js文件里。封装请求时统一处理token注入、错误码拦截、登录过期跳转这三件事。

function request(url, method, data) { return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${url}`, method, data, header: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${wx.getStorageSync('token')}` }, success(res) { if (res.data.code === 401) { wx.navigateTo({ url: '/pages/login/login' }) reject(new Error('登录过期')) } else if (res.data.code === 200) { resolve(res.data.data) } else { wx.showToast({ title: res.data.message, icon: 'none' }) reject(new Error(res.data.message)) } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }) reject(err) } }) }) }

登录页的逻辑是调用后端登录接口拿到token和用户信息，存到storage后根据角色跳转到不同的首页。首页的课程列表用onShow加载，这样从前台切回小程序时列表数据会自动刷新，课堂签到流程的用户体验会好很多。

3.4 前后端联调与真机演示

联调阶段的顺序很关键，先用小程序开发工具连本地后端，接口全部验证通过后，再把后端部署到服务器上做真机测试。不要一上来就连服务器调试，服务器有网络延迟，很难判断是代码逻辑问题还是网络问题。

本地联调时要开启开发者工具的“不校验合法域名”选项。注意后端服务需要监听0.0.0.0而不是默认的localhost，否则真机无法通过局域网IP访问到你的开发机。跨域方面，因为小程序的请求不走浏览器同源策略，所以在开发阶段一般不需要后端处理CORS，但加了也无妨。

真机演示前要特别注意图片上传的路径问题。开发环境上传的图片存在本地服务器，真机访问的是部署后的服务器地址，图片的完整URL必须是可公网访问的地址，不能是localhost。我在帮学弟调试的时候，他上传图片后前端一直显示不出来，排查了半天发现是图片路径带了localhost前缀，这个细节很隐蔽。

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

4.1 登录接口报跨域错误或请求超时

这可能是毕设阶段遇到最多的一个问题。先确认后端有没有启动、监听端口是不是预期值，再用curl命令测试接口通不通。如果本机curl没问题但小程序请求报错，优先检查开发者工具是否勾选了不校验域名，以及后端是否监听在所有网络接口上。

还有个隐蔽的问题是HTTPS证书。如果后端部署在服务器上但没有配置HTTPS，小程序真机请求一定会被拦截。开发阶段就用HTTP调通，最后部署时在Nginx配置SSL证书换成HTTPS即可。有同学图省事直接在小程序后台把域名校验关掉，个人开发没问题，但如果是做毕业演示，还是规规矩矩配好HTTPS更稳妥。

4.2 Token过期导致操作中断

JWT token默认有效时长可以设置为2小时或7天，我这里设置的是7天，因为实验室日志系统的使用频率并不高，太频繁的过期会打断学生提交日志的操作。用户每次登录后重新颁发token，前端在收到401响应时自动跳转登录页。

这个方案注意一个细节，就是前端请求并发时，多个接口同时返回401，会触发多个跳转。可以在request.js封装里加一个isRedirecting的锁变量，避免重复跳转和弹窗。这个是在实际测试中发现的问题，不处理的话用户会看到登录页跳来跳去，非常影响体验。

4.3 图片上传失败或服务器存储空间不足

上传接口本身并不复杂，但毕设服务器通常是低配云服务器，磁盘空间有限。multer将上传的图片保存到本地上传目录后，需要定期清理。我在服务里加了一个定时任务，每天凌晨删除3天前的临时图片，保留已关联日志的图片。

另外注意multer的fileSize限制，默认是无限大。要显式设置单张图片最大不超过5MB，防止用户上传大尺寸照片占满磁盘。前端用wx.compressImage压缩后再传，双保险。

4.4 课程列表加载慢和分页问题

开发阶段数据量小时看不出问题，数据量过百条后，直接在服务端一次性返回所有课程列表就会明显卡顿。正确的做法是后端接口统一支持分页参数page和pageSize，前端使用scroll-view组件实现上拉加载下一页。同时需要注意列表数据用setData更新时，用concat追加而不是整体覆盖，减少渲染数据量。

调试时发现IOS下scroll-view的底部间距有一个固定值需要做兼容，在小程序端的样式适配中，这种平台差异还有不少。写代码时建议用rpx单位配合flex布局，避免在适配问题上花太多时间。

4.5 系统上线发布避坑

最终部署建议使用Linux服务器加Nginx反向代理，后端进程用pm2管理。pm2的配置文件中，设置好环境变量、日志输出路径、启动脚本，后续重启服务只需要pm2 restart。域名的HTTPS证书用免费的就行，不用花钱买，申请流程也简单。

还有一个常被忽略的问题：数据库备份。实验室日志属于长期保存的数据，一旦服务器故障丢失会很麻烦。写一个简单的shell脚本，用mysqldump每天凌晨自动备份数据库，保留最近7天的备份文件即可。这套流程加在论文的部署章节里，你又多了一个可以展示的技术亮点。

5. 文档、代码讲解与一条龙交付

5.1 毕业论文写作框架建议

技术做完了，论文如果写不明白，毕设依然过不了。这个项目的论文建议直接采用标准软件工程结构：绪论写背景和意义，接着写需求分析、系统设计、系统实现、系统测试、总结与展望。

写需求分析章节时，先画用例图，把用户角色和功能模块的对应关系梳理清楚。系统设计章节放数据库ER图和架构图。系统实现章节按模块拆分，每个模块先描述功能逻辑，再粘贴核心代码片段，最后附运行效果截图。这样的结构是答辩老师最熟悉也最容易通过的格式，非常稳妥。

5.2 代码讲解视频录制思路

代码讲解的核心是讲思路而不是逐行读代码。录制视频时，我建议按照这个顺序讲：先跑一遍系统演示完整流程，然后讲目录结构和数据表设计，再讲一个完整的功能链路（比如日志提交到审核通过），最后讲关键代码的实现细节。这四段加起来控制在15到20分钟，答辩老师大概率没时间看完整个演示，但会挑着看看流程是否完整。

讲逻辑时多用“为什么这样设计”的表述，比如“这里用JWT而不是session，是因为小程序端没有cookie机制”之类。这种有对比、有原因的讲解，比简单复述代码要加分得多。

5.3 一条龙定制服务包含什么

过去帮学弟学妹整理毕设素材时，我一般会交付一个完整清单：可运行的源码包，包含小程序端和后端完整代码；毕业论文原稿，格式已经排好版，需要替换个人信息后即可使用；开题报告和任务书模板；答辩演示PPT；代码讲解视频；以及一份部署手册。收到后按照部署手册操作，环境搭建到项目跑起来整体不超过两小时，这个交付标准还是很有参考价值的。

另外收尾前再分享一个实用经验：代码写完后做一次彻底的代码走查，把所有硬编码的数据库密码、密钥、测试地址都挪到配置文件里。很多同学的代码被老师拷到别的机器上跑不起来，十有八九就是环境配置写死在代码里。把这些配置抽出来，配合部署手册，基本上任何人拿到源码都能顺畅跑起来。这个习惯将来进入团队做项目也受用。