企业官网建设流程全解析

简介：这是一套基于Java、SpringBoot、Vue与MySQL技术栈开发的微信小程序急救常识学习系统，面向计算机相关专业的毕业生、课程设计学习者及需要急救知识普及平台的开发者。项目已通过导师指导并获高分，下载后无需修改即可直接运行，可作为毕设、课程设计或期末大作业的完整参考方案。压缩包共1331个文件，约34.14MB，涵盖136个Java后端源码、155个Vue前端组件、265个JavaScript脚本、440个PNG界面素材，以及66个WXSS与60个WXML小程序页面文件，另附数据库SQL脚本、Maven配置与说明文档，前后端代码与数据库脚本一应俱全。系统包含用户注册登录、急救常识图文展示、答题互动、后台内容管理及微信小程序接口等模块，界面美观、操作简单、管理便捷。目前已有88人学习下载，适合希望快速获得可运行完整项目、理解前后端分离架构与小程序开发流程的读者参考使用。

1. 急救常识学习小程序：一份能跑通前后端全链路的毕设源码

急救常识这件事，真正落到产品上，难点从来不是"知识本身"，而是怎么让用户在突发场景下三秒内找到正确处置步骤。这份基于 JAVA+SpringBoot+Vue+MySQL 的微信小程序急救常识学习系统，解决的正是这个场景：后端用 SpringBoot 提供分类、题库、学习记录接口，管理端用 Vue 做内容维护，小程序端负责用户答题、查看急救图文、记录学习进度。它适合三类人——正在做毕设需要一套完整可演示项目的同学、想练手 SpringBoot + 小程序联调的后端新手、以及需要一套急救知识类内容管理骨架的开发者。整套源码包含后端工程、Vue 管理后台、小程序前端和 MySQL 数据库脚本，属于典型的"三端一体"结构，拿来就能跑，改改就能交。

2. 三端架构拆解：SpringBoot 接口层、Vue 管理端与小程序如何分工

这套系统的价值不在于代码量，而在于它把"内容管理"和"用户学习"两条线拆得很干净。理解清楚三端各自的职责边界，后面部署和二次开发才不会乱。

2.1 后端 SpringBoot 的接口分层与 MyBatis-Plus 用法

后端是整个系统的中枢，常见做法是按 controller / service / mapper / entity 四层组织。急救常识系统里核心实体一般包括：急救分类（category）、急救知识文章（knowledge）、题库（question）、用户答题记录（record）、小程序用户（user）。MyBatis-Plus 在这里的作用是省掉大量单表 CRUD 的 XML，实体类上加好注解就能直接生成基础 SQL。

// Knowledge.java 实体示例 @Data @TableName("knowledge") public class Knowledge { @TableId(type = IdType.AUTO) private Long id; private String title; // 急救知识标题 private String categoryId; // 所属分类 private String content; // 图文内容 private Integer viewCount; // 浏览量 @TableField(fill = FieldFill.INSERT) private Date createTime; }

逻辑说明：@TableName把实体映射到数据库表，@TableId指定主键策略为自增，@TableField(fill = FieldFill.INSERT)配合 MetaObjectHandler 可以在插入时自动填充创建时间，省去手动 set。参数上要注意categoryId用 String 还是 Long 要和数据库字段类型一致，不一致时 MyBatis-Plus 查询会静默返回空列表，这是新手最容易翻车的地方。

分页查询是管理端列表的刚需，配置好分页插件后直接这样写：

// 分页查询急救知识 Page<Knowledge> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Knowledge> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(keyword), Knowledge::getTitle, keyword) .eq(StringUtils.hasText(categoryId), Knowledge::getCategoryId, categoryId) .orderByDesc(Knowledge::getCreateTime); return knowledgeMapper.selectPage(page, wrapper);

逻辑说明：LambdaQueryWrapper用方法引用代替字符串字段名，重构时不会因为改字段名而漏改 SQL。like和eq的第一个参数是条件开关，只有条件为 true 时才拼接该条件，这样一套代码同时支持"带关键词搜索"和"不带关键词全量查"。参数上pageNum从 1 开始，pageSize建议限制在 20 以内，否则小程序端一次拉太多数据会明显卡顿。

2.2 Vue 管理端的路由与接口对接

Vue 管理端负责内容维护，典型页面有分类管理、知识文章编辑、题库管理、用户学习记录查看。路由用 vue-router 配置，接口请求统一封装 axios 实例，把 baseURL 指向 SpringBoot 服务地址。

