企业官网建设流程全解析

前阵子帮一个开宠物店的朋友规划“云宠之家管理系统”，他翻着厚厚的纸质登记本跟我抱怨：客户带宠物来洗澡，店员要翻半天档案，疫苗日期经常记错，预约时间全靠口头确认，月底对账更是对到怀疑人生。当时我就意识到，这不是一家店的问题，而是中小宠物门店普遍缺一套把人、宠物、预约、订单真正串起来的管理工具。这篇文章会把整个基于SpringBoot的云宠之家管理系统的设计与实现过程复盘一遍，从业务需求分析、数据库建模，到核心功能代码、部署踩坑，都按实际操作顺序写出来。适合正在做类似后台管理系统的开发者参考，也方便宠物店主理解一个合格管理系统应该覆盖哪些功能。

1. 业务场景与整体设计思路

1.1 先别急着写代码，把门店里的“乱账”理清楚

动工之前，我在朋友店里蹲了半天，发现最核心的痛点其实只有三个。

第一个是“找档案难”。顾客带宠物到店，店员要先确认这是哪只宠物、上次疫苗什么时候打的、有没有过敏史、上次洗澡用的是什么浴液。这些信息如果只靠记忆和手写本子，换一个店员就断档。

第二个是“预约撞车”。店里的美容师、寄养位、疫苗医生都有各自的时间安排。几个员工共用一张Excel排班表，经常出现同一个美容师同一时间段被约了两只狗，到店之后只能现场扯皮。

第三个是“账单对不上”。洗澡、寄养、驱虫、疫苗、宠物用品销售，不同服务项目价格不同，优惠和会员折扣又不一样。等月底想统计营收，靠翻聊天记录和收款码明细，工作量非常大。

所以我在设计云宠之家的时候，目标不是做一个大而全的ERP，而是先聚焦一条主链路：把客户、宠物、预约、订单这四个核心对象管顺。系统需要做到：店员输入客户手机号能立刻看到名下所有宠物和健康记录；顾客预约时能实时看到可用时间段；每一笔服务或商品订单都能追溯到具体宠物和经手员工。其他像会员积分、数据看板，都是在这条主链路上自然延伸出来的。

1.2 为什么选SpringBoot而不是其他方案

有朋友问我，这种规模的管理系统用Excel甚至钉钉表单不就行了？对于只有几十个客户的店，确实可以。但一旦客户超过两三百，宠物档案、预约冲突、订单统计这些问题就会指数级放大，电子表格完全扛不住。

技术选型上，我最终定了SpringBoot，理由很实在。

一是生态成熟，Java做管理系统有太多现成方案。SpringBoot自带自动配置，内嵌Tomcat，打包成一个jar就能跑，不用像传统SSM那样写一堆XML。MyBatis-Plus提供通用Mapper和分页插件，单表CRUD基本不用手写SQL。Spring Security、JWT、Redis这些组件都能无缝集成。

二是单体架构在这个场景下足够。云宠之家大概就是十几个接口、二三十张表，用微服务纯属给自己找麻烦。SpringBoot单体应用部署简单，后续如果要做小程序端，直接把接口复用出去就行。真到了性能瓶颈，再按模块拆分也不迟。

三是团队接手成本低。现在愿意学Java的开发者很多，SpringBoot已经成为Java后端事实上的主流框架。找一个能维护这个系统的人，比找一个只会小众框架的人容易得多。我选技术栈向来有个原则：能用主流方案解决问题，就不要为了炫技引入冷门框架。

1.3 功能模块划分：先把边界画清楚

功能模块不是拍脑袋想出来的，而是从前面三个痛点倒推出来的。第一个版本我规划了七个核心模块，见下表。

权限方面，我做了最简单的角色区分：店主角色和管理员角色可以看到全部数据，美容师角色只能看到预约和宠物档案，不能看营收统计。前后端分离，后端只提供Restful接口，前端用Vue搭建管理界面。

这个划分看起来简单，但让我少走了很多弯路。因为模块边界清楚了，建表的时候才能知道哪些字段该放哪张表，写接口的时候才能控制好职责范围。很多项目做到一半开始改表结构，基本都是因为最开始没把业务梳理清楚。

2. 数据库设计：先把人和宠物的关系理明白

2.1 “人-宠-预约-订单”的模型关系

数据库是整个云宠之家的地基，我花在建模上的时间比写代码还多。

核心模型是这样串起来的：用户表存顾客，宠物表存顾客名下的宠物，预约表存一次具体服务预约，订单表存一笔实际账单。一个人可以养多只宠物，一只宠物可以产生多次预约，一次预约对应一个服务项目。订单不一定都来自预约，也可能是在店里直接买宠物用品，所以订单表单独保留，并用业务单号关联预约。

