企业官网建设流程全解析

简介：这份资源是面向计算机专业毕业生与微信小程序开发学习者的毕业设计论文文档，围绕基于微信小程序的宠物寄养平台展开，解决宠物临时寄养中信息不对称、服务不规范的问题。论文约一万字，涵盖摘要、选题背景与意义、论文结构安排、开发技术介绍、需求分析与可行性分析、功能分析、业务流程分析、数据库设计、ER图、数据字典、数据流图、详细设计、系统截图、测试、总结、致谢与参考文献，技术栈为微信小程序前端搭配SSM框架与MySQL数据库，功能涉及宠主管理、宠物种类管理、寄养环境管理、宠物寄养管理及管理员审核等模块。压缩包共1个doc文件，大小约1.18MB，便于直接查阅与修改。已有529人学习下载，适合作为同类选题的写作模板与功能设计参考，帮助读者快速理清论文框架、数据库设计思路与系统实现脉络。

1. 从一张手写寄养登记表说起：这套方案要解决什么

宠物寄养这件事，真正麻烦的从来不是“有没有地方放”，而是信息对不上。宠主打电话问环境、问价格、问有没有笼位，店家翻本子、翻聊天记录、翻记忆，最后靠一句“应该还有位置”把单子接下来。等到接宠物那天才发现，笼位被重复预订、宠物种类和寄养区不匹配、费用算错。这类场景在中小寄养机构里非常普遍，也是我做这套基于微信小程序的宠物寄养平台时最想解决的核心问题。

这套方案面向两类人：一类是要交毕业设计或课程设计的学生，需要一份结构完整、能跑通、能答辩的成品；另一类是从业者，想用一套轻量系统把寄养预约、环境展示、费用结算串起来。技术栈是微信小程序前端加 SSM 后端，MySQL 存数据，整体不重，但该有的模块一个不少。下面按需求、设计、实现、避坑、验收的顺序展开，能抄的部分直接给结构和代码。

2. 需求与角色拆解：两个端、五类数据、三条主流程

2.1 角色边界：管理员管数据，宠主管自己的单

系统里只有两个角色，但这两个角色的权限边界必须在需求阶段就划清楚，否则后面写接口会反复返工。管理员负责宠主信息、宠物种类、寄养环境、宠物寄养记录、公告和评论的管理，本质是“数据维护者”；宠主负责注册登录、浏览寄养环境、在线提交寄养申请、查看自己的寄养状态和个人资料，本质是“数据生产者”。

这里有个容易被忽略的点：原方案里把“寄养机构注册”也写进了功能，但在小程序端让机构自己注册会带来审核和权限的复杂度。我一般会把它收敛成“管理员在后台录入寄养环境”，小程序端只做展示和选择。这样角色只有两个，权限模型简单，答辩时也讲得清楚。

2.2 数据实体：五张核心表撑起整个业务

从需求直接能推出来的实体有五类：宠主、宠物种类、寄养环境、宠物寄养记录、评论。它们之间的关系是：一个宠主可以有多条寄养记录，一条寄养记录关联一个寄养环境和一个宠物种类，一条寄养环境可以有多条评论。这个关系在数据库设计阶段会落成外键和索引，但在需求阶段先画清楚，后面建表就不会漏字段。

2.3 三条主流程：注册登录、在线寄养、后台审核

第一条是注册登录。宠主在小程序端用账号密码注册，密码入库前做一次摘要处理，登录成功后后端返回一个 token，小程序把 token 存到本地缓存，后续请求带上。第二条是在线寄养：宠主浏览寄养环境列表，点进详情看图片和费用，填宠物信息、选开始时间和时长，系统按“托管费用 × 时长”算出总费用，提交后生成寄养单，支付状态默认“未支付”。第三条是后台审核与状态流转：管理员在后台看到新提交的寄养单，核对信息后确认，宠主端的状态随之变化。

