Spring Boot+Vue宠物医院管理系统实战：从架构设计到部署上线

兄弟，如果你正在考虑做一个“基于Spring Boot和Vue的宠物医院管理系统”类似的项目，不管是毕业设计、课设，还是公司内部想搞一套信息化管理后台，这篇内容应该能帮你省下不少试错的时间。我当初就是从零开始，把宠物医院里那一堆纸质档案、预约电话、药品台账全塞进一套前后端分离系统里，踩过的坑基本都在这儿了。文章不会只讲“怎么把代码跑起来”，更多是讲为什么这么设计、哪些地方容易翻车、怎么做出一个真正能交付的成品。

我给它定位得很明确：这是一个面向小型宠物医院/诊所的数字化管理平台，覆盖宠物档案、预约挂号、诊疗病历、药品库存、收费结算、统计报表六大核心场景。技术栈就两样：后端 Spring Boot，前端 Vue，这也是目前中小型项目里最主流、招人最容易匹配的组合。适合三类人：一是准备毕业设计、需要完整项目经验的在校生，二是想快速搭建行业管理系统的初级/中级工程师，三是宠物医疗机构的信息化负责人，想看看市面上这类系统大概是怎么做的。

1. 项目全貌：别急着写代码，先把宠物医院的业务流程捋清楚

很多人做管理系统，上来就建表、写接口，做着做着发现模块之间对不上，前台挂号的号、药房扣的库存、医生写的病历，各是各的一套逻辑，最后项目烂尾。这种失误的根源在于：没有先理解业务。

1.1 宠物医院的核心业务，其实是一条主链路

宠物医院的日常运转，拆开看就是一条清晰的主链路：预约 -> 挂号 -> 接诊 -> 诊断/开药 -> 收费 -> 离院。患者（宠物）先通过电话或者到店预约，前台在系统里建档，医生接诊后写电子病历、开处方，药房按处方发药扣库存，最后收银台结算费用。

我建议在项目一开始，就把这条主链路画出来，然后所有模块都围绕它设计。举个具体例子：用户在前台“挂号”这个动作，不只是创建一条挂号记录，它还会联动“宠物档案是否存在”“今日医生排班”“当前候诊队列”“诊室占用情况”等多个状态。很多新手写接口时只写了“插入一条挂号表”，后续医生接诊时发现看不到宠物历史病例、开药时不知道库存够不够，这就是没梳理主链路的后果。

1.2 核心模块拆解，每个模块都要能独立讲故事

我设计的系统，最终拆成了七个模块，每个模块都承担明确的业务职责：

1.3 设计上的两个关键取舍

第一个取舍：到底要不要做“小程序端”或“客户自助端”？ 很多类似的毕设项目喜欢加一个用户端App或者小程序。我的建议是——如果时间紧，砍掉它。宠物医院真正的日常高频操作者，是前台、医生、药房、收银员，而不是宠物主人。管理端的价值远大于用户端。把精力集中在管理端的体验和业务闭环上，项目的完成度和答辩说服力反而更高。

第二个取舍：数据库字段用中文还是英文？ 这个问题看起来有点傻，但我见过不少项目直接把“宠物名字”写成petName，把“宠物主人电话”写成petOwnerPhone，强行走英文命名但又不规范。我的建议是统一用英文命名，加注释。比如 pet_name、owner_phone，别用拼音。原因是后续写 SQL、对接前端字段、维护文档时，规范的英文命名会让所有人舒服得多。

2. 技术选型思考：Spring Boot 和 Vue 为什么是这对组合

选型不是拍脑袋，我先说结论：前后端分离、Spring Boot + Vue，在宠物医院这类中小型管理系统里，是性价比极高的组合。

2.1 后端选 Spring Boot 的三个理由

第一，生态成熟。Spring Boot 最大的优势不是它本身，而是它背后的 Spring 生态。做管理系统绕不开权限认证、数据持久化、文件上传、参数校验这些基础能力，Spring Security、MyBatis-Plus、Spring Validation、MinIO SDK，几乎全都有现成的稳定方案。你要做的不是“造轮子”，而是“选轮子”。

第二，上手门槛相对平滑。如果你熟悉 Java，Spring Boot 的自动配置能省掉大量繁琐的 xml 配置，一个 @SpringBootApplication 就能把服务跑起来。我见过不少刚从 SSM 转过来的同事，适应期基本都在一两周内。

