企业官网建设流程全解析

每年到毕设季，总有人来问我：想做基于SpringBoot的宠物投保系统，该从哪里入手？说实话，这个选题挺聪明。宠物保险这两年热度涨得快，业务链路又足够清晰——产品上架、宠物建档、在线投保、支付出单、理赔处理，一整套流程走下来，SpringBoot后端该练的技术点基本都覆盖了。而且作为毕业设计，它能讲的故事也多：既有权限管理，又有订单状态流转，还有支付回调这种偏工程化的细节，答辩时完全不愁没东西讲。

这篇文章我就以实际开发这个系统时的完整思路为主线，把项目整体拆解、数据库设计、核心功能实现，还有我踩过的那些坑，一次性讲透。不管你是正在准备毕业设计，还是想自己做个能写进简历的SpringBoot实战项目，照着这个框架搭准没错。

1. 项目整体设计与技术选型思路

1.1 为什么把后端框架定在SpringBoot上

先聊一个最基础的问题：做宠物投保系统，为什么选SpringBoot而不是传统的SSM，或者干脆用其他语言框架？

我的理由很直接。SpringBoot对中小型项目来说，开发效率是碾压级的。传统SSM要手动配一堆XML，数据源、事务、MyBatis映射、视图解析器，每一样都得自己折腾，光环境搭建就能劝退不少人。SpringBoot把这些东西全部自动配置掉了，起步依赖一拉，一个注解就能跑起来内嵌Tomcat，真正做到了开箱即用。

对一个宠物投保系统来说，核心诉求是快速把业务逻辑落地，而不是在配置上耗时间。SpringBoot的自动配置、Starter生态、Actuator健康检查、统一异常处理，这些特性都能让你的开发节奏快一大截。而且生态成熟，MyBatis-Plus、Redis、JWT相关库都有非常成熟的集成方案，社区资料多，遇到问题随便一搜就有答案，对毕设党尤其友好。

这个系统本身属于典型的业务管理系统，没有特别复杂的分布式诉求，单体应用完全够用。你非要上微服务架构，反而会增加服务拆分、服务调用、数据一致性这些不必要的复杂度，最后把自己绕进去。先把单体做好，比什么都强。

1.2 业务模块拆解与功能边界划分

拿“萌宠保障在线投保系统”来说，业务上可以拆成两个视角：用户视角和管理员视角，中间通过订单和保单串起来。

用户端的核心链路是：注册登录 → 添加宠物档案 → 浏览保险产品 → 发起投保（选择产品、选择宠物） → 试算保费 → 创建订单 → 在线支付 → 系统生成保单 → 保障期间内发起理赔 → 理赔审核。

管理员端的核心链路是：维护保险产品（上下架、调价） → 审核理赔申请 → 查看平台订单和保单数据 → 统计报表。

把链路理清楚之后，后端模块就比较好划分了。我建议按下面这六个模块来做，边界清晰，也方便并行开发：

• 用户认证与权限模块：登录注册、JWT签发与校验、管理员权限控制
• 宠物档案模块：宠物信息增删改查，包括品种、年龄、体重、疫苗接种情况等影响保费计算的信息
• 保险产品模块：产品CRUD、上下架、产品详情，产品表设计时要预留扩展字段，方便后续加不同类型保险
• 投保与订单模块：投保下单、订单状态管理、支付回调处理，这是整个系统最核心、也是逻辑最复杂的模块
• 保单管理模块：支付成功后自动生成保单，支持按用户查询、按时间范围筛选、保单详情查看
• 理赔模块：理赔申请、材料上传、管理员审核流转

模块之间尽量不要互相调用业务方法，而是通过Service层暴露能力。比如订单模块需要查产品信息时，调用ProductService的方法而不是直接操作ProductMapper，这样后期改产品表结构时，影响范围能控制在产品模块内部。

1.3 技术栈与版本搭配建议

技术栈这一块，我直接给出一套经过验证的搭配方案，都是我自己实际用过的，直接“抄作业”没问题：

版本这里多说两句。SpringBoot 3.x虽然已经成熟，但它要求JDK17起步，很多学校的实验室电脑、或者你本地旧项目里的JDK1.8环境，直接升级会有一堆兼容问题。我建议稳一手，选2.7.18。这个版本是2.x系列的最终维护版本，安全补丁齐全，网上资料也最多，遇到问题基本都能搜到解决方案。