我一开始差点把宠物信息直接塞进用户表里，想想不对。一只宠物会有疫苗记录、体重变化、绝育状态、过敏史这些信息，如果全放用户表，字段会越来越多，查一次用户就要带出一堆无关注释。正确的做法是拆表，让宠物表自己逐渐长大。

积分和会员等级我也独立成表。积分流水记录每次变动的来源和去向，比如消费+100、退款-50，这样顾客如果质疑积分不对，可以直接查流水。会员等级通过累计消费金额自动升级，不需要人工干预。

建议准备做类似系统的人在写第一行代码之前，先把自己业务里的实体和关系画出来。不一定画得多规范，哪怕写在白板上都行。实体关系没理清，后面所有SQL都会别扭。

2.2 宠物表和预约表字段设计细节

宠物表的核心字段我设计成这样：

CREATE TABLE `pet` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL COMMENT '所属用户', `name` varchar(50) NOT NULL COMMENT '宠物昵称', `breed` varchar(50) DEFAULT NULL COMMENT '品种', `birthday` date DEFAULT NULL COMMENT '生日', `gender` tinyint DEFAULT NULL COMMENT '性别 0-妹妹 1-弟弟', `neutered` tinyint DEFAULT 0 COMMENT '是否绝育 0-否 1-是', `vaccine_expire_date` date DEFAULT NULL COMMENT '疫苗到期日', `allergy_info` varchar(255) DEFAULT NULL COMMENT '过敏信息', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, `deleted` tinyint DEFAULT 0, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`) );

有几个设计细节值得展开。

gender不要用字符串存“公”“母”，检索和传输都不方便，用tinyint存数字，前端再转成文案。birthday用date类型而不是varchar，因为后面要按年龄做统计，比如“一岁以下的幼宠有多少只”，日期类型可以直接计算。

疫苗到期日这个字段我当初差点漏掉。宠物店最值钱的增值服务就是疫苗提醒，如果只存最近接种日期，店员还要自己算什么时候到期。直接存一个vaccine_expire_date，定时任务每天扫一次，提前30天提醒店主，这个功能做出来朋友特别喜欢。

预约表则是整个系统状态流转最复杂的部分。

CREATE TABLE `appointment` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) DEFAULT NULL COMMENT '预约编号', `user_id` bigint NOT NULL, `pet_id` bigint NOT NULL, `service_id` bigint NOT NULL, `appointment_date` date NOT NULL, `start_time` time NOT NULL, `end_time` time NOT NULL, `status` tinyint NOT NULL DEFAULT 0 COMMENT '0-待支付 1-已确认 2-服务中 3-已完成 4-已取消', `remark` varchar(255) DEFAULT NULL, `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, `deleted` tinyint DEFAULT 0, PRIMARY KEY (`id`), KEY `idx_user_pet_status` (`user_id`,`status`), KEY `idx_appointment_date` (`appointment_date`) );

预约状态我特别用了tinyint数字而不是字符串，这个决定后面帮了大忙。字符串虽然可读性好，但写代码时到处是魔法值，而且很难做范围判断。用数字后，状态流转可以用一个简单规则控制：只有“待支付”和“已确认”状态能取消，“已完成”状态永远不能回退。数据库层面读起来不直观，但配合枚举类，代码里写得很清楚。

时间字段我用了date + time分开的两个字段，而不是直接存“2024-05-20 14:00”的datetime。原因是预约冲突查询需要单独比较日期和时间段，分开存可以分别建索引，SQL也更简单。如果只用一个datetime，后面查某一天某时段的预约，索引利用率会差很多。

2.3 索引、事务和并发控制的早期规划

建表阶段就把索引想清楚，比上线后出现慢SQL再去优化舒服得多。

用户表手机号必须加唯一索引。登录、找回密码、店员查会员，都会用手机号作为查询条件，不加索引等于每次全表扫描。预约表常见查询是“某个用户有哪些预约”和“某一天有哪些预约”，所以我在user_id和appointment_date上分别建了普通索引。注意我建的是复合索引idx_user_pet_status，它能让“查某个用户未完成预约”这个高频查询直接走索引覆盖。

预约冲突是并发问题最典型的地方。两个店员在同一秒给不同顾客预约同一个美容师，数据库并发的insert如果不做控制，两条预约都会写进去。我的做法是这样：在service层创建预约时，先用一条带条件的select检查重叠时间；真正写入时再用数据库事务包裹，并通过唯一约束兜底。

