企业官网建设流程全解析

简介：本资源为基于微信小程序的宠物寄养平台毕业设计论文，面向计算机相关专业学生及需要完成小程序类毕设的开发者。论文围绕宠物寄养场景，解决传统寄养信息不对称、服务不规范等问题，采用微信小程序前端与SSM框架后端、MySQL数据库实现。全文约一万字，涵盖摘要、背景意义、技术介绍、需求与可行性分析、功能分析、业务流程、数据库设计、ER图、数据字典、数据流图、详细设计、系统截图、测试、总结、致谢及参考文献，重点阐述宠主管理、宠物种类管理、寄养环境管理、宠物寄养管理等模块。资源包共1个doc文件，大小约1.18MB，结构完整，可直接作为论文写作模板与项目设计参考。目前已有521人学习下载，适合需要快速搭建论文框架、理解小程序与SSM整合思路的读者借鉴。

1. 从一份毕设论文包说起：宠物寄养小程序到底交付了什么

很多做微信小程序毕设的同学，卡的不是写不出代码，而是不知道一份“能过审、能跑通、能讲清楚”的论文包应该长什么样。这份基于微信小程序的宠物寄养平台论文，核心交付物是一套完整的 SSM + 小程序技术方案：前端用微信小程序承载用户浏览寄养环境、在线预约寄养、管理个人寄养记录；后端用 Spring + SpringMVC + MyBatis 处理业务逻辑与数据持久化；数据库用 MySQL 存储宠主、宠物种类、寄养环境、寄养订单等核心数据。它解决的不是“怎么做一个商业平台”，而是“怎么在有限篇幅内把需求分析、数据库设计、功能实现、系统测试串成一条可答辩的线”。适合正在做小程序方向毕设、需要参考论文结构和技术选型的人，也适合想快速了解 SSM 与小程序如何对接的开发者。论文正文里那张 ER 图和十张数据库表，才是真正值得逐行拆开看的部分。

2. 技术选型拆解：为什么是 SSM + 小程序 + MySQL

2.1 小程序端与 SSM 后端的职责边界

这套方案里，微信小程序负责的是“展示层”和“轻交互层”。用户打开小程序，看到的是寄养环境列表、宠物种类筛选、在线寄养表单、个人寄养记录。这些页面不直接连数据库，而是通过wx.request调用后端暴露的 HTTP 接口。后端 SSM 负责接收请求、校验参数、执行 SQL、返回 JSON。这种前后端分离的边界，在论文里对应的是“系统功能结构设计”那一章。

常见做法是：小程序端只保留页面渲染和表单收集逻辑，所有涉及金额、状态流转、权限判断的操作全部放在后端。比如“是否已支付”这个字段，小程序端只负责展示，真正修改它的是后端在支付回调后的更新操作。这样设计的好处是，即使小程序端被反编译，核心业务逻辑也不会直接暴露。

论文里提到的“用户分为管理员和普通用户”，在代码层面就是两套接口权限。普通用户只能调/user/下的接口，管理员调/admin/下的接口。SSM 里通常用拦截器或 Spring Security 做粗粒度控制，毕设级别用拦截器就够了。

2.2 MySQL 表结构里的几个关键设计

论文第 3 章给出了十张表的完整字段定义，其中chongwujiyang（宠物寄养表）是业务核心。这张表有几个字段值得注意：

这里有个新手容易翻车的地方：ispay用 varchar 而不是 tinyint。论文里默认值是“未支付”，说明作者用中文字符串做状态标记。这种设计在毕设里能跑通，但实际开发中更推荐用tinyint(1)或枚举，避免中文字符集问题导致状态判断失效。如果你要复现这套表结构，建议把ispay改成tinyint(1) DEFAULT 0，0 表示未支付，1 表示已支付。

另一个细节是addtime字段用了timestamp类型，默认值CURRENT_TIMESTAMP。这意味着插入记录时不需要手动传时间，MySQL 会自动填充。但要注意，如果你的服务器时区不是东八区，存进去的时间会差 8 小时。常见做法是在 JDBC 连接串里加serverTimezone=Asia/Shanghai。

2.3 从 ER 图到建表语句的落地步骤

论文里的 ER 图是概念模型，真正建库需要转成物理模型。我一般会按这个顺序操作：

第一步，先建基础字典表。chongwuzhonglei（宠物种类表）和config（配置表）不依赖其他表，先建。

