企业官网建设流程全解析

简介：本资源为基于微信小程序的宠物寄养平台毕业设计论文，面向计算机相关专业学生及需要完成小程序类毕设的开发者，帮助解决选题、系统设计与论文撰写问题。压缩包内共1个doc文件，约1.18MB，内容为完整论文正文，涵盖摘要、绪论、开发技术介绍、需求与可行性分析、功能分析、业务流程分析、数据库设计、ER图、数据字典、数据流图、详细设计、系统截图、测试、总结、致谢及参考文献等章节。论文以微信小程序为前端、SSM框架与MySQL数据库为后端，围绕宠主管理、宠物种类管理、寄养环境管理、宠物寄养管理及管理员审核等模块展开，并配有ER图与数据流图辅助理解。目前已有516人学习下载，适合作为毕设写作模板、系统设计参考与答辩准备材料，可帮助读者快速理清小程序类项目的开发流程与论文结构。

1. 从一份 SSM 小程序毕设源码说起：宠物寄养平台到底在解决什么问题

宠物寄养这件事，线下跑了十几年，痛点一直没变：宠主找不到靠谱的寄养环境，寄养机构接单靠微信聊天记录，寄养期间宠物状态全靠对方发几张照片。信息不对称、流程不透明、费用结算靠口头约定，一旦出问题双方都说不清。这份基于微信小程序的宠物寄养平台毕设，本质上就是把这套线下流程搬到线上，用小程序做用户入口，用 SSM 做后台管理，用 MySQL 落数据。

它适合谁看？一是正在做小程序方向毕设的本科生，需要一套能跑通、能写进论文、能答辩的完整工程；二是想快速了解「小程序 + Java 后端」这套组合拳怎么落地的前后端开发者。整套系统分管理员和普通用户两个角色，管理员管宠主、宠物种类、寄养环境、寄养订单，用户在小程序端浏览环境、在线下单寄养。技术栈不新，但胜在结构完整、表设计清晰，拿来改造成其他预约类小程序（比如家政、场地租赁）也很快。

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

2.1 小程序端为什么不用 uniapp 而直接原生开发

毕设场景下，原生小程序开发是更稳的选择。uniapp 虽然能一套代码多端发行，但编译到小程序时经常遇到样式错位、原生组件层级问题，调试成本反而更高。原生开发直接用微信开发者工具，wx.request调后端接口，wx.login拿 code 换 openid，链路短、问题少。常见做法是：页面用Page({})注册，数据绑定走setData，网络请求统一封装一个request.js，把 baseURL、token 注入、错误码处理收在一处。

// utils/request.js const BASE_URL = 'http://localhost:8080/jiyang' function request(options) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + options.url, method: options.method || 'GET', data: options.data || {}, header: { 'content-type': 'application/json', 'token': wx.getStorageSync('token') || '' // 登录后写入的令牌 }, success(res) { if (res.data.code === 0) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg, icon: 'none' }) reject(res.data) } }, fail(err) { reject(err) } }) }) } module.exports = { request }

这段封装做了三件事：统一拼接 baseURL，避免每个页面写死地址；自动带上本地缓存的 token，后端拦截器据此判断登录态；把code === 0约定为业务成功，其余情况弹提示并 reject。参数上options.url是相对路径，options.method默认 GET，options.data是请求体。改后端地址时只动BASE_URL一处。

2.2 后端 SSM 三层怎么分工

SSM 里 Spring 管 Bean 和事务，SpringMVC 管请求路由，MyBatis 管 SQL 映射。落到这个项目：Controller 层接收小程序请求，比如/chongwujiyang/add对应新增寄养订单；Service 层写业务逻辑，比如下单时校验寄养环境是否可预约、计算总费用；Mapper 层对应 XML 里的 SQL。MyBatis 的sqlSessionFactory通过mybatis-config.xml加载，Mapper 接口和 XML 通过 namespace 绑定。