SELECT id FROM appointment WHERE pet_id = #{petId} AND appointment_date = #{appointmentDate} AND status IN (0,1,2) AND start_time < #{endTime} AND end_time > #{startTime}

这条SQL能查出时间段交叉的预约。逻辑上只要存在重叠记录，就拒绝创建。并发量再大一点，可以在Redis里针对每个美容师每天的预约时间加锁，我最初没有加，等后面真的碰到并发问题再优化也来得及。不过事务边界必须一开始就划好：创建预约、锁定时间段、生成待支付单，这三个动作必须在同一个事务里，不能分开提交。

订单号也要设计好。我生成订单号时用了“业务日期 + 随机数”的方式，并且在订单表上建了唯一索引。支付回调是网络请求，可能重复通知，没有唯一索引的话，重复回调就会插入两条订单。有了唯一索引，第二次回调直接插入失败，配合更新条件where status = 0，就能实现幂等。

3. 核心功能实现与避坑记录

3.1 登录鉴权：JWT + Redis的组合

云宠之家是前后端分离结构，没有用传统Session，而是用JWT做登录态，Redis做token状态管理。

登录流程比较常规：前端提交手机号和密码，后端用BCrypt校验密码。密码永远不存明文，注册时就用BCrypt加密，即使数据库泄露，也没有人能反推出原始密码。校验通过后，用JWT生成一个有效期两小时的token，再把token写进Redis，之后前端每次请求都带着这个token，后端过滤器统一解析。

我当时没有引入Spring Security整套配置，而是写了一个简单的JwtFilter，继承OncePerRequestFilter。原因很直接：这个系统角色少、接口少，Spring Security的过滤器链对新人来说理解成本高，出了问题不好排查。我只需要在过滤器里做三件事：解析token、校验Redis里是否还有效、把当前用户ID塞进请求上下文。灵活性和可维护性都够用。

这里有个坑必须提醒：JWT签发之后是没法主动失效的，除非每次请求都去查数据库或Redis。所以我把token也存了一份在Redis，登出时删除Redis记录，修改密码时批量删除该用户的所有token。这样即使用户的token被别人截获，只要他点登出或者改密码，旧token立刻作废。

@Service public class AuthService { public LoginResult login(String mobile, String password) { User user = userMapper.selectOne(new LambdaQueryWrapper<User>() .eq(User::getMobile, mobile)); if (user == null || !BCrypt.checkpw(password, user.getPassword())) { throw new BusinessException("账号或密码错误"); } String token = Jwts.builder() .setSubject(user.getId().toString()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 7200 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); redisTemplate.opsForValue().set("login:token:" + token, user.getId().toString(), 2, TimeUnit.HOURS); return new LoginResult(token, user.getNickname()); } }

前端每次请求需要把token放在请求头里，后端通过拦截器统一校验。如果Redis里找不到对应key，直接返回401，让前端跳转登录页，前后端配合起来很顺。

3.2 宠物档案与图片上传的细节

宠物档案模块最容易被低估的是图片上传功能。表面看就是一个MultipartFile接收，实际上牵扯到文件存储、访问路径、安全校验三件事。

我最初实现时用的是本地目录存储，配置一个上传路径，后端把文件写到该目录，再通过SpringMVC静态资源映射暴露访问。这样做的好处是简单，不上服务器时本地也能跑通。生产环境如果图片量上来，可以换成云对象存储，但接口设计不要变，保持返回一个可访问的URL即可。

上传接口的坑主要在文件名和类型校验。我一开始直接用用户上传的原始文件名拼接路径，后来发现两个问题：一是中文文件名会导致URL乱码，二是可能存在路径穿越风险。正确的做法是彻底丢弃原始文件名，用UUID生成新文件名，只保留原始文件的后缀名，以此作为文件类型判断依据。

@PostMapping("/upload") public R<String> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty() || file.getSize() > 5 * 1024 * 1024) { throw new BusinessException("文件不能为空且大小不能超过5MB"); } // 白名单校验，只允许常见图片格式 String ext = StringUtils.getFilenameExtension(file.getOriginalFilename()); if (!Arrays.asList("jpg", "jpeg", "png", "webp").contains(ext.toLowerCase())) { throw new BusinessException("不支持的图片格式"); } String filename = UUID.randomUUID().toString().replace("-", "") + "." + ext; file.transferTo(new File(uploadDir + filename)); return R.ok("/files/" + filename); }

文件大小限制也要在配置里写明。SpringBoot默认上传大小是1MB，不配置的话，传一张手机照片就直接报错。我在application.yml里加了spring.servlet.multipart.max-file-size=5MB和max-request-size=10MB。注意，max-file-size管单个文件，max-request-size管一次请求所有文件总和。