第三，社区资料极其丰富。说句实在话，你项目里遇到的大多数问题，网上都有人踩过坑。搜索“Spring Boot + Vue 管理系统”能找到大量可参考的开源项目，热度词里像“第1关：第一个spring boot程序”“spring boot快速创建一个springboot项目”这类内容，基本覆盖了环境搭建、入门踩坑的绝大部分场景，能帮你快速起步。

我这次用的是 Spring Boot 3.2.x + JDK 17 + MyBatis-Plus 3.5.x。如果你还在用 JDK 8，建议至少升级到 JDK 17，性能和使用体验提升明显。Java 21 开启虚拟线程的玩法我也尝试过，Spring Boot 3.2 可以启用，不过目前项目里线程池还没到瓶颈，暂不纠结。

2.2 前端选 Vue，没选 React 的原因

Vue 在国内中小型项目里的普及度相当高，尤其适合管理系统这种“大量表单 + 表格 + 弹窗”的 CRUD 场景。相比 React，Vue 的模板语法更贴近传统 HTML 开发者的直觉，配合 Element Plus 这一套 UI 组件库，搭建后台页面非常快。项目里用到的第三方库——Vue Router、Pinia、Axios、ECharts——全部成熟稳定。

前端技术栈我推荐：Vue 3.4 + Vite + Element Plus + Pinia + Vue Router 4 + Axios + ECharts。其中 Vite 替代了老旧的 vue-cli，启动速度快很多，这在开发调试时体感非常明显。如果你还在用 Vue 2，我建议直接上 Vue 3，不用犹豫，组合式 API 写起来简洁很多，而且社区已经全面转向 Vue 3。

2.3 前后端分离的联通方式

既然选了分离架构，前端和后端只通过 HTTP/JSON 通信。CORS 跨域、JWT 令牌、Axios 拦截器，这三个是必须打通的点。我后面会展开讲每一块的实现细节，这里先建立一个整体认知：前端只关心“调用哪个接口、传什么参数、拿什么数据”，后端只关心“接收数据、校验权限、处理业务、返回结果”。中间的状态同步，由 JWT 令牌承担。

3. 数据库设计：建表就是搭地基，错了后面全是坑

数据库设计是整个项目里最不能省时间的环节。一张设计糟糕的表，后面用起来会接二连三冒问题，改了它又牵一发而动全身。我直接把核心表的结构拉出来讲，你照着用也能跑。

3.1 核心表与字段设计思路

先放一张总览表，再逐个拆关键的：

宠物档案表（pet）是整个系统的事实源头。我的习惯是所有关键字段都加上数据库注释，别偷懒，后面写接口联调时看着注释就知道字段含义。gender 用 tinyint 存：0 未知、1 公、2 母。birth_date 用 date 类型，别用 varchar 存，否则后面做年龄统计、疫苗提醒你会有想哭的冲动。owner_id 加索引，因为几乎所有的查询，都是“先找主人，再找名下宠物”。

预约表（appointment）是并发处理的焦点，字段 appointment_date 和 time_slot 的组合，必须做唯一索引或者至少加查询索引。我最开始没加，导致线上出现过两位用户抢同一时段、前台却不自知的情况。加上唯一索引之后，冲突在数据库层就被挡住了，这个我在下一节详细讲。

3.2 字段设计的四个硬经验

第一，所有业务表都加 create_time、update_time、deleted 三个字段。delete 用逻辑删除，值为0代表正常、1代表已删除，这样数据不会物理消失，做历史回溯和统计报表时价值巨大。MyBatis-Plus 配 @TableLogic 就能自动处理。

第二，金额一律用 decimal(10,2)，不要用 float/double。宠物医院的收费项目常常出现 0.02 元每克的驱虫药、0.5 元每毫升的注射液，浮点数运算会产生精度误差，这在结账环节是不可接受的。

第三，状态字段尽量用 tinyint 存数字，配合统一字典表解释。比如 appointment.status：0 待就诊、1 就诊中、2 已完成、3 已取消。别在代码里到处写 magic number，建议建一个 Dict 表或者在后端常量类里统一枚举。