提示：支付状态字段不要做成布尔值，用字符串存“未支付/已支付/已取消”，后面加退款或线下支付时不用改表结构。

3. 总体架构设计：小程序端、SSM 后端与 MySQL 的职责划分

3.1 三层结构：展示层、业务层、数据层

整体是典型的三层结构。展示层是微信小程序，负责页面渲染、表单收集、本地缓存 token；业务层是 SSM 后端，Spring 管 bean 和事务，SpringMVC 做请求路由，MyBatis 做 SQL 映射；数据层是 MySQL，存所有业务数据。三层之间只通过 HTTP 接口通信，小程序不直连数据库，这一点在答辩时经常被问到，要能说清楚为什么。

后端按模块分包：controller 层只做参数校验和响应封装，service 层写业务逻辑和事务边界，mapper 层对应 MyBatis 的 XML 或注解 SQL，entity 层放实体类。这个分法不新鲜，但好处是每个模块的改动范围可控，测试时也能按层定位问题。

3.2 接口约定：统一响应体与分页参数

小程序和后端之间要有统一的响应格式，否则前端每个页面都要写一套判断逻辑。我一般用下面这个结构，code 为 0 表示成功，非 0 表示业务错误，data 放具体数据，msg 放提示语。

{ "code": 0, "msg": "success", "data": { "total": 12, "list": [] } }

分页参数统一用 page 和 limit，后端在 service 层做偏移量计算，SQL 里用 limit 拼接。这样列表页、评论页、寄养记录页可以复用同一套分页逻辑，前端也不用为每个接口单独适配。

3.3 小程序端页面结构：四个 tab 加若干详情页

小程序端底部四个 tab：首页、寄养环境、在线寄养、我的。首页放公告和推荐环境，寄养环境页做列表和筛选，在线寄养页是表单入口，我的页面放个人资料和寄养记录。详情页、评论页、登录注册页作为非 tab 页面按需跳转。这个结构的好处是主流程路径短，宠主从首页到提交寄养单不超过三次点击。

4. 数据库与核心模块实现：从建表到寄养单落库

4.1 寄养主表设计：字段命名与状态字段

寄养主表是整个系统的核心，字段多但每一个都有用。下面这张表按原方案的字段整理，补上了主键、创建时间和支付状态的默认值。字段名用拼音是原方案的风格，实际开发中如果团队允许，建议改成英文，可读性更好；这里保留拼音是为了和原方案对齐，方便对照论文。

