企业官网建设流程全解析

1. 选这个题之前，我先想清楚了三件事

每年毕业设计选题季，总有人纠结要不要碰小程序方向。我的看法很直接：如果你想要一个"演示效果直观、技术范围可控、答辩有话讲、工作量看着不小"的项目，基于微信小程序的宠物店在线管理系统是一个性价比非常高的选择。它不像纯商城那样业务线单一，也不像纯管理后台那样缺乏前端展示亮点，而是把"C端小程序购买体验"和"B端店铺经营管理"两条线揉在一起，正好覆盖了微信小程序开发、服务端接口设计、关系型数据库建模、管理端页面开发这些核心能力点。

为什么特别适合毕设？因为宠物店管理天然自带几个场景：卖宠物用品算电商，宠物洗澡美容要按体重计价，寄养服务要按天排期，疫苗提醒涉及时间计算，会员储值和积分又是另一套规则。这些业务交叉在一起，数据库表不会少，接口不会只有增删改查，论文研究现状和个人总结都有真实内容可以写。同类型的校园食堂订餐、二手交易平台也类似，但宠物店在服务预约这一块多了一层排期复杂度，稍微用心做就能和其他人拉开差距。

我这边交付的源码工程结构已经整理成一套完整可运行的项目：微信小程序端负责用户逛店、下单、预约，Spring Boot 后端提供接口和业务逻辑，管理端（Vue 页面）负责商品上架、订单处理和预约审核，MySQL 脚本把建库建表语句也准备好了。接下来我按整个开发流程，把每一步背后的设计逻辑和实操细节都拆开讲。

1.1 为什么是"宠物店管理系统"而不是"宠物商城"

很多人的第一反应是做一个宠物用品商城，觉得商品展示、购物车、下单就够了。但这样做有一个问题：商城类的毕设太常见，评委老师看过太多，论文里也很难写出有区分度的业务逻辑。宠物店在线管理系统和商城的本质区别在于，它多了一条线性服务链：用户在线上挑商品是第一条业务线，预约到店服务（洗澡、美容、寄养）是第二条业务线，两条线共享同一套用户体系和会员积分体系。

举个例子，宠物洗澡美容服务在真实门店里按宠物体重计费，5公斤以下和10公斤以上的犬种洗护价格完全不同。这意味着系统里必须有一张宠物档案表，记录每只宠物的品种、体重和年龄，预约时要携带宠物档案数据，后端再根据体重区间去计算服务价格。这一个点就能让你的数据库设计、接口逻辑和页面展示都比单纯卖货复杂一个档次，而且符合行业实际，答辩时讲"我的系统按宠物体重自动匹配洗护价格"是很有说服力的。

再者，宠物商品和宠物服务的数据模型差异很大。商品有规格、库存、物流属性，服务有时间段、容量上限、服务时长、指定美容师。如果你只做商城，这些差异根本体现不出来。所以我在设计需求时就明确：系统至少包含用户端和管理端两个角色，用户端覆盖首页、商品分类、购物车、订单、服务预约、宠物档案、会员中心；管理端覆盖仪表盘、商品上下架、订单发货、预约审核、宠物档案管理、公告发布。功能闭环，数据有来有回，演示和论文都够用。

1.2 技术选型：原生小程序 + Spring Boot + MySQL

技术栈的选择应该服务于两个目标：第一是让你在有限时间内能把系统完整跑起来，第二是答辩时能扛住追问。微信小程序端我用的是原生开发框架（WXML、WXSS、JavaScript），没有用 uni-app。原因很简单：毕设项目不要求跨端发布到 App，原生小程序在开发者工具里调试更直接，页面结构和组件逻辑也能让老师看得更明白。如果你只会 Vue 的语法，用 uni-app 也行，但要注意编译后部分原生能力的适配问题，比如自定义导航栏的胶囊按钮定位、onReachBottom 分页加载这些，原生里都是现成事件，uni-app 里反而要多包一层。