第四，时间字段区分“业务时间”和“系统时间”。appointment_date 是用户指定预约的日期，create_time 是这条记录落库时间。这两者语义完全不同，别混用。我见过有人用 create_time 做报表统计，结果所有订单都聚在今天，数据完全没法看。

3.3 表关系的取舍：一对多、多对多怎么落地

业务上，一只宠物归属于一个主人，一条病历有多条处方明细，一张收费订单可能包含多项服务。我建议多表关联时，保持最少关联查询，用冗余字段换取性能。比如收费订单表里冗余一个 pet_name 字段，这样收银台列表页可以直接显示宠物名，不用每次去 join pet 表。管理系统的数据量不大，这种冗余完全在可接受范围内，换来的是代码简单、查询快。

4. 后端实现的核心细节：从工程骨架到业务难点

后端是整个系统的“大脑”，我把实现过程拆成几个关键环节，每个环节都附上可直接落地的代码思路和要点。这里面混了不少我实际摸索出来的经验。

4.1 基础工程搭建：别用 Spring Initializr 默认模板一健到底

工程结构我推荐 maven 多模块或者单模块分包。毕设和中小型项目，单模块分包完全够用，不用上微服务那套，自我感动没有意义。分包如下：

code复制com.pethospital
├── controller        # 接口层
├── service           # 业务逻辑层
├── mapper            # 数据访问层
├── entity            # 实体类
├── dto               # 请求/响应对象
├── config            # 配置类
├── common            # 公共返回、异常处理、常量
└── utils             # JWT、日期工具等

Controller 只做参数接收和结果封装，Service 层放业务规则，Mapper 层放 SQL。这三层职责要分清，我见过把 SQL 写进 Controller 的，后果就是业务一变，改 SQL 要找半天。分层不是教条，是为了让你后期维护时不用“拆东墙补西墙”。

核心依赖如下：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.7</version>
</dependency>
<dependency>
    <groupId>com.auth0</groupId>
    <artifactId>java-jwt</artifactId>
    <version>4.4.0</version>
</dependency>
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
</dependency>

注意：Spring Boot 3.x 和 MyBatis-Plus 的版本要匹配，3.5.5 以上的版本才支持 Spring Boot 3。如果你用 JDK 17 + Spring Boot 3，别拿老版本的 MyBatis-Plus 硬怼，启动会直接报“mapper not found”或者类冲突。

4.2 统一返回与全局异常处理，这是项目专业度的分水岭

我见过很多项目的接口返回格式五花八门：有的返回 Map，有的返回 null，前端解析时各种 if 判断。正确的做法是定义一个统一返回体：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;
    // 成功/失败静态方法
    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("success");
        result.setData(data);
        return result;
    }
}

配合 @RestControllerAdvice + @ExceptionHandler 处理全局异常。业务异常统一抛出 BizException，在全局异常处理器里转成 Result.fail，这样接口层代码不会到处都是 try-catch，看起来干净得多。前端 Axios 拦截器里统一判断 code 值，也省了每个页面各自处理错误。

4.3 JWT 认证 + 角色权限控制

宠物医院系统的用户分三类：管理员（admin）、医生（doctor）、前台收银（receptionist）。不同角色能访问的接口不同。我用 JWT 做无状态认证，拦截器里校验令牌、解析用户角色。

简化版 JWT 工具核心逻辑：

java复制public class JwtUtil {
    private static final String SECRET = "your-256-bit-secret";
    private static final long EXPIRE = 7 * 24 * 60 * 60 * 1000L; // 7天

    public static String createToken(Long userId, String role) {
        return JWT.create()
                .withClaim("userId", userId)
                .withClaim("role", role)
                .withExpiresAt(new Date(System.currentTimeMillis() + EXPIRE))
                .sign(Algorithm.HMAC256(SECRET));
    }

    public static DecodedJWT verify(String token) {
        return JWT.require(Algorithm.HMAC256(SECRET)).build().verify(token);
    }
}

拦截器里做两件事：白名单放行（登录接口、图片资源等不需要 token 的路径），其余请求校验 token，并把用户信息放到 ThreadLocal 或 Request Attribute 中，供 Service 层使用。业务代码里别再去解析 token，很啰嗦。

关于权限控制，我建议用 拦截器 + 注解 的方式，Spring Security 对中小型项目来说偏重。自定义一个 @RequireRole("doctor") 注解，在 Controller 方法上标注，拦截器里解析角色做校验，简单清晰，答辩时也能讲明白。