CREATE TABLE chongwujiyang ( id BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '主键', addtime TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', jiyangdanhao VARCHAR(200) DEFAULT NULL COMMENT '寄养单号', chongwumingcheng VARCHAR(200) DEFAULT NULL COMMENT '宠物名称', chongwuzhonglei VARCHAR(200) DEFAULT NULL COMMENT '宠物种类', chongwuxingbie VARCHAR(200) DEFAULT NULL COMMENT '宠物性别', shifoujueyu VARCHAR(200) DEFAULT NULL COMMENT '是否绝育', chongwunianling VARCHAR(200) DEFAULT NULL COMMENT '宠物年龄', kaishishijian DATE DEFAULT NULL COMMENT '开始时间', jiyangshizhang INT(11) DEFAULT NULL COMMENT '寄养时长', tuoguanfeiyong FLOAT DEFAULT NULL COMMENT '托管费用', zongfeiyong FLOAT DEFAULT NULL COMMENT '总费用', chongzhuxingming VARCHAR(200) DEFAULT NULL COMMENT '宠主姓名', chongzhuzhanghao VARCHAR(200) DEFAULT NULL COMMENT '宠主账号', yuyueshijian DATETIME DEFAULT NULL COMMENT '预约时间', jiyangyuanyin LONGTEXT COMMENT '寄养原因', beizhu LONGTEXT COMMENT '备注', ispay VARCHAR(200) DEFAULT '未支付' COMMENT '支付状态', PRIMARY KEY (id), KEY idx_chongzhuzhanghao (chongzhuzhanghao), KEY idx_ispay (ispay) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='宠物寄养表';

建表时有三个细节值得说。第一，宠主账号加了普通索引，因为“我的寄养记录”页面会按账号查，数据量上来后没有索引会明显变慢。第二，支付状态加了索引，后台按状态筛选待处理单子时会用到。第三，总费用用 FLOAT 存，金额计算在 service 层用 BigDecimal 做，避免浮点误差累积；如果对金额精度要求高，直接改成 DECIMAL(10,2) 更稳妥。

4.2 在线寄养接口：参数校验与费用计算

在线寄养是业务主流程，接口要做三件事：校验必填参数、按规则算总费用、落库并返回单号。下面是一段 service 层的核心逻辑，省略了日志和异常包装，重点看校验和计算。

public Map<String, Object> submitFoster(FosterForm form) { // 必填校验：宠物名、种类、开始时间、时长、宠主账号 if (StringUtils.isBlank(form.getChongwumingcheng()) || StringUtils.isBlank(form.getChongwuzhonglei()) || form.getKaishishijian() == null || form.getJiyangshizhang() == null || form.getJiyangshizhang() <= 0 || StringUtils.isBlank(form.getChongzhuzhanghao())) { throw new BizException("寄养信息不完整"); } // 查寄养环境的托管费用标准 Jiyanghuanjing env = jiyanghuanjingMapper.selectById(form.getHuanjingId()); if (env == null) { throw new BizException("寄养环境不存在"); } // 总费用 = 托管费用 * 时长，用 BigDecimal 避免浮点误差 BigDecimal unit = BigDecimal.valueOf(env.getTuoguanfeiyong()); BigDecimal total = unit.multiply(BigDecimal.valueOf(form.getJiyangshizhang())); form.setTuoguanfeiyong(env.getTuoguanfeiyong()); form.setZongfeiyong(total.floatValue()); // 生成寄养单号：时间戳 + 宠主账号后四位 form.setJiyangdanhao("JY" + System.currentTimeMillis() + form.getChongzhuzhanghao().substring(Math.max(0, form.getChongzhuzhanghao().length() - 4))); form.setIspay("未支付"); chongwujiyangMapper.insert(form); Map<String, Object> result = new HashMap<>(); result.put("jiyangdanhao", form.getJiyangdanhao()); result.put("zongfeiyong", form.getZongfeiyong()); return result; }

这段代码的关键点在于费用标准从环境表里取，而不是前端传过来。前端传费用是最常见的翻车点，用户改一下请求参数就能把总费用改成 1 块。单号生成用时间戳加账号后四位，能保证同一毫秒内不同用户不冲突，同一用户连续提交也有时间戳兜底。参数校验放在 service 层而不是 controller 层，是为了让小程序端和后台管理端复用同一套校验逻辑。

4.3 寄养环境列表与评论：查询与关联

寄养环境列表页需要展示环境名称、图片、费用标准，点进详情后还要带出评论。查询用 MyBatis 的 XML 写，列表只查主表字段，详情再按环境 id 查评论，避免一次 join 出大量重复数据。

<select id="selectEnvPage" resultType="com.demo.entity.Jiyanghuanjing"> SELECT id, huanjingmingcheng, tupian, tuoguanfeiyong, miaoshu FROM jiyanghuanjing <where> <if test="keyword != null and keyword != ''"> AND huanjingmingcheng LIKE CONCAT('%', #{keyword}, '%') </if> </where> ORDER BY id DESC LIMIT #{offset}, #{limit} </select>

评论表通过 refid 关联环境 id，查询时按 refid 过滤并按时间倒序。回复字段留给管理员在后台回复，小程序端只展示。这里要注意评论内容要做长度限制和转义，前端展示时不要直接渲染 HTML，避免脚本注入。

5. 避坑与排查：五个最容易翻车的地方

5.1 小程序请求带不上 token

现象是登录成功后跳转页面，接口返回未登录。原因通常是小程序端把 token 存在了页面 data 里，切换页面后丢失。解决方式是把 token 写进 wx.setStorageSync，封装一个统一的 request 方法，在 header 里读缓存拼 Authorization，所有页面调同一个方法。

5.2 寄养单重复提交

现象是用户快速点两次提交，生成两条一样的单子。原因是按钮没有防抖，接口也没有幂等控制。解决方式有两个层面：前端提交后立即禁用按钮并显示 loading；后端在落库前按“宠主账号 + 宠物名 + 开始时间”查一次近一分钟内的记录，存在则直接返回已有单号。

5.3 日期字段前后端格式不一致

现象是开始时间存进去变成前一天，或者详情页显示 Invalid Date。原因是小程序端日期选择器返回的是字符串，后端 DATE 字段接收时有时区偏移。解决方式是前后端统一用 yyyy-MM-dd 格式传输，后端在实体类上加 @JsonFormat(pattern = "yyyy-MM-dd", timezone = "GMT+8")，入库前不做二次转换。

5.4 后台删除环境导致寄养单查不到环境名

现象是管理员删了一个寄养环境，历史寄养单详情页环境名变成空。原因是寄养单只存了环境 id，没有冗余环境名。解决方式是在寄养单落库时把环境名称冗余存一份，或者删除环境改成逻辑删除，用状态字段标记，历史数据仍可关联查询。我一般选后者，逻辑删除对历史数据更友好。

5.5 测试环境能跑、换台机器连不上数据库

现象是本地开发正常，换一台电脑或部署到服务器后启动报连接失败。原因通常是数据库连接串写死了 localhost，或者 MySQL 版本和驱动版本不匹配。解决方式是把连接配置抽到 properties 文件，按环境区分；驱动版本和 MySQL 大版本对齐，连接串加上 useUnicode 和 characterEncoding 参数。

6. 验收与答辩：怎么证明这套系统真的能用

验收这件事，我一般分三步走，每一步都有可检查的产出，答辩时直接拿这三步的结果说话。

第一步是功能清单逐项过。把需求阶段列的模块做成一张表，每项写清楚操作路径和预期结果，比如“在线寄养：小程序首页 → 在线寄养 → 填写宠物信息 → 提交 → 我的页面出现新单，状态未支付”。验收时按表操作，截图留档。这张表同时也是论文里功能测试章节的素材，比空写“测试通过”有说服力。

第二步是异常路径抽查。正常流程谁都能跑通，答辩老师更爱问异常情况。准备三个问题：必填项不填提交会怎样、重复提交会不会出两条单、删除环境后历史单还能不能看。这三个问题对应上面避坑章节的三条，提前跑一遍，答的时候直接说现象和解决方式，比背概念强。

第三步是数据一致性核对。挑一条寄养单，从数据库里查它的宠主账号、环境 id、总费用，和小程序端展示的逐项对一遍。总费用要手算验证：托管费用乘以时长是否等于库里的值。这一步能证明费用计算逻辑没有写死在前端，也是很多同类系统容易露馅的地方。

答辩陈述我建议按“问题—方案—验证”三段讲，时间控制在八分钟以内。先讲传统寄养管理的信息不对称问题，再讲这套系统用两个角色和五张表怎么解决，最后用验收表里的两三条结果收尾。不要从头到尾念技术栈，老师更关心你为什么这么设计。

注意：答辩前把数据库里造几条真实感的数据，空表演示列表页会很尴尬；但数据里的姓名、电话一律用虚构值，不要用真实信息。

这套方案我从建表到接口到验收走了一遍，最大的教训是需求阶段偷懒，后面一定要还。最早我把“寄养环境”和“寄养机构”当成两个东西设计，写到一半发现权限和表关系全乱了，返工了两天才收敛成现在这个结构。从那以后我每次做类似系统，都强制先把角色和实体关系画在一张纸上，确认没有多余角色再动手建表。希望帮到你。

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