前端的选择上，如果你更想突出后端能力，选Thymeleaf服务端渲染会省很多事，不用考虑CORS、Token存储这些。但如果你想显得项目更“现代”，答辩时前端界面更漂亮，那就用Vue3 + Element Plus做前后端分离。我后面写的核心逻辑两种前端方式都兼容，因为接口设计是标准RESTful风格的。

2. 核心数据模型与业务规则设计

2.1 核心数据表怎么设计

数据库设计是整个系统的地基，表结构不科学，后面写代码就处处别扭。我做这个宠物投保系统时，核心表就六张，每一张都有明确的职责。

用户表（user），存账号、密码（BCrypt加密）、手机号、角色标识。角色字段用tinyint就够了，比如0代表普通用户，1代表管理员。不要把角色做成单独的表，毕设阶段的系统角色就两种，做多表反而增加联查复杂度。

宠物档案表（pet）是宠物保险业务特有的核心表，字段设计直接关系到后续保费计算，所以要多花心思。用户ID、宠物昵称、品种、出生日期或年龄、体重、是否绝育、疫苗接种状态、既往病史备注，这些字段都有用。特别是品种和年龄，它们是保费系数计算的主要依据，后面我会详细讲。

保险产品表（insurance_product）的设计很容易被忽视，很多同学就放个产品名和价格就完事了，这是不对的。宠物保险的产品往往不是一口价，而是有保障额度、免赔额、赔付比例、保障期限这些属性。产品表至少要包含：产品名称、产品类型（意外险/医疗险/综合险）、基础保费、保额、保障期限、产品状态（上架/下架）、封面图URL。后面动态算价时，还需要一组系数字段或者一个单独的产品系数表。

订单表（insure_order）是整个系统的核心，字段一定要冗余一些。订单号（全局唯一）、用户ID、产品ID、宠物ID、应付金额、订单状态、支付时间、创建时间。为什么要把用户ID、产品ID、宠物ID都冗余进来？因为订单列表页、详情页展示时需要频繁关联查询，如果当时只存了产品快照，后面产品改价或者下架了，你依然能从订单里拿到用户下单时的完整信息。

保单表（policy）由订单支付成功触发生成，保单号、订单ID、用户ID、宠物ID、产品ID、生效日期、到期日期、保额、保单状态。特别注意生效日期和到期日期的计算，很多同学直接支付成功当天作生效日，但保险产品通常有等待期概念（比如医疗险等待期7天），这个要根据产品属性配置。

理赔表（claim）记录理赔申请，关联保单ID、用户ID、申请理赔金额、理赔事由、凭证图片URL列表、审核状态、审核意见、审核时间。

六张表的关联关系不复杂，但外键我建议都别加，Java开发规范里也不推荐物理外键，用逻辑关联就够了。理由很简单：外键会影响插入更新性能，而且系统后期分库分表时会变成包袱。只要在Mapper查询时手动控制好关联关系就行。

2.2 订单与保单的状态机设计

宠物投保系统里最容易写乱的就是状态管理，尤其是订单和保单这俩。我的经验是：在建表之前，先把状态流转图画清楚，写代码时严格按状态机来控制。

订单状态我用枚举类管理，值存数据库是tinyint，1到5五个数字，对应枚举：待支付、已取消、已支付、已退款、已关闭。流转关系是：用户创建订单后是待支付状态；用户主动取消或者超时未支付，订单变为已取消；支付成功回调后变为已支付；已支付的订单发生售后退款时变为已退款。这里有个细节：已支付和已关闭要区分开。已支付是支付成功等待出单，已关闭是系统风控或者用户主动关闭但未支付，状态语义不能混。

保单状态相对简单：待生效、保障中、已到期、理赔中、已结案。订单支付成功后先生成待生效保单，过了等待期后（或者生效日当天，看产品规则）变保障中，保障期结束变已到期。用户发起理赔后，正在保障中的保单可以变理赔中，理赔结案后恢复保障中，除非理赔金额达到了保额上限，这种情况保单直接终态。

为什么要搞这么细？因为财务结算和统计报表全部依赖状态字段。如果同一张表的同一个状态字段一会儿表示“支付成功”，一会儿表示“已发货”，那后面写统计SQL、写对账逻辑时绝对会让你崩溃。我在项目里用了MyBatis-Plus的枚举类型处理器，Java枚举与数据库tinyint自动映射，代码里永远写枚举名，不会出现魔法数字到处飘的情况。

2.3 保费试算规则与实现方式

保费试算是宠物保险系统里最有业务特色的功能，也是答辩时最容易被提问的点。它不能简单做成一个固定价格乘积，而是要体现不同宠物个体之间的价格差异。