<!-- mapper/ChongwujiyangMapper.xml 片段 --> <insert id="insert" parameterType="com.entity.Chongwujiyang"> INSERT INTO chongwujiyang (jiyangdanhao, chongwumingcheng, chongwuzhonglei, chongwuxingbie, chongwunianling, kaishishijian, jiyangshizhang, tuoguanfeiyong, zongfeiyong, chongzhuxingming, chongzhuzhanghao, ispay) VALUES (#{jiyangdanhao}, #{chongwumingcheng}, #{chongwuzhonglei}, #{chongwuxingbie}, #{chongwunianling}, #{kaishishijian}, #{jiyangshizhang}, #{tuoguanfeiyong}, #{zongfeiyong}, #{chongzhuxingming}, #{chongzhuzhanghao}, '未支付') </insert>

parameterType指定入参实体，#{}是预编译占位符，能防 SQL 注入。ispay直接写死'未支付'，因为下单时还没付款，付款后走 update 改状态。注意id是auto_increment，不用手动传。

2.3 MySQL 表设计的几个关键字段

从论文的表结构看，chongwujiyang表是核心，字段设计有几个点值得说。jiyangdanhao（寄养单号）用 varchar 存，方便生成带日期前缀的业务单号；kaishishijian用 date，yuyueshijian用 datetime，区分「寄养开始日期」和「预约提交时刻」；zongfeiyong用 float，实际生产建议改 decimal 避免精度问题。ispay默认'未支付'，配合支付回调改状态。

提示：float 做金额运算会出现0.1 + 0.2 = 0.30000000000000004这类问题，毕设演示无妨，真上线务必换 decimal。

3. 从登录到下单：核心链路的代码实现

3.1 小程序登录换 openid 的完整流程

小程序登录不能直接拿用户密码，标准做法是wx.login拿临时 code，传给后端，后端用 code + appid + secret 调微信接口换 openid 和 session_key。这个项目里用户表chongzhu用chongzhuzhanghao做账号，登录时后端校验账号密码，同时把 openid 存下来做后续免密登录。

// LoginController.java 片段 @RequestMapping("/login") @ResponseBody public Map<String, Object> login(@RequestBody Map<String, String> params) { String code = params.get("code"); String account = params.get("account"); String password = params.get("password"); Map<String, Object> result = new HashMap<>(); // 1. 用 code 换 openid（伪代码，实际调微信 jscode2session 接口） String openid = wechatService.getOpenid(code); // 2. 校验账号密码 Chongzhu user = chongzhuService.login(account, password); if (user == null) { result.put("code", 1); result.put("msg", "账号或密码错误"); return result; } // 3. 绑定 openid 并签发 token chongzhuService.bindOpenid(user.getId(), openid); String token = JwtUtil.sign(user.getId(), user.getChongzhuzhanghao()); result.put("code", 0); result.put("token", token); result.put("data", user); return result; }

逻辑分三步：换 openid、验账号、签 token。code只能用一次且五分钟过期，所以必须前端一拿到就传后端。JwtUtil.sign生成带用户 id 的令牌，前端存 storage，后续请求头带上。参数account和password是明文传输，生产环境必须上 HTTPS。

3.2 在线寄养下单接口与费用计算

下单是业务最重的一环，要算总费用、生成单号、写订单表。费用公式是jiyangshizhang * tuoguanfeiyong，寄养时长从开始日期到结束日期算天数差。

// ChongwujiyangServiceImpl.java 片段 public void addOrder(Chongwujiyang order) { // 1. 生成单号：JY + 时间戳 String danhao = "JY" + System.currentTimeMillis(); order.setJiyangdanhao(danhao); // 2. 计算总费用 float total = order.getJiyangshizhang() * order.getTuoguanfeiyong(); order.setZongfeiyong(total); // 3. 校验寄养环境是否还存在 Jiyanghuanjing env = jiyanghuanjingMapper.selectById(order.getHuanjingId()); if (env == null) { throw new RuntimeException("寄养环境不存在"); } // 4. 落库 chongwujiyangMapper.insert(order); }

单号用时间戳保证唯一，简单够用。费用计算放在 Service 层而不是前端，防止用户改价。校验环境存在是必要的，避免用户提交时环境已被管理员删除。throw RuntimeException会被全局异常处理器捕获返回错误信息。

3.3 管理员审核与状态流转

订单状态从「未支付」到「已支付」再到「寄养中」「已完成」，靠ispay字段和额外状态字段控制。管理员在后台看到待审核订单，点通过后改状态。常见做法是加一个status字段，用枚举值 0-4 表示各阶段，比单纯用ispay更清晰。

-- 管理员审核通过，更新订单状态 UPDATE chongwujiyang SET ispay = '已支付', status = 1 WHERE id = #{id} AND ispay = '未支付';

WHERE里带ispay = '未支付'是乐观锁思路，防止重复审核。status = 1表示已确认待寄养。实际项目里还会记录审核人和审核时间，论文表结构没体现，可以自行加shenheren和shenheshijian字段。

4. 数据库表关系与 ER 设计的落地细节

4.1 实体关系怎么映射成外键

论文 ER 图里，管理员管理寄养环境（1 对 M），用户浏览寄养环境（M 对 1），用户管理宠物寄养（1 对 M），用户发布评论（1 对 M）。落到表上，chongwujiyang表通过chongzhuzhanghao关联chongzhu表，discussjiyanghuanjing表通过refid关联jiyanghuanjing、通过userid关联用户。

-- 查询某用户的所有寄养订单及对应环境名称 SELECT j.jiyangdanhao, j.chongwumingcheng, j.zongfeiyong, j.ispay, e.huanjingmingcheng FROM chongwujiyang j LEFT JOIN jiyanghuanjing e ON j.huanjing_id = e.id WHERE j.chongzhuzhanghao = #{account} ORDER BY j.addtime DESC;

LEFT JOIN保证即使环境被删，订单记录还在。ORDER BY addtime DESC让最新订单排前面。注意论文原表里chongwujiyang没有显式huanjing_id，实际开发需要补这个外键字段，否则关联不上环境。

4.2 评论表的多态关联设计

discussjiyanghuanjing表用refid指向被评论的环境 id，userid指向评论人，content存内容，reply存管理员回复。这种设计叫多态关联的简化版，缺点是refid没有外键约束，删环境时评论成孤儿数据。

注意：refid和userid建议加索引，否则评论列表查询会全表扫描。数据量大时longtext也影响性能，可改 varchar(1000)。

4.3 分页查询的 SQL 写法

后台管理列表都要分页，MySQL 用LIMIT offset, size。MyBatis 里配合 PageHelper 插件最省事，不引入插件就手写。

-- 第 2 页，每页 10 条 SELECT * FROM chongwujiyang ORDER BY addtime DESC LIMIT 10, 10;

LIMIT 10, 10表示跳过前 10 条取 10 条。深分页时LIMIT 100000, 10会慢，优化方式是先查主键再回表，或者用WHERE id > 上次最大id的游标分页。

5. 联调排错与毕设答辩的加分技巧

5.1 小程序请求 400/500 的排查顺序

联调时最常见的报错是 400 和 500。排查顺序：先看微信开发者工具 Network 面板的请求 URL 和参数，确认 baseURL 没写错、参数名和后端@RequestParam对得上；再看后端控制台异常栈，500 多半是空指针或 SQL 语法错；最后查数据库连接，Access denied是账号密码错，Unknown database是库名错。跨域问题在小程序里不存在（小程序不走浏览器同源策略），但本地调试要在开发者工具里勾选「不校验合法域名」。

5.2 用 Postman 先测后端再联调小程序

别一上来就小程序调后端，先用 Postman 把每个接口跑通。以登录为例，POSThttp://localhost:8080/jiyang/login，Body 选 raw JSON，传{"account":"test","password":"123456","code":"xxx"}。返回code:0说明后端没问题，再回小程序调。这样能把前后端问题隔离开，省一半调试时间。

5.3 答辩时怎么讲技术亮点

答辩老师最爱问「你的系统有什么难点」。别答「实现了增删改查」，要答具体问题：比如「小程序登录态用 JWT 而非 session，因为小程序没有 cookie，session 跨请求带不上」；「订单费用在后端算而非前端，防止篡改」；「评论表用 refid 做多态关联，一张表支持多种评论对象」。这些点论文里未必写全，但答辩时讲出来就是加分项。

5.4 源码改造的扩展方向

这套代码改造成其他预约类小程序很快。把chongwujiyang换成yuyue，jiyanghuanjing换成changdi，业务逻辑基本不用动。想加支付，接微信支付统一下单接口，回调里改ispay状态。想加消息通知，用微信订阅消息，下单和审核通过时推送给用户。这些扩展不需要重构，在现有 Service 层加方法即可。

# 本地启动后端（IDEA 里跑 Tomcat 或直接用 maven tomcat7 插件） mvn clean package mvn tomcat7:run # 小程序端在微信开发者工具导入项目，修改 utils/request.js 的 BASE_URL 为局域网 IP

启动顺序是先起 MySQL，再起后端，最后开小程序。BASE_URL用localhost在真机上不通，真机调试要换成电脑局域网 IP，且手机和电脑在同一 WiFi 下。

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