企业官网建设流程全解析

简介：一份校园反诈骗微信小程序毕业设计资料包，基于微信小程序、SSM框架与MySQL数据库构建，面向计算机专业毕业生和需要完成小程序项目的开发者。系统包含管理员与用户两种角色，管理员可管理用户、安全知识、知识竞赛及试题，用户能注册登录、浏览安全知识并参与在线竞赛，覆盖校园反诈骗宣传与学习场景。资源共947个文件，压缩包约44.07MB，以页面图片、图标素材、前端组件、后端逻辑代码及脚本配置文件为主，另含数据库脚本、演示视频和启动辅助文件，便于部署调试与二次开发。已有650人学习下载。除完整源码和毕业论文外，还提供数据库初始化脚本与操作视频，可快速跑通从环境搭建到功能验证的流程，也能用于毕业设计答辩展示或功能扩展。整体结构清晰，模块划分明确，对学习微信小程序和SSM整合开发有较好的参考价值。

1. 校园反诈骗微信小程序：这一套毕业设计到底能做什么

校园反诈宣传一直有个尴尬：海报贴了没人细看，班会讲了转头就忘，真遇到诈骗时学生又不知道去哪举报、去哪核实。把自己做的校园反诈骗微信小程序拿出来，核心就干三件事——把反诈案例做成随时能查的库，把举报入口收到微信里，再把后台处理状态透明化。这套基于微信小程序 + SSM + MySQL 的毕业设计，前端用小程序承载页面，后端用 SSM 提供接口，MySQL 落数据，再加上论文和演示视频，正好覆盖了一个完整业务系统的开发链路。对正在选毕业设计题目的学生来说，它业务边界清楚、技术栈经典、工作量可控；对想快速搭一套反诈演示系统的开发者，它也足够轻。这篇文章按我实际做过的同类项目顺序来写，从拆业务、建表、写接口到小程序对接和排错，一步步给方案。

2. 业务模块与数据库设计：三个角色、四张表把反诈流程做完整

2.1 反诈业务的最小功能集：学生、管理员、内容三块

先别急着写代码，做这类系统我习惯先把用户和动作理一遍。校园反诈骗小程序里，角色就两种：普通学生用户和管理员。学生端能浏览反诈案例、看反诈资讯、提交举报、查看自己的举报进度；管理员端则负责发布案例和资讯、处理举报、统计常见诈骗类型。不要一上来就设计复杂的权限模型，角色字段直接写在用户表里，代码里做个拦截就够了，毕业论文里也能画出清晰的用例图。

功能模块我建议收敛成四块，够完整又不至于做不完。案例库负责展示典型诈骗手段，资讯模块用来发预警通知，举报模块是核心闭环，个人中心承担登录态和个人信息展示。下面是模块对应的角色和落地页面。

这个功能集对毕业设计来说是恰到好处的：它有真实的业务闭环，不是简单的增删改查；同时每个模块的复杂度都不高，数据库表控制在个位数，论文里能把模块图画清楚，答辩时也能把每个表的作用讲明白。我见过不少同学把社区团购、二手交易那种业务搬过来，功能堆得多，最后数据库十几张表、前端十几个页面，做到中期就想换题。反诈选题的优势恰恰在于“小而有闭环”。

2.2 SSM 分层与表结构：四张表撑起整个反诈闭环

SSM 即 Spring + SpringMVC + MyBatis，它最值钱的不是技术新，而是分层足够显式。浏览器或小程序发来的请求先进 DispatcherServlet，由 Controller 接收并做参数绑定，然后调 Service 完成业务处理，Service 再通过 MyBatis 的 Mapper 接口操作 MySQL。每一层职责清楚，毕业论文里架构图好画，答辩被追问时也能从 Controller 到 Mapper 一层层说出请求的路径。用 Spring Boot 也可以，但很多学校毕业设计的技术要求里明确写了 SSM，而且 SSM 的配置都是手写 XML，对理解 Spring 容器和依赖注入反而更扎实。

数据库设计我按反诈业务的实际流程来。用户表存学生和管理员账号；案例表存诈骗类型、标题、内容、来源；举报表是整个系统的核心，记录谁在什么时间举报了什么内容，当前处理状态是什么；资讯表存站内反诈预警消息。四张表之间靠外键关联，比如举报表的 user_id 指向用户表的 id，user_id 用于数据隔离和“我的举报”查询。

