企业官网建设流程全解析

又到毕业设计选题季，每年这时候“微信小程序”都是计算机专业的热门方向，但热门归热门，很多同学拿到“基于微信小程序实现科创微应用平台管理系统”这类题目时，第一反应是搜源码、找模板、问学长要现成Demo。我见过太多人卡在同一个地方：不是不会写代码，而是根本没想清楚这个系统到底要做什么、业务流程怎么走、数据表怎么设计，最后东拼西凑交上去，答辩时被老师一问就露馅。

这篇就以“科创微应用平台管理系统”为例，把整个项目从业务梳理、技术选型、数据库设计、接口开发、小程序端实现到管理后台建设完整拆一遍，顺带把毕业设计论文的写法和答辩时容易被追问的点也整理出来。不管你是自己从零写，还是拿到别人的源码想改造成自己的，这篇文章都能帮你少走不少弯路。

1. 这个平台到底要管什么：先把业务模型想清楚

很多做毕设的同学拿到的题目描述只有一句话，比如“实现一个科创微应用平台管理系统”，然后就懵了——到底是管项目的？管人员的？还是管申报流程的？实际上“科创微应用”这四个字指向了一个非常典型的高校场景：学生课外科技实践活动的全流程数字化管理。

这类系统的本质，就是把线下纸质化的“第二课堂”流程搬线上：学校发布科研项目、竞赛通知，学生在线报名或申报，指导老师审批，系统记录参与过程并折算成积分或学分，辅导员和学院管理员查看数据、导出报表。所以它不只是一个简单的内容展示小程序，而是一个带审批流、带角色权限、带积分统计的业务管理系统。

1.1 从“第二课堂”到“科创微应用平台”的真实使用场景

先还原一个具体场景，你就能理解业务模型了：

某学院每学期要组织“大学生创新创业训练计划项目申报”，往年学生填Excel表、打印签字、交纸质材料、老师人工汇总，光收集材料就要一星期，还经常有人填错格式。有了这个平台后，流程变成：

• 管理员在后台发布“2024年大创项目申报通知”，附上申报要求和截止时间。
• 学生打开微信小程序，看到通知，点击“我要申报”，填写项目名称、成员信息、指导老师、项目简介、预期成果，上传申报书PDF。
• 指导老师在小程序或管理后台看到待审批列表，通过或驳回，驳回时填写意见。
• 学院管理员定期查看申报汇总数据，导出Excel交到学校。

除了项目申报，平台上通常还有竞赛报名、学术讲座签到、科研成果登记、积分查询等模块。这些业务虽然形态各异，但骨架都一样：发布 → 申报/报名 → 审批 → 记录 → 统计。

1.2 核心业务流转：一条申报单走过的完整生命周期

把业务抽象成状态流转，是设计数据库和接口前最重要的一步。以“项目申报单”为例，一条记录会经历：

草稿（仅自己可见） → 已提交（等待指导老师审核） → 审核通过（进入执行阶段） → 审核驳回（学生可修改后重新提交） → 中期检查（提交进度报告） → 结题验收（成果登记、积分发放）

在实际系统里，我建议状态字段用数字或简短字符串常量表示，不要直接在代码里散落中文状态。原因很简单：后期改需求时，你只需要改一处常量定义，而不是满项目搜索“已提交”三个字。同时，状态流转最好记录日志表，谁在什么时候把状态从A改成了B，这条日志要留底，答辩时这是“系统设计合理性”的加分证据。

1.3 四个基础角色与权限边界

这个平台至少有四类角色，权限边界必须清晰：

权限设计上有两种思路：一是用Spring Security / Shiro这类框架做细粒度权限控制；二是毕设场景下更常见、也更简洁的做法——用一个role字段区分角色，后端接口做拦截校验。如果项目周期紧，第二种完全够用，但要注意：角色校验不能只在前端做，接口层必须校验，否则学生直接调接口就能给自己加积分，答辩必挂。

2. 技术选型：为什么是这套组合，而不是其他

毕设项目最忌技术选型“大而全”。见过有同学为了炫技，小程序用Taro、后端用微服务、数据库用MongoDB加Redis缓存再加消息队列，结果写完登录就想放弃。科创微应用平台这种系统，并发量根本到不了需要微服务的级别，合理的选型应当是“主流、熟悉、文档多、能讲清楚”。