我采用的试算模型是：最终保费 = 基础保费 × 品种系数 × 年龄系数 × 健康系数。

基础保费由产品定义，比如某个综合险产品基础保费是300元。品种系数按照宠物的饲养风险设定，比如中华田园猫风险低，系数0.9；英短、美短这些常见品种系数1.0；一些容易得遗传病的品种系数1.2到1.5。年龄系数体现幼宠和老年宠的高风险特性，1岁以下的幼宠系数1.2，1到7岁的壮年宠物系数0.9，7岁以上的老年宠物系数1.5。健康系数则看疫苗接种状态和既往病史，疫苗齐全且无病史的系数0.9，有慢性病史的系数直接上1.5。

试算逻辑一定要放在Service层，不要写进SQL，也不要在前端算。因为保费是核心业务规则，必须后端控制，前端展示的只是试算结果，最终的实付金额以后端计算为准。我封了一个PremiumCalculator组件，输入产品、宠物信息，返回计算明细，包括每一项系数和最终金额，这样前端展示时能把试算过程详细列出来，用户感知也很专业。

至于为什么用乘法而不是加法，是因为系数之间是联动关系而非累加关系。一只品种系数1.2且有既往病史的老年猫，风险应该是成倍增长的，加法体现不出这种风险叠加效果，乘法模型更符合保险精算的基本逻辑。这块你在答辩时如果能把这个设计理由讲清楚，会是一个明显的加分项。

3. 核心功能实现：从登录到理赔全流程

3.1 登录认证与JWT拦截器落地

认证方案我选了JWT，因为它是无状态的，天然适合前后端分离部署。用户在登录接口提交用户名密码，服务端验证成功后用密钥签发一个Token，Token里携带userId和role信息，返回给前端。前端调用需要登录的接口时，在Header里带Authorization: Bearer ，后端通过拦截器统一校验。

拦截器实现上，我直接实现HandlerInterceptor接口，在preHandle里取Header中的Token，解析校验，通过后把用户信息放进ThreadLocal。这里有个很重要的坑：一定要放行登录接口、产品列表接口、以及预检请求OPTIONS，否则前端还没登录就被拦截器拦住了。

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行跨域预检请求 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); } try { Claims claims = JwtUtil.parseToken(token); UserContext.set(claims.get("userId", Long.class), claims.get("role", Integer.class)); return true; } catch (Exception e) { response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"登录状态已过期\"}"); return false; } } }