案例表里的 type 字段用来区分刷单、冒充客服、裸聊、虚假购物这些常见诈骗类型，这个字段建议用字符串枚举而不是数字，原因很直接：小程序端下拉框要展示“刷单返利 / 冒充公检法 / 虚假购物”这种文案，存数字还得再维护一张字典表，毕业设计没必要绕这一层。举报表的 status 字段用数字状态机，0 待处理、1 处理中、2 已处理，这样后台处理的流转能在接口里用 switch 判断，演示时也方便展示状态变化。建表时统一字符集 utf8mb4，排序规则选 utf8mb4_general_ci。

3. 搭好后端 SSM 工程：登录接口与举报接口的实现

3.1 项目骨架与 MyBatis 配置：四张表对应的三层代码

后端我按标准的 Maven war 包结构组织，分成 controller、service、dao（mapper）、entity（pojo）四层，外加 resource 下的 Spring 和 MyBatis 配置文件。这种结构的项目在 IDEA 里新建时选 Maven 的 Web 模板就能生成，不需要额外脚手架。下面这段是 spring-mybatis.xml 里最核心的数据源和 SqlSessionFactory 配置，也是整个项目能跑起来的前提。

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"> <property name="driverClassName" value="com.mysql.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/anti_fraud?useUnicode=true&amp;characterEncoding=utf8&amp;serverTimezone=Asia/Shanghai"/> <property name="username" value="root"/> <property name="password" value="123456"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="configLocation" value="classpath:mybatis-config.xml"/> </bean>

两点必须说明。第一，MySQL 8.x 驱动和 5.x 驱动不一致，如果你本机是 MySQL 8，driverClassName 要换成com.mysql.cj.jdbc.Driver，不换会启动报错；第二，url 里的serverTimezone=Asia/Shanghai是给 8.x 驱动用的，不加它连数据库时大概率报时区异常。这个配置里我把密码写成了 123456，实际项目里要改成你自己的数据库密码。

mybatis-config.xml 里还有一处容易被忽略的配置，它直接影响查询结果能不能正确封装成对象，那就是驼峰映射。

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings>

这个配置把数据库的下划线字段自动映射成 Java 里的驼峰属性，比如create_time自动对应createTime。没有它，你的 User 实体里 createTime 字段查出来永远是 null，因为 MyBatis 默认不会自动做下划线到驼峰的转换。这是一个典型的“跑起来不报错，数据全是空”的隐形坑。

3.2 微信登录对接：code 换 openid 与自有 Token 方案

小程序端不能直接拿到用户身份，正确的登录姿势是：小程序调用wx.login拿到一个临时 code，把这个 code 传给后端，后端用 appid、secret 和 code 去微信官方接口换取 openid。openid 是用户在当前小程序里的唯一身份标识，用它去 user 表查记录，查不到就自动注册一条新用户。因为标题要求用 SSM + MySQL，而传统 HttpSession 在小程序这种无 Cookie 环境下很别扭，我建议直接把登录态做成 token 模式：登录成功后生成一个 UUID 作为 token，存在一个全局 Map 里，同时返回给小程序，小程序后续请求在 header 里带上它。

public LoginResult wxLogin(String code) { String url = "https://api.weixin.qq.com/sns/jscode2session?" + "appid=" + appid + "&secret=" + secret + "&js_code=" + code + "&grant_type=authorization_code"; String resp = HttpUtil.get(url); JSONObject obj = JSON.parseObject(resp); String openid = obj.getString("openid"); if (openid == null) { return LoginResult.fail("code 已失效，请重新登录"); } User user = userMapper.selectByOpenid(openid); if (user == null) { user = new User(); user.setOpenid(openid); user.setRole(0); userMapper.insert(user); } String token = UUID.randomUUID().toString().replace("-", ""); tokenStore.put(token, user.getId()); return LoginResult.ok(token, user); }

这段代码里，appid 和 secret 需要从小程序后台获取，测试阶段可以用微信提供的测试号，不需要真实上线。tokenStore 我用的是ConcurrentHashMap<String, Integer>，key 是 token，value 是用户 id，对毕业设计演示来说完全够用；要追求完善可以引入 Redis，但那是加分项不是必需项。注意微信接口返回的 openid 是敏感信息，不要直接存到日志里。整个登录链路里最容易出错的位置是 code 过期，开发者工具里如果频繁重启调试，code 会失效，这时接口返回的就不是 openid 而是 errcode，代码里判空就能兜住。