2.1 小程序端选型：原生还是 uni-app

小程序端两条主流路线：

• 微信原生小程序：wxml + wxss + js，api文档全、社区资源多、踩坑答案好搜，毕业设计最稳妥的选择。缺点是同一套代码没法直接跑抖音小程序、支付宝小程序。
• uni-app：Vue语法，一套代码多端发布。如果你Vue基础好，可以选这个，写起来确实舒服，但排查问题时往往要在框架层多绕一圈。

我的建议是：你的课题名称明确写了“微信小程序”，那就老老实实用原生。毕设答辩老师看的是你是否理解小程序生命周期、组件通信、api调用，原生实现这些点最直观、最好讲。用uni-app确实省事，但你把“我用了uni-app封装”这句话放到答辩台面上，老师追问“那Vue生命周期和小程序生命周期怎么对应的”时，很容易被问住。

2.2 服务端与后台管理端的搭配逻辑

服务端最常见的毕设组合是Spring Boot + MyBatis Plus + MySQL，理由很实在：

• Spring Boot 简化配置，适合快速开发，行业内就是绝对主流；
• MyBatis Plus 提供了BaseMapper，单表CRUD几乎不用写SQL，能省大量时间；
• MySQL 免费、普及率高、资料多，对于这种规模的数据量完全够用。

后台管理端用Vue 3 + Element Plus + Vite是这几年最顺手的组合。Vite启动快，Element Plus 组件齐全，表格、表单、弹窗都能现查现用。管理端不必太花哨，功能覆盖全面、操作顺畅远比好看重要。如果你不太熟悉Vue，管理端也可以直接采用服务端渲染的Thymeleaf模板，但说实话，毕设管理端页面多、交互多，用Vue会轻松非常多。

服务端、小程序、后台管理端三个端之间通过RESTful API通信，数据格式统一用JSON。这样一个“前后端分离”的架构，无论是画架构图还是写论文架构章节，都很好渲染。

2.3 数据库设计的核心表结构

这部分是整个系统的基础，表设计错了后面处处别扭。核心表不必贪多，先把这些设计好，基本覆盖平台主要功能：

用户侧：

• user（用户表）：openid、昵称、头像、学号/工号、真实姓名、学院id、角色role、手机号、创建时间。
• college（学院表）：学院名称、编码。
• role（角色表，可选）：如果角色就固定四角色，可以不用单独建表，用字段+枚举就够。

业务侧：

• project（项目表）：标题、项目类型（大创/竞赛/科研助手）、申报人id、指导老师id、所属学院id、简介、预期成果、附件url、状态status、创建时间、审核时间。
• project_member（项目成员表）：项目id、成员id、成员角色（负责人/成员）、排序号。
• review_log（审批日志表）：业务类型（项目/竞赛/积分）、业务id、操作人id、动作（提交/通过/驳回）、意见、时间。
• competition（竞赛活动表）：标题、封面、报名开始/截止时间、活动描述、最大人数、状态。
• signup（竞赛报名表）：活动id、用户id、报名时间、状态。
• notice（通知公告表）：标题、内容、发布人id、置顶标记、发布时间。
• credit_record（积分记录表）：用户id、来源类型（项目立项/竞赛获奖/论文发表）、来源id、变动值（正负）、说明、时间。

这里有个容易忽略的点：项目成员关系必须用单独关联表，不要用逗号分隔的字符串“成员A,成员B,成员C”存进一个字段。第一次答辩时见过一个同学就这样设计，老师只问了一句“那你怎么统计某个学生参与了多少个项目”，他就答不上来了。关联表看似多了一张表，但统计、查询、扩展都方便得多。

3. 服务端接口设计：登录态、权限校验与核心 API

服务端是三个端的“中枢”，接口设计是否合理，直接影响小程序和管理端的开发效率。这一章把最关键的几个部分说透。

3.1 微信登录的完整数据流

微信小程序登录是每个做小程序的人都必须摸清的流程，整个链路是这样的：