4.4 预约模块的并发处理：两个前台同时挂号，怎么保证不撞车

这是整个系统里最容易出 bug 的地方。用户在前台登录，选“5月20日上午10:30-11:00”这个时段，另一前台同时也在选同一时段。如果两边都通过了校验，数据库里就会出现两条重复预约。

处理方案分三层：

第一层是数据库唯一索引兜底，这也是我最推荐的方式。在 appointment 表给（appointment_date, time_slot, doctor_id）建唯一索引。后插入的那条会抛出 DuplicateKeyException，在全局异常里捕获，转成“该时段已被预约”的提示。

第二层是应用层检查 + 事务。Service 方法加 @Transactional，先查该时段是否已有“未取消”的预约，如果存在直接拒绝，否则插入。但注意：事务的默认隔离级别是“读已提交”，两个并发事务可能同时读到“无预约”，然后都插入。所以应用层检查只能作为辅助，不能作为唯一防线。

第三层是乐观锁或分布式锁。管理端场景下，应用层检查+唯一索引已经足够。如果你以后要做用户线上自助预约，流量大了再考虑 Redis 分布式锁。我后来测试时，用 JMeter 并发 50 个请求挂同一时段，数据库唯一索引拦截了 49 个，系统稳如老狗。

4.5 药品库存扣减：别用“先查后减”这种危险写法

药房发药时，需要扣减库存。很多人这样写：

错误写法：

java复制DrugInfo drug = drugInfoMapper.selectById(drugId);
if (drug.getStock() >= quantity) {
    drug.setStock(drug.getStock() - quantity);
    drugInfoMapper.updateById(drug);
}

这段代码在并发场景下会超卖。正确做法是用一条 SQL 原子扣减：

java复制int rows = drugInfoMapper.updateStock(drugId, quantity);
// 返回 0 表示库存不足，回滚
if (rows == 0) {
    throw new BizException("药品库存不足");
}

对应 SQL：

sql复制UPDATE drug_info 
SET stock = stock - #{quantity}
WHERE id = #{drugId} AND stock >= #{quantity}

这个方法我反复强调：数据库自带的原子性比你在应用层加锁可靠得多，性能也更好。这个细节是面试和答辩时的高频加分点，提出来就能体现出你真的做过高并发下的数据一致性考虑。

4.6 缓存与日志：热搜词里那些“spring boot caffeine”“spring boot日志”，在这里有用武之地

系统里宠物档案、药品字典这类低频变更的数据，每次请求都查数据库其实挺浪费。我用 Caffeine 做本地缓存，Spring Boot 3 的官方推荐就是 Caffeine。用法很简单：

java复制@Cacheable(cacheNames = "drugInfo", key = "#id")
public DrugInfo getDrugById(Long id) {
    return drugInfoMapper.selectById(id);
}

先加依赖 spring-boot-starter-cache 和 caffeine，然后在配置类里 CacheManager 设一下过期时间即可。药品信息变更时，记得调用 @CacheEvict 清缓存，否则会读到旧数据。这个坑我踩过：改了药品价格，前台收费还是显示旧价，排查了好久才发现是缓存没清。

日志方面，Spring Boot 默认用 Logback。生产环境里我加了一条规则：错误日志单独输出到 error.log 文件，方便排查问题。配置方式就是 logback-spring.xml 里加一个 file 类型的 appender，按天滚动。项目上线后，排查问题基本靠它。

4.7 文件存储：宠物照片、检验报告图的方案

宠物档案要传照片，病历里可能要上传血常规报告、B超图。存哪里？两个方案：本地磁盘和云存储/MinIO。小项目存本地磁盘最简单，但做毕设/交付时存在两个问题：一是图片和代码在一起，备份迁移麻烦；二是后面部署到服务器，图片目录路径配置不对，前端加载就 404。

我的建议：本地磁盘+Nginx 静态映射是性价比最高的方案。后端接收 MultipartFile，保存到服务器 /data/pet-images/，文件名用 UUID 重命名，避免中文名乱码和太上传时间名重复。返回给前端一个 URL 路径，如 /images/xxx.jpg，Nginx 里加一条静态资源映射就能访问。如果项目中期想升级，可以平滑切到 MinIO，热度词里“spring boot集成minio”搜一下有大把教程，接口调用思路类似，只是换了个存储地址。