// request.js 统一封装 import axios from 'axios' const service = axios.create({ baseURL: process.env.VUE_APP_BASE_API, // 指向后端地址 timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) config.headers['Authorization'] = token return config }) export default service

逻辑说明：拦截器里统一挂 token，避免每个请求手动加。baseURL走环境变量，开发环境指向http://localhost:8080，打包后改成实际域名。参数上timeout设 10 秒比较稳妥，急救知识文章如果带大图，上传接口要单独放宽超时，否则大图上传必超时。

管理端打包后要放进 SpringBoot 的 static 目录一起部署，这是热词里"vue 打包放进 springboot 中"的典型场景。做法是把npm run build产出的 dist 内容拷到src/main/resources/static，然后配置一个转发规则，让非接口请求都回落到 index.html，否则刷新页面会 404。

2.3 小程序端的登录与数据获取

小程序端核心是登录态和列表渲染。登录流程是wx.login拿 code，传给后端换 openid，后端生成 token 返回。这里要注意，热词里"微信小程序登录获取手机号"是另一套流程，需要 button 的 open-type 配合，和基础登录不是一回事，别混用。

// 小程序登录 wx.login({ success: res => { wx.request({ url: `${baseUrl}/wx/login`, method: 'POST', data: { code: res.code }, success: r => { wx.setStorageSync('token', r.data.data.token) } }) } })

逻辑说明：code只能用一次，五分钟内有效，所以拿到后要立刻发给后端。后端用 code 调微信接口换 openid 和 session_key，再把自定义 token 返回给小程序存本地。参数上baseUrl在小程序里必须是 https 且已配置合法域名，本地调试要在开发者工具里勾选"不校验合法域名"，否则请求直接失败。

3. 从零跑起来：数据库导入、后端启动与小程序联调

拿到源码后最怕的是"跑不起来"，这一章按顺序把环境搭起来，每一步都给出可复制的操作。

3.1 MySQL 建库与数据导入

先在 MySQL 里建库，字符集用 utf8mb4，否则急救知识里的特殊符号会乱码。

CREATE DATABASE first_aid DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE first_aid; -- 然后执行源码里的 first_aid.sql SOURCE /path/to/first_aid.sql;

逻辑说明：utf8mb4比 utf8 多支持 emoji 和部分生僻字，急救内容里如果有图标字符必须用它。SOURCE命令在命令行客户端里执行，如果用的是 Navicat 这类工具，直接右键"运行 SQL 文件"更省事。导入后检查表数量，一般 5 到 8 张表属于正常范围，少了说明脚本没跑完。

数据库连接配置在application.yml里改：

spring: datasource: url: jdbc:mysql://localhost:3306/first_aid?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver

逻辑说明：serverTimezone必须显式指定，不写的话 MySQL 8 会报时区错误。characterEncoding=utf8配合库的 utf8mb4 使用，驱动版本 8.x 用com.mysql.cj.jdbc.Driver，5.x 用com.mysql.jdbc.Driver，写错直接启动失败。

3.2 后端启动与接口自测

后端用 Maven 构建，命令行进入项目根目录执行：