疫苗提醒功能我用SpringBoot自带的@Scheduled实现。每天凌晨跑一次，扫描宠物表里vaccine_expire_date在未来30天内的记录，生成提醒消息存入数据库。这个定时任务是单机应用里非常实用的小功能，不需要引入消息队列，一个注解加一个方法即可。

@Component public class VaccineRemindTask { @Scheduled(cron = "0 0 8 * * ?") public void checkVaccine() { List<Pet> pets = petMapper.selectList(new LambdaQueryWrapper<Pet>() .le(Pet::getVaccineExpireDate, LocalDate.now().plusDays(30)) .ge(Pet::getVaccineExpireDate, LocalDate.now())); // 逐条生成提醒消息 } }

3.3 预约服务与状态机流转

预约模块是这套系统里最容易出Bug的部分，因为状态流转多，而且和支付、退款、服务完成等操作绑定在一起。

我一开始低估了状态管理的复杂度，直接在Service方法里写if判断，结果不到一周就出现了一个让人哭笑不得的Bug：已经完成的预约居然又能被取消，导致统计报表里出现负数。后来我改成显式状态机，每个操作都检查当前状态是否允许执行。

预约状态流转我用文字描述就是：

待支付可以取消，支付成功进入已确认；已确认到店后变成服务中；服务中结束变成已完成；已取消和已完成是两个终态，不允许再修改。支付成功回调里要判断当前预约是否处于待支付，只有待支付才能更新为已确认，否则说明回调重复，直接返回成功。

public void confirmAppointment(String orderNo) { Appointment appointment = appointmentMapper.selectOne( new LambdaQueryWrapper<Appointment>() .eq(Appointment::getOrderNo, orderNo)); // 通过状态字段保证幂等 int count = appointmentMapper.update(null, new LambdaUpdateWrapper<Appointment>() .eq(Appointment::getId, appointment.getId()) .eq(Appointment::getStatus, 0) .set(Appointment::getStatus, 1)); if (count == 0) { throw new BusinessException("预约状态已变化，请勿重复操作"); } }

预约时间冲突校验和数据库锁的问题我前面已经提过。实际操作中还有一个比较隐蔽的坑：创建预约时查了没有重叠，然后同一个宠物同一天又约了第二次，如果正常业务允许一宠一天多单，那没问题。但如果一宠一天只能一单，必须在表上加上pet_id + appointment_date唯一索引，否则并发情况下应用层判断拦不住。云宠之家这里确实允许一只宠物一天有多项不同服务，所以我在代码里只校验同服务项目的时间冲突，不加唯一索引。

不过预约编号order_no必须唯一，这个我加了唯一索引。预约编号和订单号我用的都是年月日时分秒加随机数，保证了单机并发下不会重复。

3.4 数据看板：统计不要写太胖的SQL

数据统计模块差点变成性能灾难。最初我直接在预约表和订单表上做实时统计，比如今日营收、本月预约量、服务项目销售排行，数据量小的时候很流畅，但等到正式环境积累了几万条订单，几个统计接口同时请求，数据库CPU直接飙高。

后来我把统计拆成了两层。第一层是实时看板，只查当天和近几天的轻量统计；第二层是历史报表，每天凌晨用定时任务把前一天的数据聚合成一张统计快照表，前端查历史报表时直接查快照，不碰业务表。

-- 今日营收 SELECT COALESCE(SUM(pay_amount), 0) FROM orders WHERE pay_status = 1 AND pay_time >= #{todayStart} AND pay_time < #{todayEnd}

-- 近7日预约量 SELECT appointment_date, COUNT(*) FROM appointment WHERE appointment_date BETWEEN #{start} AND #{end} AND status = 3 GROUP BY appointment_date

定时任务生成日统计表的代码逻辑也很简单：每天凌晨把前一天的订单总额、订单数、新增客户数、各服务销量写入一张day_report表。查询端就一行select，怎么都不会慢。前端用ECharts画折线图和饼图时，数据结构也基本能对得上。

做统计功能最大的心得是：永远不要在一个管理后台里面让用户实时查询全量历史数据。用户看报表通常不需要精确到秒，晚半小时生成完全没关系。用空间换时间，这个思路一旦想明白，后面很多报表功能都不会慌。

4. 部署运维与常见问题排查实录

4.1 本地环境搭建和启动

云宠之家的技术栈版本我会锁死，避免后面升级带来一堆莫名其妙的问题。当前项目使用的是SpringBoot 2.7.18、MyBatis-Plus 3.5.3、MySQL 8.0、Redis 6.x，JDK 8和11都验证过可以跑。

本地启动前需要先把MySQL和Redis准备好，然后配置数据源和Redis连接地址。这里面最容易出坑的是MySQL连接URL，一定要加上时区参数，否则高版本MySQL会报时间戳相关的异常。

spring: datasource: url: jdbc:mysql://localhost:3306/cloud_pet?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 servlet: multipart: max-file-size: 5MB max-request-size: 10MB mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

MyBatis-Plus的逻辑删除配置也建议一开始就打开。我在所有业务表里都加了deleted字段，查询的时候由MyBatis-Plus自动拼接deleted=0，不需要自己每次手写。注意逻辑删除不要用在订单表这种有财务意义的表上，订单只能有作废状态，不应该物理删除，也不应该逻辑删除后从业务统计里消失。

启动顺序看起来是常识，但真的会有人踩坑。Redis和MySQL必须先行启动，再启动SpringBoot应用，否则启动时数据源初始化就会报错。如果公司服务器上同时跑了很多服务，端口冲突特别常见。8080被占用的处理方式我习惯用以下命令查出来再处理，而不是直接换端口：

lsof -i :8080 netstat -tunlp | grep 8080

4.2 常见异常和排查思路

我把这套系统从开发到上线遇到过的几个典型问题整理成了表格，几乎都是新手容易碰到的。

跨域这个问题在本地前后端联调时会特别明显。我的做法是写一个CorsFilter，只允许来自配置文件中指定域名和端口的请求，而不是直接设置allowedOriginPatterns为*。生产环境不要全放通，前端地址固定的话就写死那几个来源。

定时任务那个坑我自己踩过。写完@Scheduled方法后怎么都不执行，排查了半天，发现在启动类上忘了加@EnableScheduling。SpringBoot的定时任务默认是关闭的，必须通过这个注解显式开启。如果你也遇到定时方法不跑，首先检查启动类。

4.3 上线前的性能与安全加固

系统能跑起来只是第一步，真正要上线还是得做一轮性能和安全的检查。

MyBatis-Plus分页插件必须配置。如果不加分页插件，调用Page方法是无法正确分页的，MyBatis-Plus会直接把所有数据查出来，内存分页，数据量大了必炸。配置分页插件也很简单，在配置类里注册MybatisPlusInterceptor并添加PaginationInnerInterceptor。

越权漏洞是管理系统最容易出现的安全问题。想象一下：普通顾客登录后知道自己的用户ID是100，如果把请求里的ID改成101，是不是就能查到别人的宠物和预约？解决这个问题不能靠前端隐藏按钮，后端在做查询时一定要把当前登录用户ID从token上下文取出来，SQL查询强制加上user_id = 当前用户的条件。这个规则我在云宠之家所有涉及用户数据的接口里都执行了。

文件上传安全前面提过一点，这里再补充：本地存储路径一定不要放在项目源码目录下，更不要允许文件名包含../。我的做法是配置一个独立的上传目录，启动时创建，并通过配置项映射到静态资源路径。同时，保存文件时重新生成UUID文件名，完全不信任用户传入的文件名。

数据备份不要等出了问题再想起。MySQL我设置了每天凌晨全量备份加binlog增量，Redis因为只是存token和缓存，重建成本低，没有单独备份。部署目录中uploads文件夹也要定期备份，宠物照片丢了很难找回来。备份这事听着不起眼，真的遇到服务器硬盘损坏时就懂它的价值了。

性能上再补充一个实用建议：所有业务表的公共字段create_time和update_time不要手动在代码里set，而是用MyBatis-Plus的字段自动填充。配置一个MetaObjectHandler，插入时自动填充create_time和update_time，更新时自动填充update_time。这能让代码简洁很多，也避免某些接口漏填时间字段导致数据问题。

最后再聊两句实施建议

整套系统从设计到上线，前后大概用了一个多月。最大的体会是：管理系统最怕的不是功能少，而是业务流程没想清楚。预约状态怎么流转，支付回调怎么保证幂等，员工权限怎么控制，这些设计问题哪怕多花一周时间也是值得的，否则后面改起来真要动大手术。

最后分享一个我当时没有设计好、后来被反复询问的细节：宠物疫苗的“最近接种日期”和“下次疫苗日期”一定要分开存。我看到很多店的记录只有最近接种日期，店员需要自己推算下次时间，不同的人算出来结果还不一样。云宠之家最初只存了一个疫苗到期日，后来需求方说想看上次接种记录，我只能额外加字段迁移数据。如果一开始就把这两个字段同时设计进去，就不用这么折腾了。

做这种业务管理系统，细节决定实际使用体验。希望这篇复盘能帮你少踩几个坑。