胖厨胡学斌“宠物指南服务平台”这个词，听起来像是把内容资讯和业务管理揉在一起，实际上做起来也确实是这样。我最初接这个项目时，甲方给的需求只有一句“做一个宠物养护指南加服务预约的系统”，但真正开始拆解，才发现里面有内容发布、宠物档案、预约排期、问答互动、后台权限管理好几条业务线。如果你也在做类似的 Spring Boot 管理平台，尤其是课程设计或中小型商用项目，这篇复盘应该能帮你少走不少弯路。
我从项目立项到最终部署，把整个过程中的架构选型、数据库设计、关键模块实现、以及踩过的坑都整理了一遍，中间涉及大量 Spring Boot 的实际配置和代码细节。考虑到很多同学是从“Spring Boot 项目怎么做”开始入门的，本文也会把一些核心概念用比较直白的方式说清楚。
1. 这个项目到底在做什么：宠物指南平台的业务画像与模块地图
1.1 用户侧与服务侧的两种使用场景
开始写代码之前，我建议每个人都先画一张业务流程图。宠物指南服务平台的业务其实可以拆成两个端：普通用户端和后台管理端。用户端面向养宠人群，核心诉求是“查询养护知识 + 管理自己的宠物档案 + 预约线下服务 + 向专家提问”；管理端面向平台运营人员，核心诉求是“发布和维护指南文章、处理预约订单、审核用户问答、管理宠物分类和门店信息”。
不要小看这一步。很多时候项目写到一半发现表设计不够用，就是因为最开始没有把使用场景理清楚。比如“收藏”功能到底该挂在文章上还是挂在分类上，如果一开始就明确用户侧行为包含“收藏指南文章用于后续查看”，那么设计一张单独的favorite表就是顺理成章的事。
1.2 平台的核心功能模块拆解
按我最终实现的结构，这个系统一共分为六大业务模块：
- 内容管理模块：指南文章的分类维护、富文本发布、封面图片上传、上下架操作。
- 宠物档案模块：用户维护自家宠物的基本信息，包括品种、体重、疫苗记录、绝育状态等。
- 服务预约模块：预约洗澡、驱虫、疫苗接种等服务项目，后台可查看和变更订单状态。
- 问答互动模块：用户发起问题，管理员或养宠顾问进行回答。
- 系统用户模块：前台用户注册登录、后台管理员账号鉴权。
- 数据统计模块：统计文章浏览量、预约数量、分类内容占比，用于运营决策。
这种划分方式是有讲究的：内容、宠物、预约、问答四个模块各自独立成域，但通过用户 ID 互相打通。比如用户躺在“宠物档案”里的一条宠物记录，可以在预约服务时直接引用；用户在问答区咨询“猫不吃东西怎么办”，后台的顾问也能看到这个用户养了什么品类的猫。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型复盘：为什么在一堆框架里只挑了这几个
2.1 Spring Boot 版本选型：2.7.18 还是 3.x
这是项目立项时第一个纠结的点。Spring Boot 3.x 已经发布很久了，但它基于 Jakarta EE，很多老版本的第三方库不兼容，如果团队里有人还停留在旧版 MyBatis 或 SpringFox，迁移成本会非常高。
我在这个项目里选的是 Spring Boot 2.7.18。原因是 2.7 是 2.x 系列的最后一个维护版本，官方支持周期覆盖项目交付节点，同时兼容市面上绝大多数的 Java 8 代码习惯和现成教程方案。很多同学直接一上来用最新版 Spring Boot，结果发现某个 starter 根本拉不下来，再去翻资料就会发现大多数排查经验都是基于 2.x 的，版本太高反而成了瓶颈。
有一点值得提的是，Spring Boot 2.7.x 使用的 springdoc-openapi 版本和 3.x 也不同。如果你用的是 swagger 3 注解，最好在依赖里直接锁定 springdoc-openapi-ui 为 1.6.x 版本线，不然启动时容易出现 NullPointer 或路径匹配异常。
2.2 后端核心组合：Spring Boot + MyBatis-Plus + MySQL + Redis
持久层我采用了 MyBatis-Plus，不是为了炫技，是因为这个项目里大量操作为单表 CRUD，MyBatis-Plus 的自带 BaseMapper 能覆盖 90% 的常规方法，代码量至少减掉三分之一。更重要的是它对分页的支持很友好，后台列表页用 selectPage 就能返回分页数据，对赶工期的项目来说是真的省事。
数据存储选 MySQL 8.0，Redis 用来做缓存和 Token 黑名单。Redis 其实在这个阶段不一定必须上，但我考虑到指南文章首页的点击量很高，如果每次都直接查 MySQL，数据库压力会偏大，所以就设计成：文章详情先查 Redis 缓存，缓存没有命中再回源查询 MySQL。这个设计后期压测效果不错。
2.3 前端与接口对接方式：Vue + Axios 的前后端分离
项目采用了前后端分离结构，前端用 Vue 2 + Element UI，后端只提供 JSON 数据的 RESTful API。这种模式下，后端开发更需要重视接口文档规范，所以我从一开始就集成了 Swagger，并且把接口返回结构统一成了 Result<T> 格式，例如：
json复制{
"code": 200,
"message": "success",
"data": {}
}
如果返回结构不统一，前端处理起来就是噩梦，每个接口都要单独判断。统一之后，前端 Axios 的响应拦截器可以集中处理错误码，比如 code 为 401 时直接跳去登录页，整个联调过程会顺畅很多。
提示：集成 Swagger 的注解并非越多越好，最实用的是在 Controller 类上使用
@Tag，在接口方法上使用@Operation，DTO 内部字段用@Schema，三件套基本够用。
3. 数据库设计：从宠物档案到内容库，表结构里的关键取舍
3.1 核心表结构概览
我把数据库命名为 pet_guide_platform，字符集用 utf8mb4。包含主要表如下：
user—— 前台用户表/后台用户表可合并，通过role字段区分，也可以拆成member和admin两张表。本项目合并为一张，通过role_type区分。pet_category—— 宠物分类表，用于区分猫、狗、异宠等。pet_archive—— 宠物档案表，一个用户可绑定多个宠物。article—— 指南文章表。article_category—— 文章分类表。favorite—— 用户收藏文章表。service_item—— 服务项目表，比如“猫咪洗护套餐”。appointment—— 预约订单表。question和answer—— 问答及回复表。
3.2 宠物档案表：一对多关系的细节
pet_archive 是一张比较典型的“从属用户”的表格。设计它的关键是理清每个字段的实际含义。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，使用雪花算法生成 |
| user_id | bigint | 关联 user 表 |
| pet_name | varchar | 宠物昵称 |
| pet_type | int | 宠物类型，关联分类表 |
| breed | varchar | 品种，如“金渐层” |
| birthday | date | 生日，用于计算年龄 |
| weight | decimal | 体重，单位 kg |
| gender | tinyint | 性别 0 未知 1 公 2 母 |
| vaccine_status | tinyint | 疫苗状态 0 未接种 1 已接种部分 2 已接种完全 |
| avatar | varchar | 宠物头像 URL |
这里有一个很容易被忽略的业务逻辑：用户预约服务时，需要展示“该宠物当前是否满足服务条件”，比如驱虫服务会限制最小体重。如果把体重、疫苗状态这些信息放在预约表里，多个服务预约会产生大量冗余数据；但放在档案表里，就能在创建订单时直接读取并做校验。
3.3 文章内容表：富文本和浏览量字段
文章表的结构相对常规，但有两个点我想特别提一下。
第一是 content 字段。指南文章的内容是富文本，如果用户量不大，直接存 longtext 完全没问题；但后续如果要接全文检索引擎或做 HanLP 分词搜索，建议把“原始 Markdown”、“解析后的 HTML”以及“纯文本提取内容”分开存储。纯文本内容对后期做搜索分词非常有用，不然你只能用正则扒 HTML 标签，还容易把脚本内容扒出来。
第二是浏览量的更新策略。不要在用户每次点开详情时都执行一次 update article set view_count = view_count + 1，这样会给数据库带来巨大的写压力。更合理的方式是先用 Redis 的 INCR 累加，然后定时任务每隔 5 分钟把增量同步回 MySQL。热搜里不是总提到 Spring Boot 整合 Redis 吗，这个场景就是最典型的落地用法之一。
4. 后端工程搭建与配置：IDEA 初始化 + 多环境 YAML + 常用集成配置
4.1 从 Idea 创建一个 Spring Boot 项目时的容易出错点
创建项目时有两个点特别容易踩坑。
第一个是依赖坐标。Spring Initializr 默认拉取的是 Maven Central，但国内网络访问很慢。我在 IDEA 中新建项目时，会把 Server URL 改成阿里云镜像地址，这样依赖下载速度会快很多。如果项目已经创建成功但无法拉取依赖，则需要修改 Maven 的 settings.xml，加上阿里云 central 镜像。
第二个是 Maven 打包时的版本号匹配。如果 POM 里定义的 parent 版本是 2.7.18，但本机 Java 版本是 17，代码依然可以跑，因为 Spring Boot 2.7.x 支持到 Java 17；但如果某些第三方类库用了低版本 javassist，有可能在启动阶段报 UnsupportedClassVersionError。所以最好是 Java 8 配 2.7.x，Java 17 配 3.x，这样最不折腾。
4.2 多环境配置：application.yml 的拆分思路
开发时数据库密码、测试环境地址、线上 Redis 地址都不一样，所以我习惯把配置文件拆成三个：
application.yml：公共配置application-dev.yml：开发环境application-prod.yml：生产环境
公共配置里放服务端口和框架常量，环境配置里放数据源和第三方密钥。启动时通过 --spring.profiles.active=dev 来指定当前环境。有人问要不要用 application.properties，我的态度是 YAML 的可读性和层级结构更好，尤其是 datasource 下多个配置项堆叠时，缩进能一眼看出层级关系。这块也是很多初学者面试时被问到的点，掌握多环境配置非常加印象分。
一份典型的 application-dev.yml 长这样：
yaml复制server:
port: 8080
spring:
datasource:
url: jdbc:mysql://localhost:3306/pet_guide_platform?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
username: root
password: 123456
driver-class-name: com.mysql.cj.jdbc.Driver
redis:
host: localhost
port: 6379
database: 0
timeout: 3000ms
servlet:
multipart:
max-file-size: 20MB
max-request-size: 40MB
mybatis-plus:
configuration:
log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
map-underscore-to-camel-case: true
global-config:
db-config:
id-type: assign_id
logic-delete-field: deleted
logic-delete-value: 1
logic-not-delete-value: 0
这里有个细节：map-underscore-to-camel-case 开启后，数据库字段 user_id 能自动映射到实体类 userId。但很多初学者刚接触 MyBatis 时不会开这个配置，于是 SQL 中不得不写各种别名，非常痛苦。用 MyBatis-Plus 时这个配置默认就是开启的，所以基本不会出问题，但如果手写 XML 里的自定义 SQL，它依然只对列名和属性名做自动映射，遇到复杂嵌套结构还是要手动指定 resultMap。
4.3 Swagger 与 Knife4j 的集成细节
做前后端分离后，Swagger 文档基本是团队协作的生命线。我引入的是 Knife4j 增强包，它在 Swagger 基础上前端界面更友好，支持离线文档导出，对接口调试更顺手。
集成时会有一个经典问题：生产环境不能暴露 Swagger 页面，所以需要通过配置进行动态开关。常见做法是在配置文件中加一个属性：
yaml复制knife4j:
enable: true
然后在配置类里使用 @Value("${knife4j.enable:false}") 判断是否注册 Docket Bean。这样开发环境看到文档，生产环境就自动隐藏，避免接口信息泄露。
4.4 Resource 资源映射与文件上传配置
宠物头像、文章封面都是图片文件。我把图片存在服务器本地的 /data/pet-guide/upload/ 目录下，然后在 Spring Boot 里配置一个虚拟路径映射，将 URL 请求指向磁盘路径。如果你问过“Spring Boot 如何做资源映射”，核心就一段代码：
java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
@Value("${file.upload-path}")
private String uploadPath;
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry.addResourceHandler("/upload/**")
.addResourceLocations("file:" + uploadPath);
}
}
注意 Windows 下路径需要写成 file:D:/data/pet-guide/upload/，Linux 下写成 /data/pet-guide/upload/。最稳妥的方式是在配置文件中设置时避免写死分隔符，用 Paths.get(uploadPath).toAbsolutePath() + File.separator 拼接出兼容路径。
5. 登录鉴权模块实战：从用户表设计到 JWT 拦截器释放 Swagger
5.1 用户表和权限模型
用户表设计不能只满足“登录”，还要满足“谁登录、能看到什么、能操作什么”。我用的角色模型比较简单：
roleType=0：普通用户，仅访问前台接口。roleType=1：内容编辑，可发布与管理指南文章。roleType=2：超级管理员，拥有系统全部权限。
用户表字段包括 id、username、password、phone、avatar、nickname、role_type、status、create_time 等。
密码存储是个非常容易踩坑的点。明文存储是绝对不可取的，直接 MD5 也不够安全。我最终采用了 BCrypt 加密。Spring Security 自带 BCryptPasswordEncoder，但如果不想整套引入 Spring Security（毕竟拦截器开发量更小），可以用 spring-security-crypto 这个单独的 jar 包，把它当成工具类使用。这样既不需要引入完整的过滤器链，又能使用 BCrypt 的随机盐机制。
5.2 JWT 登录流程与 Token 刷新
登录的核心流程如下：
- 用户提交用户名和密码。
- 后端校验密码成功后，生成 JWT Token，过期时间设为 24 小时。
- 前端把 Token 存到
localStorage，每次请求在请求头Authorization: Bearer <token>中携带。 - 后端拦截器解析 Token，验证身份与有效期。
JWT 使用 io.jsonwebtoken:jjwt 库，生成 Token 的工具类核心代码如下：
java复制public String generateToken(Long userId, String username, Integer roleType) {
Date now = new Date();
Date expiration = new Date(now.getTime() + 86400000L);
return Jwts.builder()
.setSubject(username)
.claim("userId", userId)
.claim("roleType", roleType)
.setIssuedAt(now)
.setExpiration(expiration)
.signWith(secretKey, SignatureAlgorithm.HS256)
.compact();
}
解析 Token 时要注意捕获 ExpiredJwtException 和 SignatureException，不要让异常直接冲垮接口。拦截器里解析出来后，把用户信息放到 ThreadLocal 或 RequestContextHolder 中，后续 Controller 就能直接取到当前登录用户 ID，不用每个方法都传一次参数。
5.3 资源放行配置：Swagger 和登录接口的路径规则
这是整个项目里问得最多的一个点，关键词搜索里“springboot jwt 放开 swagger”一直在热搜前列。问题根源在于：JWT 拦截器把 /doc.html、/v3/api-docs/** 这类 Swagger 资源路径也拦截了，导致前端无法访问接口文档。
解决方案不是把 Swagger 接口全部绕过，而是注册拦截器时手动添加排除模式。给出一段可以直接复制的代码：
java复制registry.addInterceptor(jwtAuthInterceptor)
.addPathPatterns("/**")
.excludePathPatterns(
"/auth/login",
"/auth/register",
"/article/public/**",
"/pet/category/list",
"/doc.html",
"/webjars/**",
"/v3/api-docs/**",
"/swagger-ui/**",
"/swagger-resources/**",
"/upload/**",
"/error"
);
这样做有一个隐患：如果后续新增了一些本来就不需要 Token 的接口，例如优惠券领取页面，很容易忘记在拦截器里放行。我最终的处理是在这些接口的注解上添加 @IgnoreAuth 自定义注解，然后在拦截器里检查 HandlerMethod 上是否存在该注解，存在就直接放行。这样权限标记与代码逻辑的位置更近，后续管理起来更省心。
5.4 拦截器中的角色权限校验
登录后，普通用户和管理员访问同一接口的权限可能完全不同。我的做法是在拦截器中用 HandlerMethod 读取方法上的自定义注解 @RequireRole(roleType = 1)，然后根据当前登录用户的 roleType 判断是否允许访问。
这种简单方案在小项目里非常实用，但有一个前提：所有 Admin 路径必须以 /admin/** 开头且不被普通接口复用。如果路径混在一起，靠拦截器做角色判断会出现大量逻辑分支，建议这种场景还是引入 Spring Security 的 @PreAuthorize 注解，从框架层面做方法级鉴权。
6. 核心业务 API 开发实录：档案管理、指南内容、问答互动常见实现技巧
6.1 宠物档案模块：新增、编辑及头像上传
我这里给出一个宠物档案新增的典型接口流程。
控制层接收前端传来的表单字段，通过 @RequestBody 反序列化成 DTO。因为图片上传是单独的文件接口，前端会在提交表单前先把图片传到 /file/upload，拿到返回的 URL，再把这个 URL 作为 avatar 字段传给后端。
文件上传接口的实现核心是接收 MultipartFile 后使用 UUID 重命名文件，防止文件名冲突。命名时我保留原文件的扩展名并用 FilenameUtils.getExtension 获取，避免直接拼接文件名导致路径穿越漏洞。
保存文件后返回访问路径，前端直接拼接图片地址显示即可。
6.2 指南内容管理：带分类的树形结构和上下架状态
指南分类支持多级层级，我在 article_category 表里增加了 parent_id 字段，根分类的 parent_id 为 0。查询列表时利用递归组装出树形结构。在实现深度只有两三层的小系统中，直接用 Java 递归没问题；如果分类深度不确定或者数据量极大，就要改用左右值模型或闭包表。
关于文章上架和下架，最简单的方案是给 status 字段设三种取值：0 草稿、1 上架、2 下架。每次请求时前端要区分接口是带有 public 的前台接口还是管理后台接口：
- 前台公开接口：只查询
status = 1的数据。 - 后台管理接口：可以使用
status作为查询条件，默认全部。
这块容易出错的是很多人会把“下架”实现为物理删除，结果客户反映历史预览地址全断裂了。指南文章中收藏记录、用户浏览记录都引用文章 ID，一旦物理删除，这些记录都会变成无效数据，所以逻辑删除比物理删除安全得多。MyBatis-Plus 支持全局逻辑删除字段，只需要在实体上加上 @TableLogic 注解，就会自动把删除操作转成更新操作。
6.3 问答模块：为什么我用答案追加而非一对多嵌套？
在问答模块设计上，我的起初方案是问题表与回答表一对多。这样可以实现多轮回复、评论交互，但项目实施后发现，就养宠问答这类场景而言，大部分问题只需一个权威回复即可，做成一问一答模式反而更清晰。
当然这不代表答表就失去了意义。为了保证后续能扩展评论互动，我在 answer 表保留了 reply_count、like_count 字段，用于展示回复的热度。热门问题排序，可以先根据“今日回答数”和“浏览量”组合计算热度值。由于项目较小，不需要 Redis 的排序集合，直接查出问题列表后在内存中按加权公式排序即可，等真正超过万级数据再考虑引入分页和缓存。
6.4 预约服务模块：状态流转与并发冲突
预约服务模块核心是一个状态机。我的设计如下：
WAIT_CONFIRM：待平台确认。CONFIRMED：已确认。IN_SERVICE：服务中。COMPLETED：已完成。CANCELED：已取消。
用户提交预约后，订单初始状态是待确认。后台确认后，系统根据预约时间更新服务排期。要注意的是，同一时间段可能有多人预约同一服务，所以需要做唯一约束或事务锁。很常规的思路是在 appointment 表中创建一个包含 service_item_id、appointment_date、time_slot 的唯一索引，从数据库层面阻止同时间段重复预约。
但唯一索引的存在会影响正常的取消和变更操作，所以我在业务层面加了事务：创建订单时先查询是否存在同时间段的非取消状态订单，如果有则直接返回提示，没有才插入。对于日均预约量几百的平台，数据库层面加个普通索引就够了，不需要引入分布式锁。
7. 项目落地时踩过的坑与解决过程：从本地编译到服务器部署
7.1 启动 Banner 与项目辨识度：不只是图个好玩
Spring Boot 启动时那个大写的 ASCII Art Banner 是可以替换的。在 src/main/resources 下新建一个 banner.txt，启动时就会加载。团队多人开发时自定义一个 banner，可以在日志中快速识别当前启动的是哪个服务、哪个环境，省得每次都要看端口号。
如果你不会手写艺术字，可以找一个在线 Banner 生成器，把“Pet Guide Platform”丢进去，会自动生成 ASCII 字符画。这个东西虽然和生产功能没有直接关系，但用来区分本地、测试和现网启动日志是真有用。特别是同一个服务器部署两套环境时，看启动日志顶部就能分辨。
7.2 部署时数据库连接失败：SSH 隧道与防火墙问题
我第一次部署到云服务器时，配置文件里直接使用的是 localhost:3306，结果容器启动时一直提示连接拒绝。排查后发现 MySQL 虽然跑在宿主机上，但 Docker 容器内的 localhost 指向容器自身，根本不是宿主机。
解决办法有两个：一是把数据库地址改成宿主机内网 IP；二是如果数据库只允许本机连接，要用 --network=host 启动 Spring Boot 容器。这个坑几乎每一个做 Docker 部署 Spring Boot 项目的人都踩过，建议以后写 Docker 部署文档时，把网络模式写清楚。
另一个坑是在服务器上开启了防火墙或安全组策略，导致 8080 端口在公网无法访问。部署完成后先在本机 curl http://localhost:8080/doc.html 验证应用本身是否正常，再从外部网络访问一次，如果外部访问不了就先排查安全组。这一套排查链路很机械，但基本能解决 80% 的部署访问问题。
7.3 JWT 时间戳与 MySQL 时区不一致问题
项目本地跑得好好的，上了服务器后登录报错提示 Token 过期或时间异常，后来发现是服务器时间和本地时区相差很大。JWT 的时间戳在解析时强依赖系统时区，而 MySQL 连接串和 JVM 默认时区不一致，就会出现非常诡异的问题。
解决办法是在启动命令中明确指定 JVM 时区：
bash复制java -jar -Duser.timezone=Asia/Shanghai pet-guide-platform.jar
同时 MySQL 连接串加上 serverTimezone=Asia/Shanghai。这样本地和服务器保持同一个时间基准，Token 校验就正常了。
7.4 资源映射后图片 404 的问题
图片上传后配置了资源映射，但通过 URL 访问图片一直 404。排查后发现问题出在权限拦截器上。JWT 拦截器把我配置的 /upload/** 放行了，本来应该没问题，但前端访问图片时用的是带 Token 的路径，问题不在拦截器，而在浏览器端对图片请求根本不会自动携带 Authorization 请求头。
真正原因是图片资源路径被放在了没有权限校验的公开区域，而后端静态资源处理器返回的是二进制流，图片正常显示。如果一定要带鉴权头，则应该改成后端写一个文件下载接口，用 ResponseEntity<byte[]> 返回图片内容，这需要对每个图片请求都做一次 Token 校验。对于宠物平台这种前台图片访问量较大的项目，用 Nginx 直接映射静态目录是更合理的做法。如果这个项目还没到上云的地步，直接用公共上传路径映射即可，不用在图片下载上加太复杂的鉴权逻辑。
7.5 接口返回时间格式不一致
前端反馈后台的文章发布时间显示了一串数字，大概能猜到是时间被序列化成了时间戳。Spring Boot 默认的 ObjectMapper 会把 java.util.Date、LocalDateTime 按 ISO-8601 或时间戳输出，而前端用的是 Element UI 的表格格式化，两种格式对不上导致显示异常。
统一处理方式是在 application.yml 中做全局配置：
yaml复制spring:
jackson:
date-format: yyyy-MM-dd HH:mm:ss
time-zone: GMT+8
但是注意，这只对 java.util.Date 生效，对 LocalDateTime 并不完全生效。还需要在类上增加 @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") 注解。如果项目中有很多时间字段，建议封装一个 BaseEntity，公共字段直接包含 createTime、updateTime，并在这个字段上加上注解，所有业务实体继承它。
一些额外想说的实践心得
做这个项目的过程中，我最大的体会是：Spring Boot 管理系统看起来是“增量式”开发，模块不断加，接口不断堆，但如果前期数据库设计和通用层封装没做好，后期每加一个功能都会伴随一堆重复代码。比如我的 Result<T> 统一返回、全局异常处理器、BaseEntity 的公共字段，都是必须在一开始就规划好的基础结构，而不是等项目写了一半才回头补。
还有一点关于自学和毕设阶段的建议：不要把自己困在“把功能做出来”这个层面，也要去想想接口的幂等性、数据校验、缓存失效策略这些听起来比较高级的问题。你不需要全部实现，只要在回答“系统怎么设计的”时能说出一两个有深度的取舍，已经比大多数项目看起来靠谱得多。
如果后续要继续扩展，可以考虑给指南内容接入 HanLP 分词，在应用层做一个基于倒排索引的搜索服务；也可以把预约模块升级为基于状态机的流程引擎，让每一步操作都有迹可循。技术选型永远服从业务阶段，先把平台的核心链路跑通，再谈组件复杂化。希望这篇复盘能帮到正在折腾同类平台的人。