3.3 举报接口：Controller、Service、Mapper XML 的完整链路

举报接口是反诈系统的核心链路，也是论文里能展开讲的亮点。我设计的动作是：学生提交举报时携带诈骗类型、描述、联系方式，后端从 token 里解析出用户 id，把举报记录插入数据库，状态默认置为待处理。管理员通过另一个接口拉取所有待处理举报，处理后回写 status 和 handleResult。前端做表单提交时，我把请求方法定义为 POST，token 放在请求头里，后端用@RequestHeader接收。

@RestController @RequestMapping("/api/report") public class ReportController { @Autowired private ReportService reportService; @PostMapping("/add") public Result add(@RequestBody Report report, @RequestHeader("token") String token) { Integer userId = tokenStore.getUserId(token); if (userId == null) { return Result.fail("登录已过期，请重新登录"); } report.setUserId(userId); report.setStatus(0); reportService.add(report); return Result.ok(); } }

Controller 里做三件事：校验登录态、补齐用户 id 和初始状态、交给 Service 落库。这里的 Result 是统一的响应体，结构为{ code: 0, msg: "ok", data: ... }，code 为 0 表示业务成功，非 0 表示失败，小程序端统一用它判断接口是否正常，而不是只靠 HTTP 状态码。

Mapper 的 XML 里有一个值得注意的细节：

<insert id="insert" parameterType="Report" useGeneratedKeys="true" keyProperty="id"> insert into report(user_id, case_type, description, contact, status, create_time) values(#{userId}, #{caseType}, #{description}, #{contact}, #{status}, now()) </insert>

useGeneratedKeys="true"配合keyProperty="id"的意思是：数据库自增生成的 id 在插入完成后回填到传入的 Java 对象里。这样后续如果需要拿着 reportId 去做其他操作，不用再查一遍数据库。create_time 字段直接用 MySQL 的now()生成，而不是在 Java 里 new Date() 传进去，理由很简单：数据库时间最可靠，避免应用服务器和数据库服务器时钟不一致。举报类型这个字段在 Service 层建议做个枚举校验，防止小程序端传任意字符串进来，保持数据可统计。

4. 小程序端实现：页面结构、请求封装与登录态管理

4.1 页面目录与 tabBar 设计：五个页面覆盖反诈主流程

小程序端我从 app.json 的 tabBar 配起。tabBar 页面放四个：首页、案例库、举报、我的，案例详情和举报记录作为非 tabBar 页面，从列表页跳转进入。这种结构对应业务上“浏览-学习-举报-追踪”四个动作，也跟后端四张表一一对应。目录结构如下。

pages/ index/ 首页，展示反诈资讯和最新预警 cases/ 案例库列表 detail/ 案例详情 report/ 举报表单 mine/ 个人中心 utils/ request.js 封装 wx.request auth.js 登录态管理 app.js app.json

app.json 里需要把 tabBar 页面注册进tabBar.list，每个 tab 至少配 text 和 iconPath，icon 可以放本地图片。没配 icon 会导致编译报错，这是小程序最基础但也最容易在赶工时忽略的问题。案例详情页之所以不放进 tabBar，是因为详情页语义上是二级页面，放进 tabBar 会让底部导航在详情页也显示，交互上很怪。

4.2 请求封装与 Token 注入：每个页面都不重复写 wx.request

小程序里最值得先封装的就是请求模块。没有封装之前，每个页面都要写一遍 wx.request 的 success 回调、fail 回调、loading 提示，代码冗余不说，等你想统一改 baseURL 的时候会想骂人。我习惯把请求封装成一个返回 Promise 的函数，页面里用 async/await 调用，代码干净，排错也方便。

const BASE_URL = 'http://localhost:8080/anti_fraud'; function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + path, method: method, data: data, header: { 'Content-Type': 'application/json', 'token': wx.getStorageSync('token') || '' }, success(res) { if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg || '请求失败', icon: 'none' }); reject(res.data); } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); } module.exports = { request, BASE_URL };