5. 前端 Vue 项目落地：如何做到页面好看又高效

前端这部分，我会重点讲几个真实项目里“人人都会遇到但文档很少整合”的问题：环境安装、路由设计、页面组件化、状态管理、图表统计。

5.1 环境配置与项目初始化，别卡在第一步

尽量使用 Vite 创建项目，命令：

bash复制npm create vite@latest pet-hospital-web -- --template vue
cd pet-hospital-web
npm install

初次接触 Vue 的人最容易被.node_modules安装、npm网速、版本冲突搞得崩溃，我的建议是安装 Node.js 18+ 后，先把 npm 镜像源切换成国内源，减少大量“卡住不动”“下载失败”的时段。接着安装项目必须的三件套：

bash复制npm install element-plus axios vue-router@4 pinia echarts
npm install -D sass

Element Plus 建议直接用全量引入，开发期图省事，后期做性能优化再考虑按需引入。别在项目初期就折腾按需自动导入插件，配置出错的时候你半天也找不到问题在哪。

5.2 路由设计：权限控制的前端配合

Vue Router 4 的核心路由表建议分为两部分：公共路由（登录页、404页）和 业务路由（需要登录才能访问的页面）。业务路由放在一个数组里，通过动态路由 addRoute 在用户登录后加入，这样前端也能实现一个基础的路由级权限控制。

javascript复制const businessRoutes = [
  {
    path: '/dashboard',
    name: 'Dashboard',
    component: () => import('@/views/Dashboard.vue'),
    meta: { title: '工作台', icon: 'Odometer' }
  },
  // ...其他页面
];

路由守卫的核心逻辑：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token');
  if (to.path === '/login') {
    next();
    return;
  }
  if (!token) {
    next('/login');
    return;
  }
  next();
});

这里有个实用细节：用户刷新页面时，Pinia 里的用户信息会丢失，需要先发请求重新拉取用户信息，再放行业务页面。否则你会在控制台看到“user is null”的错误，这是典型的新手坑。

5.3 Axios 封装：一处统一，全站清爽

Axios 必须统一封装，这是前端项目从“能跑”跨向“协作规范”的关键一步。拦截器做三件事：带 token、接收统一返回体、错误处理。

javascript复制// request.js
const service = axios.create({
  baseURL: import.meta.env.VITE_API_BASE_URL,
  timeout: 10000,
});