后端我选了 Spring Boot + MyBatis-Plus + MySQL 8.0。Spring Boot 简化配置，MyBatis-Plus 提供现成的单表 CRUD，代码量能少写一半。为什么不选 Spring Security 做权限？不是不行，而是对毕设来说太重了，配置和概念解释成本高，一旦老师追问过滤器链执行顺序，容易把自己绕进去。我用的是更轻量的 Token 拦截器方案：用户登录成功后拿到一个 token，后端写一个拦截器校验所有 /admin/** 接口的请求头，逻辑简单，代码也容易讲清楚。

管理端用 Vue3 + Element Plus 单独写一套页面，打包后放到 Spring Boot 的静态资源目录里托管，这样前后端部署是一体的，演示时只需要起一个 jar 包，不用再折腾 Nginx。如果时间紧张，管理端也可以直接用 Thymeleaf 模板引擎写，但页面观感会差一些。我在源码里提供的是 Vue 那套，因为大多数毕设老师第一眼看的是界面光不光滑，Element Plus 的表格、表单、弹窗组件能帮你省下大量调样式的时间。

1.3 功能闭环：不是堆页面，而是让数据流动起来

我在规划功能时有一个原则：每个功能点必须能承接上一个功能产生的数据，同时为下一个功能提供输入。具体来说，用户在小程序端浏览商品、加入购物车、提交订单，订单数据进入管理端的待发货列表；用户给宠物创建档案、提交预约，预约单进入管理端的待审核列表。管理端处理完订单和预约后，数据状态回流到用户端的订单列表和预约记录里，同时仪表盘上的销售额、预约量、热门商品排行榜也随之更新。

这样做的好处是演示时有故事线：我一边演示小程序下单，一边切到管理端看到订单出现，完成发货，再切回小程序看到订单状态变化。数据在两端之间同步流动，评委看完对整个系统的完整性会有直观印象。相反，如果前端展示页和后台管理数据是割裂的，只是各做各的 CRUD，演示效果会非常碎。后面第 3 章我会讲到具体接口怎么对接，第 4 章讲管理端怎么联动，先把整体架构立住。

2. 数据库设计：整个项目能不能拿高分，这一关是地基

很多人写毕设拿到源码后第一件事就是跑起来看页面，这是大忌。页面再好看，数据库设计经不起推敲，答辩一样扣分。我在宠物店系统里设计了 11 张核心表，但更重要的是每张表为什么这么建、字段为什么这么设。把设计逻辑讲明白了，老师问数据库相关问题你基本都能打住。

2.1 核心表结构与字段规划

用户体系这块，用户表除了常规的 id、昵称、头像、手机号、注册时间之外，还加了会员等级和积分两个字段。会员等级在用户端会有展示位，积分来自消费和签到，后续可以对接优惠券。但这里有一个细节：会员等级和积分不要只放在用户表里。如果你后续要做"消费满100元升级"之类的规则，等级和积分变动需要留痕，所以单独建一张 member_log 表会更合理。我简化成了用户表直接存字段，但你要清楚这个简化的代价——等级变更历史查不到。答辩时如果老师问，你可以说这是为了控制毕设规模，同时明确给出生产环境的扩展方案。

宠物表是宠物店业务里最有辨识度的部分。字段包括 pet_id、user_id、宠物昵称、品种、生日、体重、绝育状态。其中体重字段非常关键，因为洗护服务要按体重区间计价，宠物档案里存了体重，预约服务时就能自动匹配价格，而不是让用户每次手动填写。绝育状态则关系到部分美容项目能否下单，算一个小的业务规则点。

商品与订单这边，商品表走标准电商结构：分类表、商品表、库存字段。但订单表有一个重要设计：下单时要保存一份商品快照，把下单时的商品名称、单价、图片都以冗余字段存进订单明细表。为什么？因为商品表的价格会改、名称会调、图片会换，如果订单明细只存商品 ID，历史订单展示时可能拿到的是修改后的商品信息，这与用户下单当时看到的不一致，会造成对账困难。这个用"业务数据快照"可以解释得很清楚。

2.2 订单状态机和预约排期逻辑

我处理订单状态时用的是一张状态流转图，虽然不能画流程图，但你可以自己在纸上画出来：待支付 -> 已支付 -> 已发货 -> 已完成，中间允许取消和退款。后端接口设计上，每个状态变更对应一个独立的 action 接口，比如 cancelOrder、payOrder、deliverOrder，而不是写一个通用的 updateState 接口。为什么要这么设计？因为每个 action 背后要做的校验和连带操作完全不同，比如取消订单要回补库存，退款要写退款记录并把积分扣回，如果统一用一个状态更新接口，逻辑会全部挤在一个方法里，非常难维护。这也是一个小型系统里体现代码组织能力的点。

预约逻辑是宠物店项目里的另一个亮点。预约表包含 user_id、pet_id、service_item_id、预约日期、时间段、状态等字段。一天的时间段是提前配置好的，比如 09:00-10:00、10:00-11:00 这样划分。预约冲突检查的做法是：当用户提交一个预约时，后端先查该 day + time_slot 下已审核通过的预约数量，如果大于等于该服务项每天的最大容量，就返回"该时间段已约满"。这里要注意并发问题，如果两个用户同时提交同一个时间段的预约，理论上会超卖。生产环境可以用数据库行锁或 Redis 计数器，但毕设阶段我在代码里做了 synchronized 锁，并加了唯一索引（day、time_slot、service_item_id 组合），实际并发测试问题不大，也够答辩解释。

2.3 预约服务按体重计价的业务亮点

我前面几次提到按体重计价，这里展开说一下具体实现。服务项目表里有一个 price_rule 字段，存的是 JSON 格式的阶梯价格。比如美容服务的规则是 [{maxWeight: 5, price: 40}, {maxWeight: 10, price: 60}, {maxWeight: null, price: 80}]。当用户选择宠物并提交预约时，后端从宠物档案里读取当前体重，匹配对应区间的价格。这个设计比普通的价格字段灵活得多，门店调整价格时不用改表结构，直接改 JSON 规则即可。

同时，每次预约完成之后，把实际成交价记录到预约单里。这样即使体重区间调价了，历史预约单仍然保留当时的价格，逻辑上和订单快照一致。这个点我在论文里单独写了一段"基于规则引擎的宠物服务动态计价设计"，其实不算什么高深东西，但写出来就显得你思考过业务细节。

2.4 数据库设计的三个防坑提醒

第一，金额字段一律用 decimal(10, 2)，不要用 float。float 是浮点数，做加法会出现 0.1 + 0.2 不等于 0.3 这种精度问题，金额算错在答辩现场非常尴尬。第二，所有表统一加 create_time、update_time、is_deleted 三个通用字段。is_deleted 做逻辑删除，配合 MyBatis-Plus 的 @TableLogic 注解，删数据变成改标记，避免误删导致演示数据缺失。第三，不要用物理外键。外键约束在删除或更新时会带来连锁问题，而且 MyBatis-Plus 的批量操作很容易被外键卡住。表之间的关联关系靠查询时 join 字段来维护，这是企业开发的常规做法，你可以直接说"电商系统分库分表后物理外键基本不可用，所以用逻辑关联"。

3. 小程序端实现：从工程目录到页面交互，这些坑我都替你踩过

小程序端是用户直接接触的部分，也是毕设答辩时演示时间最长的界面。我按"工程搭建 -> 网络层封装 -> 登录态 -> 核心页面 -> 适配细节"这条线来讲，每一步都有可以直接照抄的姿势。

3.1 小程序工程结构怎么搭

页面文件放在 pages 目录下，按功能模块拆分子目录：pages/index 首页、pages/category 分类、pages/cart 购物车、pages/order 订单列表、pages/order/detail 订单详情、pages/service 服务项目、pages/appointment 预约、pages/user 个人中心、pages/pet 宠物档案。组件放在 components 目录，比如商品卡片、空状态占位、数量选择器、分页加载组件。utils 目录放三个文件：request.js 统一请求封装、config.js 环境配置、util.js 工具函数（格式化时间、价格展示、防抖）。

这里最容易被忽略的是 config.js 与环境切换。我建议配置一个全局变量，里面包含 baseUrl 和图片前缀，开发时指向你电脑的局域网 IP，上线时改成服务器域名。小程序不支持运行时读取本地环境变量，所以你得记住每次换环境要改这里。我在源码里把它单拎出来，就是为了让你切换演示环境时不用到处找。

3.2 网络请求封装和登录态处理

request.js 里我做了几件事：统一拼接 baseUrl，读取 storage 里的 token 放到请求头，响应非 200 时统一 toast 错误信息，401 时清理登录态并跳转登录页。这个封装看起来基础，但能避免你在每个页面重复写 wx.request，而且统一报错样式。有一点要注意：小程序里 wx.request 的 success 回调只是网络层成功，不代表业务成功，所以后端返回的数据要约定一个通用结构，比如 { code: 0, data: ... }，只有 code 为 0 才说明业务成功。不做这一层约定，你会发现调试时错误信息全靠猜。

登录流程是毕设必考点，流程本身不复杂：小程序端 wx.login 拿到临时 code，传给后端 /api/login 接口，后端拿这个 code 去微信服务器换 openid，然后生成一个自己定义的 token 返回给小程序。这里有两个容易踩坑的地方：第一，wx.login 的 code 是一次性的，5 分钟有效，后端不要缓存；第二，新版本小程序不能再像以前那样直接 getUserInfo 弹窗获取用户头像和昵称，现在更稳妥的做法是在个人中心页面放一个"编辑资料"功能，让用户手动填写昵称、上传头像。微信官方对头像昵称填写能力做了调整，你顺带在论文里写一句"遵循微信平台最新的用户信息保护规范"是比较加分的。

3.3 首页、商品列表与分页加载

首页做的内容比较标准：顶部搜索框、轮播图（用 swiper 组件）、金刚区快捷入口、推荐商品流。轮播图的数据从管理端的公告管理接口读取，图片上传后返回 URL。这里有一个性能小技巧：首页的图片比较多时，建议用小图压缩版，不要直接加载原图。管理端上传图片后可以同时保存一个缩略图路径，首页展示缩略图，详情页展示原图，减少小程序加载时间。

商品分类页和搜索结果页共用一个商品列表组件，这个组件里实现了分页加载：小程序有 onReachBottom 页面生命周期，当页面滚动到底部时触发加载下一页。我习惯用 page（页码）和 pageSize（每页数量）两个参数，后端返回数据时同时返回 total，前端根据 total 和已加载条数判断 hasMore 是否还有更多。这里的防坑点是：onReachBottom 触发频率很高，如果上一页请求还没返回就触发下一页，会出现列表重复或错乱。解决办法是在组件里加一个 loading 标志位，请求未完成时直接 return。下拉刷新用 enablePullDownRefresh 开启配置，然后在 onPullDownRefresh 里重置页码并重新加载第一页数据。

3.4 购物车、下单与预约流程的细节

购物车数据建议存服务端而不是只存本地缓存。如果只存 localstorage，用户换了手机登录购物车就丢了，而且下单时校验库存还是得请求后端，数据不同步会造成实际库存超卖。我的做法是购物车表关联用户 ID，增删改都调用接口。购物车页面支持选中商品、修改数量、计算总价，提交订单时只把选中的购物车 ID 列表传给后端，后端在 service 层校验商品是否上下架、库存是否充足，然后生成订单。这里下单接口里有一个关键动作：先扣库存再写订单，用事务包住，任何一个步骤失败就整体回滚。实现时不要忘了在 service 方法上标注 @Transactional。

预约流程稍微不同，因为它还要携带宠物 ID。用户从服务项目列表页进入详情页，选择宠物（从我的宠物档案里选），选择日期和时间段，提交后后端做容量校验，然后创建一条"待审核"的预约单。管理端审核通过后，用户端能通过订阅消息收到通知。小程序订阅消息（wx.requestSubscribeMessage）是毕设里容易被忽略的功能，我建议你加上。它不需要额外的服务器资源，前端拉起订阅授权，后端调用 subscribeMessage.send 推送，成本低但演示时很提气。

3.5 自定义导航栏和相关适配问题

把导航栏从默认样式改成自定义样式后，页面上移会导致内容被状态栏和胶囊按钮遮挡。这个问题的关键在于动态获取胶囊按钮的位置和小程序右上角的胶囊布局信息。页面 json 里设置 "navigationStyle": "custom" 后，用 wx.getMenuButtonBoundingClientRect 获取胶囊按钮的坐标，再从 wx.getSystemInfoSync 拿到状态栏高度，计算出一个导航栏占位组件的高度，并应用到每个页面的顶部。我在源码里写了一个 nav-bar 组件，统一处理了标题显示和返回事件，避免每个页面重复写。

真机适配还有一个问题：iPhone 底部横条（home indicator）会遮挡底部 tab 栏或底部操作按钮。解决方式是给底部区域加 padding-bottom: constant(safe-area-inset-bottom) 和 padding-bottom: env(safe-area-inset-bottom)。这两个 CSS 安全区属性虽然加了很久了，但在小程序里仍然很常踩坑，因为开发者工具的模拟器不一定能完全模拟真机的安全区表现，演示时尽量用真机预览确认样式没问题。

4. 管理端与接口开发：内部人看的逻辑，要配得上外部人看到的效果

管理端是员工视角，它不追求花哨，但必须让每一项操作都有反馈。我在源码里提供了 Vue3 + Element Plus 的管理端，功能覆盖商品、订单、预约、会员、宠物档案、公告和统计数据。下面讲几个实现过程中花费时间最多、也最值得分享的模块。

4.1 权限控制的轻量方案

管理端登录走的是账号密码体系，用户表和管理员表是分开的。管理员登录成功后，后端生成一个包含 managerId 和 role 的 token 返回，前端存到 localStorage，并在每次请求时通过请求拦截器加入 Authorization 头。后端用一个拦截器拦截所有 /admin/** 接口，从请求头里解析出 token，如果无效或过期就返回 401。角色字段只区分超级管理员和普通员工，超级管理员能访问商品删除、会员管理等高权限接口，普通员工只能处理订单和预约。毕设这个权限粒度够了，但你要讲清楚：如果业务再复杂一点，可以引入 RBAC 权限模型，给每个管理员分配角色，角色关联菜单和操作权限，这样回答"权限怎么扩展"就有了现成答案。

4.2 图片上传与静态资源映射

管理端上传商品图片，我用的是 el-upload 组件，请求后端 /admin/file/upload 接口，后端接收 MultipartFile，保存到本地目录，返回图片访问路径。这里有一个很常见的坑：如果你将图片保存到项目的本地磁盘路径，部署到服务器后路径会变，或者你从开发电脑换到演示电脑后会发现所有历史图片全部裂图。我建议在 Spring Boot 配置文件里单独配置一个 upload.dir 属性，同时自定义一个资源映射，将 /upload/** 的 URL 映射到配置目录。也就是说，代码里不要写死绝对路径，全部读配置。另外，小程序端和 web 管理端用的图片前缀可能不同，前端展示时不要直接在代码里拼死前缀，而是用接口返回的 URL 或统一前缀做拼接。我在 config.js 里单独留了 imgBaseUrl，演示时改一处即可。

图片上传大小也要限制。小程序端 wx.chooseMedia 可以选择压缩图片，管理端上传时建议在后端设置单张不超过 2MB。如果你上传原图不压缩，商品列表页加载大量高分辨率图，用户体验会非常差，小程序端流量消耗也大。我管理端里做了前端压缩，并在后端做了大小校验，双保险。

4.3 订单处理与仪表盘统计

订单管理页的核心操作是发货。点击发货后调用后端接口，后端把订单状态改为"已发货"，同时写入发货时间和物流单号。这里要处理一个关联逻辑：用户端订单列表展示的是每个订单的最新状态，订单状态一变，小程序端要多拉一次接口才能看到最新状态。如果你想让演示更流畅，可以在小程序端的订单列表页做一个下拉刷新，并提醒用户刷新查看。很多毕设卡在这一步——发货了，但小程序端看不到变化，其实是前端没刷新数据，不是后端 bug。

仪表盘统计：

• 今日订单数、今日销售额、待发货订单数、待审核预约数，这四个是顶部指标卡，后端分别写 count / sum 查询。
• 近 7 天销售趋势，SQL 用 GROUP BY DATE(create_time) 统计每天的订单总额。
• 热销商品 Top5，按 order_item 里的商品 ID 分组，count 数量降序。
• 预约按服务项目分布，查 appointment 表按 service_item_id 分组。

这些统计接口看起来简单，但实际会遇到一个问题：本地订单数据量太少，图表显示出来很稀疏，演示效果不好。解决办法是在演示前准备一批有日期的模拟数据，或者按日期范围筛选而不是只查最近 7 天。我在源码里写了一个数据导出的 SQL 脚本，可以快速生成 20 条分布在不同日期的模拟订单，方便演示时统计图有正常的曲线形状。

5. 联调部署与常见问题排查实录

5.1 域名与 HTTPS 配置

小程序 wx.request 有个硬性要求：正式环境请求的域名必须是 HTTPS，并且在小程序管理后台配置 request 合法域名。毕设阶段如果你没有备案域名，最简单的方案是：使用开发者工具时，在"详情 -> 本地设置"里勾选"不校验合法域名"。但是要注意，这个设置只对开发者工具生效，真机预览时必须使用有效域名或者把后端地址配成局域网 IP 才能跑通。真机预览时你的手机和电脑必须在同一个局域网内，后端运行在电脑上，小程序请求地址填 http://你的电脑IP:8080。如果手机和电脑不在同一网络，请求就会直接失败。我建议演示时把后端、小程序模拟器、管理端都集中在同一台电脑上，避免网络问题影响发挥；如果非要用真机演示，请提前连好同一 Wi-Fi 并测试网络互通。

5.2 真机预览与开发者工具的细节差异

真机预览时有两个非常影响体验的问题。第一，开发者工具模拟器里样式正常，但真机上部分样式偏移，常见的原因是字体渲染差异和 rpx 换算在不同屏幕宽度下的表现不同。第二，真机上的 vConsole 工具可以看到 console.log 和网络请求，但小程序开发工具里打开的调试面板和真机不完全一致。如果你遇到真机上有请求失败但模拟器正常，优先检查网络环境、域名白名单、证书，而不是怀疑后端代码。还有一个常见的缓存问题：微信真机预览会缓存小程序代码包，你改了代码后重新预览可能还是旧版本。解决方案是在预览二维码后，在真机上杀掉小程序进程重新进入，或者用体验版并清除缓存。

5.3 常见问题速查表

6. 毕业设计答辩的演示策略，这一块没人写但我建议你看完

技术做完了，论文写好了，答辩现场如果翻车，前面的努力全部白费。我根据自己的经验列几个演示时必须注意的点，照着准备能少踩很多坑。

6.1 演示前的准备工作，提前半小时检查

第一，预置演示数据。数据库里至少要准备 15 个以上商品、5 只宠物档案、覆盖不同状态的订单（待支付、已支付、已发货、已完成、已取消各来几条）、未来几天的可预约时间段。很多项目在演示时用空数据库跑，场景全凭现场新建，一旦现场紧张操作缓慢，整体效果就很拉胯。预置数据还有一个隐藏好处：仪表盘的统计图表有真实数据曲线，评委一看就觉得系统是"被用过"的。

第二，环境切换和网络检查。如果你之前一直用模拟器调试，演示前最好先确定后端是否在当前电脑上运行，数据库服务是否已启动。如果后端地址写的是 localhost，切换到局域网 IP 后要记得同步更新 config.js 并重新编译。实操时我习惯准备一份启动文档，把启动 MySQL、导入 SQL、启动 Spring Boot、启动管理端、打开微信开发者工具导入小程序这几步写清楚，演示当天照着执行，避免临时慌乱。

第三，准备一页"演示脚本"：先展示小程序首页和商品分类，再走一遍下单流程，切到管理端处理订单，再回到小程序看订单状态变化，然后展示服务预约流程，最后切到仪表盘看统计变化。脚本不用很详细，但顺序要定好，确保每一个功能点都有从前端到后端的闭环展示。答辩时时间有限，演示流畅比功能齐全更重要。

6.2 老师最爱问的几个问题，提前背答案

我把答辩现场被问到概率最高的问题整理成速答口径，供你参考。

"你项目的登录流程是怎么实现的？"答：小程序端 wx.login 获取临时 code，后端用 code 换取 openid，用 openid 作为用户唯一标识，并签发自己的 token 管理登录态。要补充当前微信平台不再直接开放用户授权头像昵称的接口，通过手动填写资料页解决。

"订单状态是怎么流转的？"画状态图，说明待支付、已支付、已发货、已完成、已取消、已退款六种状态，每种状态对应独立接口，并解释取消订单回补库存、支付后扣减库存、退款扣回积分的联动逻辑。

"预约冲突怎么处理？"答：提交预约时查询同一日期同一时间段已通过的预约数，达到容量上限则拒绝；数据库层用联合唯一索引兜底；生产场景下可以用 Redis 计数器或数据库行锁，但毕设项目用的是代码层面的校验加索引约束。

"你这个项目最大的难点是什么？"这个问题的标准答案不是"学会了微信小程序语法"，而是挑一个业务复杂度高点讲清楚设计思路。我推荐答预约服务的动态计价：服务项目价格规则用 JSON 配置，宠物体重变化后重新匹配区间，历史预约单保存成交价避免价格追溯困难。如果能把这个点讲明白，老师会认可你是真的理解业务而不是只抄了一遍代码。

7. 一些真实的心得，留给准备动手的你

文章写到最后一站，分享几条我在开发和交付这个项目的过程中总结出来的真实经验。

进度管理上，我给自己的分期比是：数据库设计和接口文档占四分之一，小程序端实现占四分之二，管理端和联调占四分之一。不要急着先写页面，没有接口数据，小程序页面写出来也只能用 mock 数据，联调时还要返工。先把数据库的表建好、后端接口跑通，让管理端能够维护数据，再开始小程序端，进度反而更快。

协作习惯上，建议全程用 Git 管理代码，哪怕你是一个人写。每次完成一个模块就提交一次 commit，理由有两个：一是中途改坏了某项功能可以快速回退；二是答辩老师的系统里会查代码提交记录，有规律提交的 Git 历史会给"独立完成、过程规范"加分。提交信息开头用"feat:"、"fix:"这些前缀更显专业，别一条消息写"更新"到底。

源码交付的 Readme 一定要写清楚三块内容：环境要求（JDK 版本、Maven 版本、MySQL 版本、Node 版本）、启动步骤（建库、导入数据、修改配置、启动后端、导入小程序项目）、测试账号信息（管理端登录账号和密码）。不要低估这一步，很多同学在交付源码后被问的第一个问题就是"怎么跑起来"。把这块写明白，对你负责，对拿到你源码的人更负责。

我做这个项目时最深的体会是：毕业设计的评分标准本质上是"你用工程方法解决一个具体问题的能力"。宠物店管理系统这个题目并不新奇，但只要你把完整链路走通，把数据关系理清楚，把演示故事讲流畅，它就是一份扎实的、能拿得出手的成品。希望对正在选做这个方向的你有点实际帮助，祝你答辩顺利。