这段封装里我做了两个约定。第一个约定是业务成功以res.data.code === 0为准，HTTP 状态码 200 只代表请求到达了后端，不代表业务成功；后端返回的 msg 在失败时会统一弹 toast，页面里就不用每个接口都写失败提示了。第二个约定是 token 从 Storage 里取，每次请求自动注入 header，新写页面时只要调 request 方法，登录态就自动带上。这里有一个新手常犯的错误是把 token 放在wx.getStorageSync('token')之外再加一层全局变量，小程序冷启动后全局变量会丢失，而 Storage 不会。

4.3 案例列表与举报表单：分页、下拉刷新与状态处理

案例列表用常见的分页加载模式，page 从 1 开始，每页 10 条，滑动到底部自动加载下一页，下拉时重置分页参数重新拉取。下面这段代码是案例列表页的核心逻辑。

Page({ data: { list: [], page: 1, pageSize: 10, hasMore: true, loading: false }, onLoad() { this.loadCases(); }, async loadCases() { if (this.data.loading) return; this.setData({ loading: true }); try { const data = await request('/api/cases', 'GET', { page: this.data.page, pageSize: this.data.pageSize }); this.setData({ list: this.data.list.concat(data.list), hasMore: data.list.length === this.data.pageSize }); } finally { this.setData({ loading: false }); } }, onReachBottom() { if (this.data.hasMore) { this.setData({ page: this.data.page + 1 }); this.loadCases(); } }, onPullDownRefresh() { this.setData({ list: [], page: 1, hasMore: true }); this.loadCases().then(() => wx.stopPullDownRefresh()); } });

hasMore的判断逻辑是：如果这一页返回的记录数等于 pageSize，说明后面还有数据，反之说明已经到最后一页。这个判断方式依赖后端正确返回 total 或按照 pageSize 截断。后端接口里@RequestParam(defaultValue = "1") int page处理页码，LIMIT #{offset}, #{pageSize}处理数据库分页，offset 的计算需要在 Service 层做(page - 1) * pageSize。

举报表单页用的是传统表单思路，form 里放 picker 选择诈骗类型、textarea 填描述、input 填联系方式，提交时把表单数据序列化成 JSON 发给后端。如果要做图片证据上传，用wx.chooseMedia选图，再用wx.uploadFile上传到后端，后端用MultipartFile接收并保存到服务器磁盘，把返回的 URL 存入举报记录表。不过对毕业设计来说，图片上传是加分项，文字举报闭环已经足够支撑演示和论文。

5. 避坑与排查：从请求失败到中文乱码的几个常见问题

5.1 真机预览请求全部失败，开发者工具却一切正常

现象：小程序在微信开发者工具里跑得好好的，案例列表都能正常加载；换到真机预览，所有接口全失败，页面空白或一直转圈。

原因：开发者工具默认勾选了“不校验合法域名”，所以 http://localhost 或局域网 IP 都能直接请求；但真机上小程序运行在微信客户端环境，要求所有 request 的域名必须是已配置的合法域名且为 HTTPS。本地开发阶段，你的电脑 IP 不属于合法域名，真机自然连不上。

解决：本地联调时让手机和电脑连同一个 Wi-Fi，把 BASE_URL 里的 localhost 改成电脑的局域网 IP，比如 192.168.1.100:8080；同时在开发者工具的“详情 - 本地设置”里勾选“不校验合法域名”。如果要在手机上彻底跑通，需要在小程序后台配置服务器域名，并把后端部署到 HTTPS 环境，这一步对演示来说通常不必要。

5.2 后端接口全部 404：Controller 没有被 Spring 容器扫描到

现象：Tomcat 正常启动，数据库连接也正常，但访问/api/case/list时返回 404；有时访问静态页面正常，Controller 接口全部失效。

原因：Spring 的组件扫描没有覆盖到 controller 包。最常见的是spring-mvc.xml里的context:component-scan配的 base-package 写错了，比如后端代码在com.xxx.anti.controller，扫描配的是com.xxx.system。另一种可能是 DispatcherServlet 的 url-pattern 配成了*.do，而请求路径没有后缀。