-- 宠物种类表：只存种类名称，id 自增 CREATE TABLE chongwuzhonglei ( id bigint(20) NOT NULL AUTO_INCREMENT, addtime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, chongwuzhonglei varchar(200) NOT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

第二步，建用户和宠主表。chongzhu表里存了账号、姓名、密码、性别、头像、联系电话。密码字段论文里没写加密方式，毕设级别常见做法是 MD5 存储，但更稳妥的是 BCrypt。如果你只是复现论文，MD5 够用；如果要写进简历，建议换成 BCrypt。

-- 宠主表：账号唯一，密码建议加密存储 CREATE TABLE chongzhu ( id bigint(20) NOT NULL AUTO_INCREMENT, addtime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, chongzhuzhanghao varchar(200) NOT NULL, chongzhuxingming varchar(200) NOT NULL, mima varchar(200) NOT NULL, xingbie varchar(200) DEFAULT NULL, touxiang varchar(200) DEFAULT NULL, lianxidianhua varchar(200) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_zhanghao (chongzhuzhanghao) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

第三步，建寄养环境表和寄养订单表。jiyanghuanjing表存环境名称、图片、价格、描述；chongwujiyang表存订单号、宠物信息、寄养时长、费用、支付状态。这两张表通过chongzhuzhanghao关联。

-- 寄养订单表：核心业务表，ispay 建议改 tinyint CREATE TABLE chongwujiyang ( id bigint(20) NOT NULL AUTO_INCREMENT, addtime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, jiyangdanhao varchar(200) DEFAULT NULL, chongwumingcheng varchar(200) DEFAULT NULL, chongwuzhonglei varchar(200) DEFAULT NULL, chongwuxingbie varchar(200) DEFAULT NULL, shifoujueyu varchar(200) DEFAULT NULL, chongwunianling varchar(200) DEFAULT NULL, kaishishijian date DEFAULT NULL, jiyangshizhang int(11) DEFAULT NULL, tuoguanfeiyong float DEFAULT NULL, zongfeiyong float DEFAULT NULL, chongzhuxingming varchar(200) DEFAULT NULL, chongzhuzhanghao varchar(200) DEFAULT NULL, yuyueshijian datetime DEFAULT NULL, jiyangyuanyin longtext, beizhu longtext, ispay varchar(200) DEFAULT '未支付', PRIMARY KEY (id), KEY idx_zhanghao (chongzhuzhanghao) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

建完表后，用SHOW CREATE TABLE chongwujiyang;检查字符集和索引是否生效。如果CHARSET不是utf8mb4，中文宠物名会变成问号。

提示：论文里的表名和字段名全是拼音，这是毕设常见风格。实际项目建议用英文命名，但复现论文时保持拼音能减少对照成本。

3. 核心功能实现：在线寄养流程的代码落地

3.1 小程序端提交寄养申请的完整链路

用户在小程序里选好寄养环境、填写宠物信息、选择开始时间和寄养时长，点击提交。这个动作在小程序端对应一个wx.request调用：

// 小程序端：提交寄养申请 wx.request({ url: 'https://your-domain.com/ssm/jiyang/add', // 后端接口地址 method: 'POST', header: { 'content-type': 'application/json', 'token': wx.getStorageSync('token') // 登录后存的令牌 }, data: { chongwumingcheng: this.data.petName, // 宠物名称 chongwuzhonglei: this.data.petType, // 宠物种类 chongwuxingbie: this.data.petGender, // 宠物性别 shifoujueyu: this.data.isNeutered, // 是否绝育 chongwunianling: this.data.petAge, // 宠物年龄 kaishishijian: this.data.startDate, // 寄养开始日期 jiyangshizhang: this.data.duration, // 寄养时长（天） tuoguanfeiyong: this.data.unitPrice, // 托管单价 chongzhuxingming: this.data.ownerName, // 宠主姓名 chongzhuzhanghao: this.data.ownerAccount, // 宠主账号 jiyangyuanyin: this.data.reason, // 寄养原因 beizhu: this.data.remark // 备注 }, success(res) { if (res.data.code === 200) { wx.showToast({ title: '申请已提交', icon: 'success' }); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); } }, fail() { wx.showToast({ title: '网络异常，请重试', icon: 'none' }); } });

这段代码的关键参数有三个：token用于后端识别当前用户，chongzhuzhanghao用于关联宠主表，jiyangshizhang和tuoguanfeiyong用于后端计算总费用。后端收到请求后，不会直接信任前端传来的zongfeiyong，而是用jiyangshizhang * tuoguanfeiyong重新计算，防止前端篡改金额。

3.2 后端 SSM 的 Controller 与 Service 分层

后端接收请求的入口是 Controller。论文里没有贴具体代码，但按 SSM 的标准写法，JiyangController大概长这样：

// 后端 Controller：接收寄养申请 @RestController @RequestMapping("/jiyang") public class JiyangController { @Autowired private JiyangService jiyangService; @PostMapping("/add") public Result add(@RequestBody JiyangDTO dto, HttpServletRequest request) { // 从 token 中解析当前用户账号 String account = (String) request.getAttribute("currentAccount"); if (account == null) { return Result.error("请先登录"); } // 校验必填字段 if (dto.getChongwumingcheng() == null || dto.getKaishishijian() == null) { return Result.error("宠物名称和开始时间不能为空"); } // 计算总费用，不信任前端传值 float total = dto.getJiyangshizhang() * dto.getTuoguanfeiyong(); dto.setZongfeiyong(total); dto.setChongzhuzhanghao(account); dto.setIspay("未支付"); // 生成寄养单号：时间戳 + 随机数 String orderNo = "JY" + System.currentTimeMillis() + (int)(Math.random() * 900 + 100); dto.setJiyangdanhao(orderNo); jiyangService.add(dto); return Result.success("申请已提交"); } }

这里有几个参数需要说明：@RequestBody表示接收 JSON 格式的请求体；Result是统一返回封装，包含code、msg、data三个字段；JiyangDTO是数据传输对象，字段与前端传参一一对应。Service 层负责调用 MyBatis 的 Mapper 接口，把 DTO 转成实体类后插入数据库。

MyBatis 的 Mapper XML 里，插入语句大概是这样：

<!-- MyBatis Mapper：插入寄养订单 --> <insert id="insert" parameterType="com.example.entity.Chongwujiyang"> INSERT INTO chongwujiyang ( jiyangdanhao, chongwumingcheng, chongwuzhonglei, chongwuxingbie, shifoujueyu, chongwunianling, kaishishijian, jiyangshizhang, tuoguanfeiyong, zongfeiyong, chongzhuxingming, chongzhuzhanghao, jiyangyuanyin, beizhu, ispay ) VALUES ( #{jiyangdanhao}, #{chongwumingcheng}, #{chongwuzhonglei}, #{chongwuxingbie}, #{shifoujueyu}, #{chongwunianling}, #{kaishishijian}, #{jiyangshizhang}, #{tuoguanfeiyong}, #{zongfeiyong}, #{chongzhuxingming}, #{chongzhuzhanghao}, #{jiyangyuanyin}, #{beizhu}, #{ispay} ) </insert>

#{}是 MyBatis 的占位符，会预编译成?，防止 SQL 注入。如果写成${}，就是直接拼接字符串，有注入风险。毕设里经常有人混用，答辩时被问到会扣分。

3.3 管理员审核与状态流转

管理员登录后，看到的是待审核的寄养订单列表。审核动作本质上是更新ispay字段或增加一个status字段。论文里没有单独的状态字段，用ispay兼顾了支付状态。管理员点击“确认寄养”后，后端执行：

// 管理员审核通过：更新支付状态 @PostMapping("/admin/confirm") public Result confirm(@RequestParam Long id) { Chongwujiyang order = jiyangService.getById(id); if (order == null) { return Result.error("订单不存在"); } if ("已支付".equals(order.getIspay())) { return Result.error("该订单已确认"); } order.setIspay("已支付"); jiyangService.update(order); return Result.success("确认成功"); }

这段逻辑里，先查后改是常见做法，但并发场景下会有问题：两个管理员同时点确认，可能都查到“未支付”，然后都执行更新。毕设级别可以忽略，实际项目要用乐观锁或UPDATE ... WHERE ispay = '未支付'的方式。

注意：论文里的“在线支付”功能，毕设通常只做到“模拟支付”——点击按钮后直接把状态改成已支付，不接真实支付接口。如果你要写进论文，测试章节要说明这是模拟支付，避免答辩时被追问支付凭证。

4. 避坑与排查：复现这套论文包时最容易翻车的五个点

4.1 小程序请求域名未配置导致真机调试失败

现象：开发者工具里接口能通，真机预览时所有请求都失败，控制台报“不在以下 request 合法域名列表中”。

原因：微信小程序对wx.request的域名有白名单限制，开发者工具可以勾选“不校验合法域名”，但真机不行。

解决：登录微信公众平台，在“开发管理 → 开发设置 → 服务器域名”里把后端接口域名加进 request 合法域名。如果后端还没部署到公网，真机调试时在开发者工具里勾选“不校验合法域名”只能解决工具端，真机需要域名备案 + HTTPS。

4.2 MySQL 时区不一致导致寄养时间差 8 小时

现象：小程序端选的开始时间是 2025-06-01，数据库里存的是 2025-05-31 16:00:00。

原因：MySQL 服务器时区是 UTC，Java 应用时区是东八区，JDBC 连接没有指定时区。

解决：在 JDBC 连接串里加serverTimezone=Asia/Shanghai，完整写法：jdbc:mysql://localhost:3306/pet_foster?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai。同时检查 MySQL 的global time_zone和session time_zone，用SELECT @@global.time_zone, @@session.time_zone;查看。

4.3 MyBatis 字段名与实体类属性不匹配导致插入为空

现象：插入寄养订单后，数据库里chongwumingcheng字段是 NULL，但前端明明传了值。

原因：MyBatis 默认开启驼峰命名映射，但论文里的字段名是拼音，没有下划线，实体类属性名如果写成chongWuMingCheng，映射会失败。

解决：在 MyBatis 配置文件里关闭驼峰映射mapUnderscoreToCamelCase=false，或者保持实体类属性名与数据库字段名完全一致。更稳妥的做法是在 Mapper XML 里显式写resultMap，把字段和属性一一对应。

4.4 小程序端 token 过期后接口全部 401

现象：用户登录后能用一段时间，之后所有请求返回 401，但重新登录又正常。

原因：后端 token 设置了过期时间，小程序端没有做续期或重新登录引导。

解决：在小程序端的wx.request封装里统一拦截 401，清除本地 token 并跳转到登录页。常见做法是写一个request.js工具函数，所有接口调用都走这个函数，在fail或statusCode === 401时统一处理。

4.5 论文里的 ER 图与建表语句不一致

现象：照着 ER 图建表，发现评论表discussjiyanghuanjing里有refid和userid，但 ER 图里只画了“评论信息”实体，没有体现关联关系。

原因：ER 图是概念模型，省略了外键字段；建表语句是物理模型，必须包含关联字段。

解决：以建表语句为准。refid关联寄养环境 ID，userid关联评论用户 ID。如果论文答辩时被问到 ER 图与表结构的关系，回答“ER 图展示实体与联系，物理表通过外键字段实现联系”即可。

5. 从论文包到可演示系统：我的验证习惯与一个实用技巧

复现这套论文包，最怕的是“代码能跑，但数据对不上”。我自己的习惯是：先把论文第 3 章的十张表全部建好，然后手动插入三条测试数据——一个管理员、一个宠主、一个寄养环境。然后用 Postman 或 curl 直接调后端接口，确认增删改查都能通，再打开小程序端联调。这样能把问题定位在后端还是前端，省去来回翻日志的时间。

一个实用技巧是：在chongwujiyang表里加一个status字段，用0/1/2表示“待审核/已确认/已完成”，而不是只靠ispay的“未支付/已支付”。论文里用ispay兼顾了支付状态，但实际演示时，管理员审核和支付是两个动作，混在一起容易讲不清楚。加一个status字段后，小程序端的“我的寄养”页面可以按状态筛选，答辩时演示效果更直观。

-- 给寄养订单表加状态字段，不影响原有 ispay ALTER TABLE chongwujiyang ADD COLUMN status tinyint(1) NOT NULL DEFAULT 0 COMMENT '0待审核 1已确认 2已完成';

改完之后，后端查询列表时按status排序，小程序端用不同颜色标签展示。这个改动不大，但能让整个演示流程从“提交申请 → 管理员审核 → 用户查看状态”串成一条完整的线，而不是提交完就结束了。

从那以后我每次拿到一份毕设论文包，都先跑一遍“建表 → 插数据 → 调接口 → 联调前端”这条链路，确认数据能闭环再去看论文里的流程图和用例图。希望帮到你。

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