mvn clean package -DskipTests java -jar target/*.jar

逻辑说明：-DskipTests跳过测试加快打包，毕设项目一般没写测试用例，不跳过反而可能因为测试类报错卡住。启动成功后控制台会打印端口，默认 8080。用浏览器或 Postman 访问一个列表接口验证，比如http://localhost:8080/knowledge/list，能返回 JSON 就说明后端通了。

如果启动报Table 'xxx' doesn't exist，八成是数据库没导入或库名对不上；报Access denied就是账号密码错；报端口占用就改server.port。这几个是启动阶段最高频的问题。

3.3 Vue 管理端与小程序联调

管理端先装依赖再启动：

npm install npm run serve

逻辑说明：npm install如果卡住，换国内镜像源能明显提速。启动后访问控制台提示的地址，一般是 8081 或 8082。登录管理端后先加一条急救分类和一篇知识文章，确认数据能写进数据库，这一步通了说明前后端联调没问题。

小程序端用微信开发者工具打开源码目录，改app.js或配置文件里的baseUrl指向后端地址。本地调试勾选"不校验合法域名"，真机预览则必须用 https 域名。小程序顶部导航栏高度这个点要注意，自定义导航栏时不同机型高度不一样，用wx.getSystemInfoSync().statusBarHeight动态算，写死数值在部分机型上会错位。

4. 避坑与排查：跑这套源码最容易翻车的五个地方

这一章全是血泪经验，每条都按"现象 → 原因 → 解决"写，遇到问题直接对号入座。

现象一：后端启动报时区错误The server time zone value is unrecognized。原因：MySQL 8 的时区配置和 JDBC 驱动默认值不匹配。 解决：连接串里加serverTimezone=Asia/Shanghai，或者进 MySQL 执行SET GLOBAL time_zone = '+8:00'。

现象二：小程序请求全部失败，控制台提示不在合法域名列表。原因：小程序正式环境只允许 https 且已备案的域名。 解决：开发阶段在开发者工具"详情 → 本地设置"里勾选"不校验合法域名"，上线前把后端域名配到小程序后台的 request 合法域名里。

现象三：Vue 打包放进 SpringBoot 后，刷新页面 404。原因：前端路由是 history 模式，刷新时请求打到了后端，后端找不到对应接口。 解决：加一个配置类，把非 api 开头的请求都转发到 index.html，或者把前端路由改成 hash 模式。

现象四：MyBatis-Plus 查询返回空列表，但数据库里明明有数据。原因：实体字段类型和数据库字段类型不一致，或者@TableName写的表名和实际表名对不上。 解决：逐字段核对类型，开启 MyBatis-Plus 的 SQL 日志logging.level.com.xxx.mapper=debug，看实际执行的 SQL 长什么样，一目了然。

现象五：小程序登录后拿不到用户信息，token 存了但接口还是 401。原因：请求头里没带 token，或者后端拦截器校验的 header 名和前端设置的不一致。 解决：统一约定 header 名为Authorization，前端拦截器统一加，后端拦截器统一读，别一个用 token 一个用 Authorization。

提示：这套源码涉及三端，任何一端配置错都会表现为"跑不起来"，排查时按"数据库 → 后端 → 前端 → 小程序"的顺序逐层验证，别一上来就怀疑代码。

5. 二次开发进阶：把急救知识系统改成你自己的题库应用

跑通只是第一步，真正让这套源码产生价值的是二次开发。急救常识系统的骨架其实是一个通用的"内容 + 题库 + 学习记录"模型，把急救知识换成任何垂直领域的内容都能复用。

先说题库模块的扩展。原始题库一般是单选，要加多选和判断，核心是改question表的type字段和答案存储格式。单选答案存A，多选存A,B,C，判断存true/false。前端渲染时按 type 分支处理，判分逻辑也要跟着改：

// 判分逻辑 public boolean checkAnswer(String userAnswer, String correctAnswer, Integer type) { if (type == 1) { // 单选 return userAnswer.equals(correctAnswer); } else if (type == 2) { // 多选，排序后比较 List<String> u = Arrays.asList(userAnswer.split(",")); List<String> c = Arrays.asList(correctAnswer.split(",")); Collections.sort(u); Collections.sort(c); return u.equals(c); } return false; }

逻辑说明：多选判分必须先排序再比较，否则用户选B,A和正确答案A,B会被判错，这是题库类项目最经典的坑。参数上type用整数枚举，1 单选 2 多选 3 判断，别用字符串，字符串比较容易因为大小写和空格出问题。

再说学习记录的统计。原始系统一般只存答题记录，要加"学习时长"和"连续打卡"，可以在record表加duration和study_date字段，用一条 SQL 统计连续天数：

SELECT COUNT(DISTINCT study_date) FROM record WHERE user_id = #{userId} AND study_date >= DATE_SUB(CURDATE(), INTERVAL 7 DAY);

逻辑说明：这条 SQL 统计近七天有学习记录的天数，配合前端展示"本周学习 X 天"。参数上INTERVAL 7 DAY可以按需改成 30 天做月度统计。注意study_date要存日期而不是时间戳，否则 DISTINCT 去重会失效。

最后说一个验证方法：改完任何模块，别只看页面能不能点，要直接查数据库确认数据落库正确。我一般会准备几条边界数据——空答案、超长内容、特殊字符——跑一遍，能过这几条，基本就不会在答辩或演示时翻车。从那以后我每次拿到这类三端源码，都强制先跑一遍边界数据再动业务代码，省下的返工时间远比测试花的多。希望帮到你。

本文还有配套的精品资源，点击获取