1. 小程序端调用wx.login()获取临时登录凭证code。
2. 小程序端通过接口把code传给后端。
3. 后端通过code+appid+secret调用微信官方接口https://api.weixin.qq.com/sns/jscode2session，换取openid和session_key。
4. 后端根据openid查用户表，老用户直接返回登录态，新用户则自动注册一条记录。
5. 后端生成自定义登录态（一般是加密后的session信息），返回给小程序端，小程序端存入本地storage。
6. 后续请求，小程序端在请求头或参数中带上这个登录态，后端解析后识别用户身份。

注意几个坑：code只能用一次，5分钟内有效；session_key不能下发到小程序端，需要解密用户敏感信息时才用得上；appid和secret一定不能写在小程序端代码里，否则等于把自己账号的钥匙扔进公共场所。

自定义登录态的生成，毕设级别最简单的做法是：随机token + Redis存储（key为token，value为userId），或者直接使用JWT。JWT不需要Redis存储，服务端无状态，写起来也直接，但要注意设置过期时间和密钥。代码示意这样：

// 生成JWT String token = Jwts.builder() .setSubject(userId.toString()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

3.2 核心 API 清单与状态设计

按业务模块划分，接口清单大致如下：

每个接口都要设置权限注解或拦截器校验。我习惯的做法是写一个LoginInterceptor，拦截所有需要登录的路径，从token解析userId后放入ThreadLocal，业务代码直接获取。角色校验则通过自定义注解@RequireRole("admin")标注在Controller方法上，由拦截器统一处理。这样业务代码里面不会到处飞着角色判断，答辩时讲“统一鉴权设计”也更清晰。

3.3 审核状态机的实现思路

项目申报审核是系统中最核心的流程，状态变化必须联动几个表：项目表状态更新、审批日志插入、用户积分变动。

用一个简单的方法来封装状态变更逻辑，比如审核通过方法：