service.interceptors.request.use(config => {
  const token = localStorage.getItem('token');
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

service.interceptors.response.use(
  response => {
    const res = response.data;
    if (res.code === 200) {
      return res.data;
    }
    if (res.code === 401) {
      localStorage.removeItem('token');
      router.push('/login');
      return Promise.reject('登录已过期');
    }
    ElMessage.error(res.message);
    return Promise.reject(res);
  },
  error => {
    ElMessage.error('网络异常，请稍后重试');
    return Promise.reject(error);
  }
);

export default service;

baseURL 用环境变量管理，开发环境指 http://localhost:8080/api，生产指向 Nginx 反代路径。这个是极强的实战细节：不写死接口地址，项目才能平滑地从本机挪到服务器。

5.4 可视化统计报表，ECharts 怎么接数据

宠物医院的管理者肯定想看两个东西：每月营收趋势、各科室接诊量占比。前端用 ECharts 封装一个 BaseChart 组件，接收 option 对象，内部负责初始化、销毁、自适应窗口调整。后端提供统计接口，返回 [{date, amount}, ...] 这种结构，前端做一次 map 就能塞进 series。

有个坑：图表 100% 宽度在 Flex 布局下经常显示为 0px 或者 1000px 被挤爆。我的处理方式是给 ECharts 容器设置固定高度，宽度用 computed 动态计算或者给容器类加 overflow: hidden 并设置 position: relative。初次渲染时若拿不到宽度，可以在 mounted 钩子里用 setTimeout 或 nextTick 强制刷新一次。

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

单模块能跑不算本事，前后端能流畅联调、部署上线，才叫真正的“项目完成”。这一节我讲一些你大概率会遇到的细节坑，直接按场景排列。

6.1 跨域问题，第一道必过的关卡

开发环境前后端端口不同（前端5173，后端8080），天然存在跨域。解决方案有两类，我建议后端配置一个全局 CORS 配置类：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("*")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

请注意：如果用了 allowCredentials(true)，allowedOrigins 就不能用 ，要改用 allowedOriginPatterns("")，否则 Spring Boot 会启动报错或请求被拒。如果你使用了自定义拦截器校验 token，注意 CORS 配置要先于拦截器生效，否则预检请求（OPTIONS）会被拦截器拦截，报跨域错误。处理方式是在拦截器里对 OPTIONS 请求直接放行。

6.2 生产部署用 Docker 还是宝塔？

交付项目时，我不想让对方搞一堆 Java 环境配置的麻烦事，所以最省心的是 Docker Compose 一条命令启动后端 + 前端 + Nginx + MySQL。这里贴一个简化版 Compose 结构：

yaml复制version: '3.8'
services:
  mysql:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=yourpassword
      - MYSQL_DATABASE=pet_hospital
    volumes:
      - mysql-data:/var/lib/mysql
    ports:
      - "3306:3306"

  backend:
    build: ./backend
    environment:
      - SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/pet_hospital
    depends_on:
      - mysql
    ports:
      - "8080:8080"

  frontend:
    build: ./frontend
    ports:
      - "80:80"

前端构建时，Vite 打出的静态文件由 Nginx 托管，Nginx 再把 /api 开头的请求反向代理到后端 8080。生产环境里前端不需要也不需要直接暴露后端端口，统一走 Nginx 这一层，既解决了跨域，又多了一重保护。

如果你没有 Docker 环境，用宝塔面板手动部署也不难——后端打 jar 包，前端把 dist 目录传到 Nginx 站点根目录，再配置反向代理。这个方案对运维能力要求低，小诊所完全够用。

6.3 典型问题速查表

6.4 做好这四件事，项目才真正可交付

第一，写清楚 README。环境要求、启动方式、默认账号、数据库初始化脚本、部署步骤，每一项都要写清楚。不少项目交付后对方跑不起来，80% 是因为 README 太敷衍。

第二，初始化演示数据。系统一进来就是要看图表和数据，空荡荡的界面很劝退。准备一份包含十只宠物、二十个账号、三个月就诊记录的 SQL 脚本，演示效果直接提升一个档次。

第三，统一接口返回格式。这个前面提过，但在联调阶段，前后端经常因为格式问题反复拉扯。一定先定好契约：{ code, message, data }，所有接口一致，前端全局处理，后端统一封装。

第四，接口请求和响应一定要打日志。我习惯用一个简单的过滤器在日志里打印请求路径、参数、耗时。项目出问题排查时，这份日志能救你命。别等甲方半夜打电话说“系统打不开了”，你还得远程抓包。

7. 写在最后的几点实在话

按照惯例，我会在最后分享几个从实战中反复打磨出来的个人经验。这套宠物医院管理系统做到现在，我已经在各处跑了差不多半年多时间，项目从能“跑通”到真正被日常使用，中间隔着的恰恰是那些教科书不会写的细节。

第一个体会：不要沉溺在“技术炫技”里。宠物医院的管理者不关心你用的是不是微服务、有没有上 K8s，他们只关心前台小姐能不能在 30 秒内完成一次挂号、医生能不能快速翻到宠物半年前的化验结果、月底报表能不能一键导出。核心价值是把业务流程理顺，技术选型永远是服务于业务的。

第二个技巧：开发前期就做接口契约文档，哪怕只是手写在文档里的表格。前后端各写各的，等到联调再对接口，效率极低。把接口路径、请求参数、返回结构在前端开工前敲定，节省的时间是惊人的。

第三个建议：“宠物多归属”场景一定要考虑进去，也就是一个主人可能同时带两只猫、一只狗来就医。我的第一版设计把宠物和主人角色耦合了，后面花了很大力气才拆开。做任何信息管理系统，先考虑“一对多”关系在界面和流程上的表现，比后期重构成本低得多。

这个项目后续还能扩展的方向不少：微信小程序端的疫苗到期提醒、口服药定期下单、远程问诊视频接口，都是真实的市场需求。如果你打算长期维护，可以先从“消息推送”这块入手，成本最低、用户感知最强。祝愿你的项目从设计到落地的每一步都走稳，代码写得开心，交付得漂亮。