解决：检查 Spring MVC 配置文件里的扫描路径是否与 controller 所在包一致，确保DispatcherServlet的映射配成/而不是/*。/*会拦截所有请求包括静态资源，导致静态资源被 Controller 接管而返回 404。改完配置重新编译部署，再用浏览器直接访问接口地址验证。

5.3 查询结果字段全是 null：下划线与驼峰的映射问题

现象：案例列表接口返回了完整 JSON，但每条记录的 createTime、caseType、viewCount 都是 null，而 title、content 这类单字段名正常。

原因：MyBatis 默认把数据库列名create_time映射到 Java 属性时需要完全一致的名字，而实体类里写的是createTime，两边对不上，结果就是 null。单字段像 title 没有下划线所以正常。

解决：在 mybatis-config.xml 里开启驼峰映射 ——<setting name="mapUnderscoreToCamelCase" value="true"/>。也可以在 Mapper XML 里给每个带下划线的字段起别名create_time as createTime，但一劳永逸的办法是开启全局配置。这个坑排查起来很隐蔽，因为 SQL 没报错、接口也返回了数据，只有字段值对不上。

5.4 举报描述里的中文全部变成问号

现象：小程序端提交的举报描述，在数据库里看到的内容是一串???，英文和数字正常。

原因：数据库连接 URL 缺少编码参数，或者表/字段的字符集是 latin1。MySQL 默认连接字符集在某些版本下不是 utf8，导致客户端传来的 UTF-8 中文被错误转码。

解决：在 JDBC URL 上追加useUnicode=true&characterEncoding=utf8，建表时用DEFAULT CHARSET=utf8mb4。注意 XML 里&要转义成&，否则 Spring 解析配置文件会报错。如果改完已有表的字符集，用ALTER TABLE report CONVERT TO CHARACTER SET utf8mb4，已存在乱码的数据只能重新插入，没有后悔药，所以这个配置在建库时就要一步到位。

5.5 登录态一刷新就丢：Session 方案在小程序环境下的局限

现象：登录成功跳转到个人中心后，用户昵称能正常显示；但杀掉小程序重新打开，或者过一段时间再操作，接口开始提示未登录。

原因：后端用了 HttpSession 存登录态，而小程序没有 Cookie 容器，wx.request不会自动维护 Session。即使开发者工具里第一次请求带上了 Cookie，下次冷启动时 Session 找不回来。把 token 存在globalData里也有同样问题，小程序冷启动后 globalData 重新初始化，存储就没了。

解决：登录成功后把 token 写入wx.setStorageSync('token', token)，后端每次从 header 读取 token 并查 tokenStore 得到用户 id。Storage 的持久化在小程序生命周期内是稳定的，冷启动后也能正常读取。联调时如果发现登录态异常，先看开发者工具的 Storage 面板里是否有 token，再看后端请求头是否带上了 token，两步就能定位。

6. 演示、答辩与数据恢复：让这套系统稳稳落地

6.1 预置数据与一键重置：别让演示现场页面空荡荡

演示翻车最常见的原因不是代码 bug，而是数据库里没数据。我养成的习惯是准备一份完整的初始化脚本，里面包含建库建表语句、预置的管理员账号、8 到 10 条真实的诈骗案例、几条状态各异的举报记录。演示前跑一遍脚本，所有页面打开就有内容，不用现场现编数据。重置数据库用一行命令就够了。

mysql -uroot -p < anti_fraud.sql

anti_fraud.sql 里要包含DROP TABLE IF EXISTS再CREATE TABLE，保证重复执行不会报错。个人账号我用一个测试号替代真实微信登录，后端提供一个 mock 登录接口直接返回固定 openid，避开现场依赖网络换取 openid 的不确定性。

6.2 演示路径设计：两分钟走完主闭环

我建议按“登录 - 浏览案例 - 提交举报 - 管理员处理 - 状态更新”这条线走。时长压在两分钟内，先演示完整流程让答辩老师看到系统到底做了什么，再回到代码里讲 SSM 三层请求路径。讲到 SpringMVC 时停留在 Controller 和配置文件，讲到 MyBatis 时打开 Mapper XML 指向一条 SQL。论文里的架构图不用多，一张三层架构图加一张 ER 图足够支撑整个答辩讲解。视频演示录制时先重置数据库再走流程，保证界面数据和讲解一致。

这套系统做完后的真实收益是：你对“请求从前端到数据库再返回”这条链路的理解，比只看教程深刻得多。我自己第一次演示时就吃过亏，现场网络波动导致 fetch openid 失败，整个登录演示卡死，后来补了 mock 登录接口才稳住。吃一堑长一智，现在凡是依赖外部服务的环节，我都会准备一个本地兜底方案。希望这篇笔记帮到你，也祝你答辩顺利。

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