注册拦截器时，用addPathPatterns指定要拦截的路径，用excludePathPatterns放行公共接口。我实际在项目里是这样配的：拦截/api/**，放行/api/auth/login、/api/products/list以及静态资源路径。如果你用了Swagger接口文档，记得也要把swagger相关的路径放行，不然调试接口时天天被401挡住。

Token有效期建议设置两小时，同时配合Redis做二次校验。这样如果用户被管理员强制下线，只要在Redis里删掉对应的key，Token立即失效，解决JWT无法主动失效的问题。这个方案在毕设里用上，会显得很专业。

3.2 在线投保下单的完整事务链路

投保下单是系统里最核心的操作，流程长、涉及表多，我建议把下单和支付拆成两个接口，先创建订单，再发起支付。

创建订单接口接收一个JSON体，包含productId、petId。后端做了四件事：校验产品是否上架；校验宠物是否属于当前登录用户（这个校验太容易被漏掉了，如果不做，别人把宠物ID传进去就能用你的账号给别人的宠物投保）；调用保费试算组件计算金额并重新获取最新产品信息；生成订单号并插入订单表，状态设为待支付。

订单号生成有一个很常见的坑：直接用自增ID做主键暴露给前端，很容易被爬虫遍历。我的做法是用时间戳加随机数：yyyyMMddHHmmss + 4位随机数，生成20位的订单号。虽然并发量大了会有重复概率，但毕设阶段完全够用。想更稳一点可以引入雪花算法，MyBatis-Plus里内置了AssignedId生成器，配一下就能用。

整个下单过程必须加事务控制，因为涉及产品状态校验、订单创建、还有可选的优惠券核销，任何一步失败都不能留下脏数据。我在Service实现方法上直接加@Transactional(rollbackFor = Exception.class)，注意这里一定要指定rollbackFor，因为Spring默认只在RuntimeException时回滚，你抛一个业务异常如果继承的是Exception，事务不会回滚，这个坑我后面会专门讲。

3.3 支付回调与保单生成的幂等处理

支付环节是最考验工程经验的地方。真实对接支付宝或微信支付时，支付结果是通过异步回调通知服务端的，回调接口有两大特点：可能重复调用，必须做幂等；调用方在公网，必须验签。

我在项目里实现了模拟支付网关，本地联调时直接回调一个测试地址，模拟成功和失败两种场景。生成保单的核心逻辑写在回调处理接口里，第一步是查订单，如果订单状态已不是待支付，直接返回成功——这是幂等的关键。因为正常情况下，一笔订单只能从待支付流转到已支付，如果回调重复来了，订单状态已经是已支付了，再走一遍会对账不平。

@Transactional(rollbackFor = Exception.class) public void handlePayCallback(String orderNo, String tradeNo, BigDecimal amount) { InsureOrder order = orderMapper.selectByOrderNo(orderNo); // 幂等判断：非待支付状态直接返回 if (order == null || !OrderStatus.WAIT_PAY.equals(order.getStatus())) { return; } order.setStatus(OrderStatus.PAID.getCode()); order.setPayTime(LocalDateTime.now()); order.setTradeNo(tradeNo); orderMapper.updateById(order); // 生成保单 Policy policy = new Policy(); String policyNo = "P" + System.currentTimeMillis(); policy.setPolicyNo(policyNo); policy.setOrderId(order.getId()); policy.setUserId(order.getUserId()); policy.setProductId(order.getProductId()); policy.setPetId(order.getPetId()); // 生效日期和到期日期计算 policy.setStartDate(LocalDate.now().plusDays(product.getWaitingDays())); policy.setEndDate(policy.getStartDate().plusMonths(product.getCoverageMonths())); policy.setStatus(PolicyStatus.PENDING.getCode()); policyMapper.insert(policy); }

这里我再提醒一个细节：回调处理里的事务要尽量短，查询订单状态、更新订单、插入保单，三步做完就提交事务。不要在事务里调用远程接口，也不要发什么通知消息，这些都可以等事务提交后再做。因为事务越长，锁持有的时间越久，高并发下死锁的概率就越大。

3.4 理赔申请与审核流程设计

理赔模块是宠物投保系统里最能体现完整度的地方，也是很多同学容易做得虎头蛇尾的地方。

用户侧理赔申请书比较简单：选择一张保障中的保单、填写理赔金额、填写事故经过描述、上传证明材料图片。后端用一个ClaimController接收参数，文件上传接口单独拆出来，用MultipartFile接收，存到本地指定目录或者MinIO对象存储。文件名不能用用户原始文件名，要UUID重命名，否则两个用户都传一张2024.jpg，第二个就会把第一个覆盖掉。同时要做文件类型校验和大小限制，只允许jpg、png、pdf，单个文件不超过5MB。我实际见过有人把文件上传目录设在项目根路径下，结果暴露了配置文件，非常危险，一定要把上传目录放到应用外部，通过配置项指定。

管理员侧的审核是状态流转的关键一环。管理员查看待审核理赔列表，点进详情能看用户填写的理赔说明和凭证图片，选择通过或者驳回，驳回时填写审核意见。审核通过后，理赔单状态更新为已通过，保单状态视情况更新为已结案或者维持保障中。如果理赔金额达到保额，保单直接终态。

整个理赔流程的状态流转我用一个枚举类控制：待审核、审核通过、已打款、已驳回、已取消。用户可以在审核前主动取消理赔申请，这个业务场景经常被忽略，但实际使用中很常见，用户传错了材料想重新申请，如果系统不支持取消，体验就很差。

4. 开发实战中的常见坑与排查手册

4.1 SpringBoot版本选择：2.7.x还是3.x

版本问题我在前面提过，这里专门展开说。很多人在创建项目时喜欢追新，直接选SpringBoot 3.5.x，结果发现自己电脑上还是JDK8，或者用了很多基于JDK8的第三方库，项目死活起不来。

SpringBoot 2.7.x要求JDK8或以上，SpringBoot 3.x强制要求JDK17。如果你用的是IDEA自带的Spring Initializr，默认给的SpringBoot版本可能是3.x，这时候如果你的机器没装JDK17，项目就会启动失败，还报一些看起来很奇怪的错误。所以创建项目第一步，先确认本地JDK版本，再选择对应的SpringBoot版本。

还有一个兼容性问题是Swagger。很多教程用的是springfox的2.9.2，这个库对SpringBoot 2.6以上版本会直接启动报错，因为SpringMVC路径匹配策略从AntPathMatcher改成了PathPatternMatcher。解决方案有两个：要么把SpringBoot版本降到2.5，要么换成springdoc-openapi。我更推荐直接换springdoc，它原生支持OpenAPI3，界面比Swagger2还好看。

4.2 MyBatis-Plus分页插件不生效

宠物后台管理列表、订单列表、理赔列表都需要分页，MyBatis-Plus的分页插件是我用得最多的组件之一。但很多新手发现，自己按教程配置了分页，也调用了selectPage方法，返回的total就是不对，SQL日志里也没有LIMIT语句。

原因几乎都是同一个：忘了注册PaginationInnerInterceptor。MyBatis-Plus的分页插件不是默认开启的，必须显式配置分页拦截器才能生效。

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

配置完这个，selectPage方法才会在查询前自动拼接LIMIT。还有一个更隐蔽的坑：如果你在Mapper里写的是自定义SQL，比如联表查询，分页条件不会自动拼上去。MyBatis-Plus的分页插件支持自动在自定义SQL后面追加LIMIT，条件是自定义SQL必须先用Page参数接收，并且SQL里不要自己写分页语句。多表联查的分页，建议在Service层先分页查出主表记录ID，再用ID去联查，既能走索引又不会出现分页数据错乱的意外。

4.3 前后端联调中的跨域与时间格式问题

如果你选的是Vue3 + SpringBoot前后端分离架构，跨域问题绝对躲不掉。前端地址是localhost:5173，后端是localhost:8080，浏览器默认禁止跨域请求。解决方案是后端配置CORS过滤器，而不是在前端配代理。因为答辩时可能需要直接用手机访问后端接口，前端代理在手机上是不生效的。

配置CORS有一个特别容易踩的坑：一定要放行OPTIONS预检请求。浏览器在发送真正的POST请求前，会先发一个OPTIONS请求询问服务器允不允许跨域，如果拦截器直接拦截了OPTIONS，前端会一直报CORS error，而且浏览器控制台报错信息还特别隐晦。

时间格式问题也值得注意。SpringBoot默认用Jackson序列化LocalDateTime，序列化结果是数组格式，比如[2025,6,1,14,30,0]，前端拿到的JSON完全没法直接使用。我是在application.yml里统一配置了时间格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这里顺便提一句时区问题。如果服务器部署在海外或者Docker容器里默认是UTC时区，数据库存的时间和你页面展示的时间会差8个小时。解决方法是JVM启动参数加-Duser.timezone=GMT+8，或者Docker Compose里配置TZ=Asia/Shanghai，这个坑我是在系统上线测试时被测试的同学提的bug，印象特别深。

4.4 @Transactional 失效的几种真实场景

事务问题属于老生常谈，但我还是要重点讲，因为这个系统里凡是涉及订单、保单、理赔的操作，全都要靠事务保证一致性，一旦事务悄悄失效，数据就乱了。

第一种失效场景是方法被同类调用。我在开发理赔取消功能时踩过一次：ClaimServiceImpl里有一个方法a调用了同类里的方法b，b加了@Transactional注解，结果b内部抛异常，之前插入的数据没有回滚。原因是Spring事务基于AOP代理，同类内部的this调用走的是原始对象而不是代理对象，事务注解直接被无视了。解决方案有三个：把b拆到另一个Service里；或者注入ApplicationContext然后从容器里拿代理对象；或者在类里面注入自己的代理。最优雅的还是拆Service，职责本身也更清晰。

第二种失效场景是异常被吞了。事务方法里try-catch捕获了异常但没有往外抛，Spring看到方法正常返回，自然就不会回滚。我自己的习惯是：事务方法里尽量不捕获异常，让异常自然往上抛；如果确实需要在事务方法里处理异常，记得catch之后重新throw new RuntimeException。

第三种失效场景是数据库表引擎不支持事务。MySQL里如果表用的是MyISAM引擎，@Transactional是不生效的。建表时一定要确保用InnoDB引擎，这个可以写进SQL建表语句里，或者在my.cnf里把default-storage-engine设为InnoDB。判断方法也很简单，执行show table status，看每个表的Engine字段。

最后分享一个我自己的小经验。整个宠物投保系统做完，我自己最大的收获不是SpringBoot的语法，而是“先想清楚状态流转再动手编码”这件事。订单有订单的状态机，保单有保单的状态机，理赔有理赔的状态机，这三个状态机一旦设计清楚，整个系统的代码结构会自然变得清晰很多。后面我再看网上各种开源项目，第一件事就是看它们的枚举和状态流转逻辑，这个习惯我一直保留到现在。如果你也准备做这类业务管理系统，建议也从状态设计入手，这比多写几个接口实用得多。