@Transactional public void reviewProject(Long projectId, Long reviewerId, boolean approved, String opinion) { Project project = projectMapper.selectById(projectId); if (!"已提交".equals(project.getStatus())) { throw new BizException("当前状态不可审核"); } // 更新项目状态 project.setStatus(approved ? "已立项" : "已驳回"); project.setReviewerId(reviewerId); project.setReviewTime(new Date()); projectMapper.updateById(project); // 写审批日志 ReviewLog log = new ReviewLog(); log.setBizType("project"); log.setBizId(projectId); log.setOperatorId(reviewerId); log.setAction(approved ? "通过" : "驳回"); log.setOpinion(opinion); reviewLogMapper.insert(log); }

@Transactional必须加，否则状态更新和日志写入两条操作只成功一条就出问题了。对了，哪怕比较基础的代码，异常抛出时也要保证事务回滚，这个知识点很多基础好的人都会忽略。还有一处容易漏：审核通过给申报人加积分，这一步也要放在同一个事务里，积分变动表也要留记录。

4. 小程序端核心模块：从首页到申报表单

小程序端的体验直接决定用户愿不愿意用这个平台，所以页面结构、交互细节、接口对接都得认真打磨。这里挑几个关键模块说。

4.1 首页与通知的呈现逻辑

小程序首页不要堆太多功能按钮，那是后台管理端该干的事。面向学生用户，首页应该像一个“办事大厅”，明确告诉用户当前有哪些事可以做、有哪些缓存消息没处理。

通常布局是：顶部轮播图（放重要竞赛海报）、中间是功能入口宫格（项目申报、竞赛报名、积分查询、我的项目）、下方是通知列表。通知列表只显示标题、发布时间，点击跳转详情页。

这里有一个产品细节要注意：“待办提醒”比纯通知列表更有价值。比如学生的申报单被老师驳回了，首页必须有显眼的红点或待办卡片，否则用户根本不知道要重新提交。这个功能做起来也就是多查一次“我的申报单中有几条状态是‘驳回’”，但对用户体验提升极大，也是答辩时可以讲故事的功能点。

4.2 申报表单的校验与文件上传

申报表单是使用频率最高的交互模块。以项目申报为例，至少包含：项目名称（input）、项目类型（picker）、指导老师（picker）、成员（动态添加列表，每人含姓名+学号）、项目简介（textarea）、预期成果（多选）、附件（上传PDF/Word）。

表单校验必须前后端都做。前端用form组件的校验规则，只做基础校验（非空、长度），真正严格的校验在后端。比如项目名称必须唯一、附件必须是PDF且不超过10MB，这些规则如果只在前端做，攻击者绕过前端直接调接口就全废了。

文件上传用wx.chooseMessageFile选择文件后，通过wx.uploadFile传给后端。这里有个开发经验要分享：小程序端上传大文件时容易超时，建议后端配置合理的超时时间，同时前端要显示上传进度，否则用户看到一直转圈就会退出重来。后端接收文件时要注意目录安全，不要直接把上传文件名拼进路径，生成UUID作为文件名存储，文件后缀用白名单过滤。

4.3 积分明细的查询展示

积分模块做起来不难，但细节容易出错。积分展示页面通常需要两个维度：

• 汇总卡片：当前总积分、本学期积分、累计积分。
• 明细列表：分页展示每一条积分变动，包含时间、来源、数值（正负）、状态。

积分类型建议用枚举区分，例如 PROJECT_ESTABLISH（项目立项，+20分）、COMPETITION_PRIZE（竞赛获奖，分等级加分）、TUTOR_REJECT（驳回扣除，-5分）等。枚举的好处是前端可以根据类型显示不同图标和文案，后端统计时也能按类型分组汇总。

这里提醒一句：积分一旦和毕业要求挂钩，就不要让用户手动自报积分。所有积分必须由系统在审核通过等业务节点自动产生，管理员的“手动调分”操作要写清楚调分原因。这一点在答辩时会被重点关注，提前准备了就不慌。

4.4 setData 性能与真机调试

原生小程序最需要留意的性能坑就是setData。你每调用一次setData，微信都要把数据从逻辑层传送到渲染层，数据量越大越慢。常见优化手段：

• 按需更新，不要一次性 setData 整个大对象；
• 列表页用分页加载，一次只拉20条，不要一次几百条塞进页面；
• 变更单条列表项时，用this.setData({ ['list[' + index + '].status']: '已通过' })精准更新，而不是把整个list重新set一遍。

真机调试也是必踩坑场景。我遇到过最典型的：模拟器里一切正常，真机上登录接口一直失败。查了半天发现是wx.login的 code 被某些安卓机型延迟返回，处理方式是要在success回调里再调后端接口，不要在wx.login之后直接同步拿code。还有本地storage在真机上的隔离性和清缓存策略都不一样，调试时需要特别留意。开发时建议多用真机调试，不要只在模拟器上点来点去，问题早暴露早解决。

5. 管理后台：审核、统计与权限

管理后台是“管理”二字的落地之处，也是区分这类系统和小工具类小程序的关键。管理端做得好，整个系统的“管理系统”属性才立得住。

5.1 审核工作台的设计

管理后台的第一屏应是待办中心，也就是“审核工作台”。它汇总了当前所有需要处理的事项：待审核的项目申报、待审核的竞赛报名、待处理的其他申请。每一项列出来，点击进入详情即可快速通过或驳回。

这里要提供一个“批量审核”能力，因为实际使用中老师会遇到十几份申报材料要审批的情况，一个一单太耗时间。批量审核界面通常做成表格勾选+批量操作按钮，后端接口支持批量更新，一个事务里处理所有选中的记录。别看这个功能逻辑不复杂，它是“真正站在用户角度设计过”的体现，也是很多模板代码里做得最粗糙的地方。

5.2 用户与积分管理

用户管理页面至少要有：用户列表查询（按姓名/学号/学院/角色筛选）、新增用户、修改角色、重置密码、禁用账号。为什么要有“禁用”功能？因为有些非微信登录方式（比如管理员在后台直接创建账号）需要密码登录，学生毕业后账号应该被停用。

积分管理是管理端的高频操作，也是注意力最该集中的地方。管理员的调整界面设计要注意“操作留痕”：调整数值、填写原因都是必填项，保存时自动写入积分记录表和操作日志表。这样任何一次积分变动都可追溯，学院拿这个表公示都行。你把这个细节写进论文里，“系统的可追溯性设计”这一小节就有了很扎实的内容支撑。

5.3 数据统计可视化的常见布局

数据看板是让管理端“装得像个管理系统”的利器，通常放在后台首页。用ECharts即可，常见统计项：

• 平台用户总数、本周新增用户数
• 项目申报总数、审核通过率
• 各学院申报数量柱状图
• 竞赛报名人数趋势折线图
• 积分发放总额、各来源积分占比饼图

后端提供对应的统计接口，比如“按学院分组统计项目申报数量”“按月份统计用户增长数”，SQL基本都是GROUP BY聚合，写起来不复杂。前端取到聚合结果后传给ECharts渲染即可。注意统计接口的数据量要控制，比如趋势图按月汇总就够，没必要查每一天的明细然后在前端聚合。

6. 毕设出彩点与论文写法

同样的题目，有人拿到良，有人拿到优，差距往往不在功能多少，而在“有没有超出预期的设计”和“会不会讲”。这一章专门说怎么让项目在答辩中更出彩、论文怎么组织。

6.1 在功能之外还能加哪些低成本亮点

毕设没必要追求大而全，但一两个亮点功能就能让评分上一个档次。以下这几个都是实现成本不高、但答辩时很能打的：

• 审批流转记录可视化：在项目详情页展示一条时间线，从提交到审批到立项，每一步的节点、操作人、审批意见都清晰可见。本质就是把review_log表的数据按时间倒序渲染出来，工作量不大，但“系统的可审计性”立刻直观起来。
• 管理员导出Excel报表：把项目列表、积分明细、报名名单导出成Excel，用EasyExcel或者POI做，代码量不大，但这是很多真实管理系统的刚需，答辩时展示一次导出效果，很加分。
• 通知模板消息推送：学生提交申报或审核状态变更时，通过微信订阅消息提醒用户。申请流程、用户留存都更真实，每年答辩都有一批评委吃这一套。
• 申请单打印/PDF导出：学生提交后的申报单可以自动生成带格式的PDF版本，方便线下盖章存档。后端用itext或Java配合模板生成PDF，前端留一个“生成PDF”入口即可。

你不需要全加，挑一个做扎实就好。深度远比广度重要。

6.2 论文结构与核心章节怎么写

毕设论文通常有固定框架：绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结。核心章节的写法要注意：

需求分析 | 除了写功能需求，一定要写用例图和用例描述。每个角色配一个用例图，把“学生”和“管理员”这两种最主要的角色画清楚。比如学生的用例至少包括：注册登录、浏览通知、项目申报、查看审批状态、竞赛报名、查看积分明细。

系统设计 | 架构图、功能模块图、数据库ER图一个不能少。一般画三层架构：表现层（小程序端+管理端）、业务逻辑层（服务端接口）、数据层（MySQL）。功能模块图按平台功能拆：通知公告模块、项目申报模块、竞赛报名模块、积分管理模块、系统管理模块。数据库ER图用工具根据实际表结构生成，不要手画一个跟代码对不上的图，答辩老师核验代码时一眼就能看出造假。

系统实现 | 不要写流水账，要挑两三个核心功能详细写。比如项目申报功能的流程：前端页面交互描述 + 后端Service实现类代码片段 + 核心SQL。代码片段不必全贴，贴关键的几十行加注释就好。这里核心原则是：论文里写的每一段代码都必须真实来自你的项目。

6.3 答辩时最容易被追问的几个点

提前准备好以下问题的答案，答辩基本稳了：

• “为什么项目立项状态要设计成‘提交/已立项/已驳回’三个，而不是加一个‘草稿’？”——答：草稿是在前端本地暂存，不提交到服务端；一旦提交就进入审批流，状态由服务端维护。
• “积分只能加不能扣，毕业了有人虚报怎么办？”——答：这也是我系统里把审批和积分流程绑定的原因，只有当老师审核通过后系统才自动加分，学生本人不能发起加分申请；管理员调分会有记录。
• “如果用户量大，这个系统性能瓶颈在哪？你怎么优化？”——答：目前单体架构够用，如果用户量增长，首要优化是数据库索引（经常查询的字段如状态、创建时间加索引），以及列表查询的分页优化。
• “你的微信登录安全吗？怎么防止伪造请求？”——答：登录凭证code仅由后端通过secret换openid，前端拿到的只有jwt token，后端每次请求校验签名和过期时间。

这些问题其实都在考察是不是真的自己做的。把代码吃透、数据库关系理清，就能从容应对。

7. 实测踩坑记录与调试建议

最后写几个我在开发这类小程序系统时真实踩过的坑，很多都是折磨人一整天才查出来的问题，希望你能直接跳过。

7.1 登录态失效与并发刷新导致的问题

很多同学在写接口请求时，遇到token过期，就弹出提示“请重新登录”。这个设计只有一个问题：如果小程序页面里有多个请求同时发出去，全部都会因为token过期失败，弹窗也会弹出多次，体验很糟糕。

比较好的处理方式是做“请求拦截器 + 统一刷新token队列”。当某个请求返回401时，拦截器先不急着提示，而是串行刷新token，刷新成功后排队的其他请求都用新token重发，只有刷新失败才去提示登录失效。这样说起来复杂，但用Promise实现几十行搞定。论文里把这个一写，“异常处理与用户体验优化”章节就有实际内容了。

7.2 富文本图文详情在小程序里的适配

发布竞赛通知时，内容往往是富文本，包含图片、加粗、列表等排版。在Web后台用富文本编辑器存了HTML，小程序端直接渲染时发现样式全乱了、图片还变形。因为小程序的rich-text组件对HTML支持有限，很多CSS样式不生效。

最省心的方案是：管理端富文本编辑器只允许用户做有限排版操作（标题、段落、图片、列表），前端发布时把图片压缩后转存到自己的文件服务器，富文本内容入库时做清洗，过滤掉未知标签和脚本内容。小程序端渲染用rich-text，能覆盖95%的场景。如果一定要高度还原公众号文章那种排版，就需要改用webview加载H5页面了，但毕设没必要做这么重。

再提示一个和富文本无关但经常一起出现的坑——图片上传要限制大小。手机拍摄的照片动辄5MB、10MB，上传速度和服务器存储都是压力。管理端和小程序端都要做压缩或大小限制，服务端也要做校验，超出大小直接拒绝。

7.3 小程序审核、真机访问与后端接口的边界问题

小程序开发好后，如果要发布上线，需要通过微信公众平台的审核。审核过程中最容易撞上的问题是：

• 小程序要求所有功能必须对用户真实可用，不能出现测试数据、空白占位页面；
• 涉及“大学”“科研”等高校业务，部分类目需要提供相关资质，学生个人开发者账号可能受限。

所以毕设小程序一般建议在“体验版”阶段演示即可，不一定非要发布到线上。但演示时要注意一个细节：真机访问本地后端接口，必须用局域网IP或者内网穿透地址，不能写localhost。很多同学在自己电脑上跑后端，模拟器里好好的，手机一访问就全部失败，原因就是手机的localhost指向的是手机自己。

如果你需要在手机上做演示，最简单的办法是让电脑和手机连同一个Wi-Fi，后端启动时绑定0.0.0.0，接口地址填电脑的局域网IP（比如http://192.168.1.6:8080），然后在微信开发者工具里关闭“不校验合法域名”选项。这个demo阶段这么做没问题，真要发布上线就必须配置HTTPS域名并在公众平台备案，这个流程也是毕业设计论文里“系统部署”一章很好的素材。

另外顺便说一下，校园真实环境里这类系统还会对接学校的统一身份认证，获取学生的真实学号和姓名，而不是像毕设demo一样只用微信昵称。虽然这块在毕设里做不出来（也不可能拿到学校的认证接口），但你在论文展望里写一句“未来可对接学校统一身份认证，提升数据真实性”，档次就高了。

做这类管理系统，最核心的收获不是学会了某个框架，而是完整走了一遍“业务分析 → 数据库建模 → 接口设计 → 前端实现 → 测试演示”的闭环。这套流程在任何行业做开发都会反复用到。如果只是想把毕设凑合做完，照着上面的表结构把CRUD写全就差不多了；如果想拿到高分，把业务流转、权限边界、状态设计这些“看不见的部分”做扎实，然后在答辩时把这个思考过程讲清楚，效果远胜于堆砌八个华而不实的模块。最后说个个人建议，拿到源码后第一件事不是急着跑起来，而是先画一遍数据库ER图，再对照业务代码看一遍状态流转，能把这个过程独立走下来，答辩基本就立于不败之地了。