SpringBoot+Vue3+MyBatis+MySQL实战：保险合同管理系统设计与避坑指南

一个保险合同管理系统，看起来名字挺长，拆开看其实就是那套经典的 Java 技术栈组合：SpringBoot + Vue3 + MyBatis + MySQL。我在实际项目里把这套东西完整落地过，从数据库建模到后端接口，再到前端页面联调，踩过的坑和沉淀下来的经验还真不少。这篇就把整个系统的核心设计、关键代码逻辑，以及那些文档里不会写清楚的注意事项，一并和你聊聊。

先明确这个系统能做什么：它面向的是保险公司的业务管理人员，核心功能覆盖客户信息管理、保单录入与查询、缴费记录跟踪、理赔流程登记，以及围绕这些数据的统计报表。整个系统采用前后端分离架构，后端基于 SpringBoot 提供 RESTful API，前端用 Vue3 配合 Element Plus 搭建后台管理界面，数据层由 MyBatis 负责操作 MySQL。适合正在学习 Java 全栈开发的人作为参考项目，也适合需要快速搭建内部管理系统的团队直接作为基座改造使用。

1. 整体系统设计与业务模块拆解

1.1 保险合同业务的本质与系统目标

保险业务和一般进销存的差别很大。合同（保单）是一个带状态的生命周期对象：从投保人填写信息、核保通过、正式承保，到后续每一期的缴费、可能的批改、甚至是理赔和满期给付，中间会经历多个状态流转。所以数据库建模时不能只把它当成一个简单订单表来设计，必须给保单加上状态机字段，并且用缴费记录、理赔记录等子表来支撑整个生命周期。

我把系统核心拆成六大模块：

• 客户管理：记录投保人和被保险人的基本信息，包括证件类型、证件号码、联系方式、地址等。客户是先于保单存在的，先有客户，后有保单。
• 保单管理：系统最核心的模块。一个保单会关联客户、保险产品、保额、保费、生效日、终止日、当前状态（草稿/已核保/已承保/已退保/已满期）。
• 缴费管理：按保单生成缴费计划，每期包含应缴日期、应缴金额、实缴日期、实缴金额、缴费状态。缴费记录直接关联保单状态，欠费超过宽限期会导致保单失效。
• 理赔管理：记录理赔申请、理赔金额、审核状态。理赔申请的前提是该保单处于有效状态且在保险期间内。
• 产品管理：保险产品的定义，包括产品名称、类型（重疾/医疗/意外/寿险）、缴费期限、保障期限等。
• 系统管理：用户登录、角色权限、操作日志。后台管理系统必备的模块。

1.2 系统角色的权限隔离思路

权限设计我用了最简单的 RBAC 模型，用户-角色-菜单三级。角色主要分管理员和普通操作员两类：管理员可以查看全部数据、修改配置、导出报表；普通操作员只能处理自己录入的保单，查看权限也做了数据范围的限制。

这个系统没有把权限做得很复杂，因为对于内部管理系统来说，过度的权限精细化反而增加开发和维护成本。但有一点我一直坚持：操作日志必须记录。谁在什么时间给哪个保单做了批改，这笔缴费是谁操作的，这些在保险业务里有审计需求，不能省。

1.3 界面层与接口层如何协作

前端用 Vue3 实现单页应用，路由前置守卫做登录拦截，Axios 统一封装请求和响应拦截。后端接口全部以 /api 前缀暴露，由 Controller 层接收参数，Service 层处理业务逻辑，Mapper 层操作数据库。

前后端协作最关键的是接口文档和数据结构约定。我在项目里使用统一返回体 Result，包含 code、message、data 三个字段。分页查询返回 PageResult，包含 records、total、current、size 四个字段。这样前端拿数据的时候非常统一，不会有这个接口返回 data 数组、那个接口返回 rows 这种混乱情况。

2. 技术选型解析：为什么是 SpringBoot + Vue3 + MyBatis

2.1 SpringBoot：企业级开发的稳妥选择

后端框架这个选择几乎没有悬念。SpringBoot 已经成了 Java 企业级开发的事实标准，它解决了 Spring 框架配置繁琐的问题，内置 Tomcat，配合 Maven 或 Gradle 可以快速构建可独立运行的应用。

SpringBoot 的版本选择上需要注意，版本不是越新越好。我用的是 SpringBoot 2.7.x，理由很实际：这个版本稳定，且和主流生态兼容性好。如果选太高版本，比如 SpringBoot 3.x，它会强制要求 Java 17，而且很多第三方 starter 和配置类可能会有兼容性问题。具体到这个项目，MyBatis-Spring-Boot-Starter 2.x 在 SpringBoot 2.x 下是完美匹配的，不需要额外处理。

2.2 MyBatis 凭什么比 JPA 更合适

ORM 框架的选型上，我最终选择了 MyBatis 而不是 Spring Data JPA。原因主要是基于这个系统的实际需求：保险业务的 SQL 有大量动态条件和多表关联查询。

举个例子，保单的高级查询需要根据客户名称、身份证号、保单状态、产品类型、投保日期区间等多个条件动态拼接 SQL，MyBatis 的 <where> + <if> 标签处理这类场景非常自然。而 JPA 的动态查询需要 Specification 或者 QueryDSL，代码量不小，而且复杂的多表统计 SQL 用 JPA 写起来非常痛苦。

MyBatis 的另一个优点是 SQL 与代码分离，所有的 SQL 都集中在 XML 文件里，DBA 可以直接审查和调优 SQL，而不用去看 Java 代码。这一点在保险、金融这种对数据访问有严格把控要求的业务中非常重要。

2.3 前端为什么是 Vue3 而不是 Vue2

前端这块，我直接选了 Vue3 + Vite + Element Plus 的组合。Vue3 相比 Vue2 的好处是组合式 API 让代码逻辑更聚合，配合 Vite 的开发服务器启动速度非常快，实测下来比 Webpack 那套提升明显。

Element Plus 是 Element UI 的 Vue3 版本，后台管理系统的表格、表单、弹窗、分页这些组件全都现成，开发效率很高。虽然有人说 Element Plus 改版后样式有点变化，但整体稳定性和生态成熟度仍然是后台管理项目的首选。

组合式 API 对复杂业务页面的收益是实实在在的。比如保单详情页面，它同时涉及保单基本信息、客户信息、缴费记录列表、理赔记录列表，如果全部写在 data() 和 methods 里，代码会非常臃肿。用组合式 API 以后，我按业务区块封装成独立的 composable 函数，每个函数只负责一块逻辑，页面代码清晰很多。

2.4 前后端分离的边界划分

前后端分离的核心是数据契约的约定，本质上是把视图渲染和数据操作彻底解耦。在这个项目里，前端只负责页面渲染和用户交互，通过 HTTP 请求与后端通信，后端只输出 JSON 数据，不做任何页面跳转。

这种架构遇到的问题也很典型：跨域和 Token 认证。跨域用 SpringBoot 的 CORS 配置类解决，Token 认证使用拦截器统一校验请求头中的 Authorization 字段。还有一个团队协作层面的问题，前后端并行开发时，接口定义要提前定好，否则会出现前端等后端接口、后端等前端页面的互相等待。我的做法是先用接口文档工具定义好每个接口的出入参，然后前后端各自 mock 数据开发，联调阶段再把接口地址切换成真实地址。

3. 数据库设计：保险合同业务的核心表结构规划

3.1 客户表和保单表的设计细节

客户表是我坚持单独设计的第一张表，因为一个客户在保险业务中可能投保多张保单，如果每张保单都冗余客户信息，更新客户资料时就要同步修改多张表，很容易产生数据不一致。客户表的主键用自增的 customer_id，身份证号（id_card）设置唯一索引，这个是客户身份的唯一标识。

保单表是整个系统的核心，设计时的关键字段包括：政策编号 policy_no（业务编号，格式如 P20250110001）、客户ID、产品ID、保额 sum_insured、保费 premium_amount、保障起始日 start_date、保障终止日 end_date、缴费期限 payment_term、状态 status。policy_no 要与主键区分开，主键是内部使用，业务编号是对外展示的，我用时间戳加序列号生成。

状态字段我单独解释一下。保险保单的状态设计为：-1 已退保、0 草稿、1 已核保、2 已承保、3 已失效、4 已满期。这个状态机贯穿整个系统，比如只有已承保的保单才能发起理赔申请，只有有效状态的保单才能做批改操作。所有状态变更都通过 Service 层统一处理，不允许 SQL 直接改状态字段，这样能保证业务规则不会因为散落的更新语句而失控。

3.2 缴费计划和理赔明细的设计思路

缴费计划表（premium_plan）每期一条记录，包含所属保单 ID、期次 period_no、应缴日期 due_date、应缴金额 due_amount、实缴日期 paid_date、实缴金额 paid_amount、缴费状态 status（0 未缴、1 已缴、2 逾期）。这个表的生成逻辑是在保单承保时根据 payment_term 自动批量生成，比如一个缴费期限为 20 年的保单，承保时就生成 20 条缴费记录。

理赔表（claim_record）记录每次理赔申请，字段包括所属保单 ID、申请日期 claim_date、理赔金额 claim_amount、理赔原因 claim_reason、审核状态 audit_status（0 审核中、1 已通过、2 已拒绝）、审核备注 audit_remark。

这里有一个细节值得注意：理赔表里保存的保单ID、客户ID 都是逻辑外键，我没有在数据库层面加物理外键约束。原因是保险业务中如果客户被删除（逻辑删除）、保单被退保，物理外键会产生不必要的约束问题。通过应用层保证数据完整性，数据库层面只建索引不加外键，这是很多企业级项目的实践惯例。

3.3 MySQL 索引设计和排序的实战细节

MySQL 索引设计在保险这类数据量增长很快的业务里非常重要。我建索引的原则是：高频查询条件必须有索引，排序字段尽量加到索引里，索引数量控制在合理范围避免写放大。

保单表的索引设计我这样安排：status 单列索引（状态查询很频繁）、customer_id 单列索引（按客户查保单）、start_date + status 联合索引（按日期范围筛选时可命中索引）。这里还要特别注意 MySQL 的排序优化，如果用 ORDER BY create_time 排序，并且 create_time 不在索引里，MySQL 就不得不做 filesort，当数据量达到几十万行时性能会明显下降。所以我在保单表上加了一个 idx_status_create_time (status, create_time) 联合索引，这样 WHERE status = ? ORDER BY create_time DESC 这样的查询可以完全走索引，排序也不再需要额外操作。

MySQL 排序还有一个容易忽略的坑：如果排序字段是字符串类型，会按照字典序排列而不是数字大小。比如期次字段 period_no 如果用 VARCHAR 存第 1 期、第 2 期、第 10 期，直接 ORDER BY 会得到 1、10、2 的顺序，这种就得用数字类型或者做填充格式化。

4. 后端实现：SpringBoot + MyBatis 核心链路详解

4.1 项目结构分包与基础配置

后端项目的分包结构我建议这样组织：

code复制com.example.insurance
├── config          // 配置类：CORS、MyBatis、分页插件、拦截器
├── controller      // 接口层
├── service         // 业务层
│   └── impl        // 业务实现
├── mapper          // MyBatis Mapper接口
├── entity          // 实体类
├── dto             // 传输对象（入参、返回）
├── common          // 统一返回、异常处理器、工具类
└── interceptor     // 登录拦截器、审计日志拦截器

这种分包方式没有特别新潮，但是职责清晰，团队协作时不会出现代码互相找不到的情况。Controller 层只做参数接收和结果封装，不写业务逻辑；Service 层才是核心业务逻辑的所在地；Mapper 层只负责 SQL 操作，不做跨表关联判断。

基础配置方面，application.yml 里最核心的是数据源和 MyBatis 配置。放一个典型的配置示例：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/insurance_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver

mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.example.insurance.entity
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

map-underscore-to-camel-case: true 这个配置一定要开，它能把数据库的 customer_name 自动映射到实体类的 customerName 字段，少写很多没意义的映射代码。log-impl 我在开发阶段开着方便调试，生产环境会去掉。

4.2 MyBatis 动态 SQL 与一二级缓存实战

动态 SQL 是这个系统里出镜率最高的功能，因为后台管理页面几乎都是多条件组合查询。保单查询的典型场景：用户输入客户名称、选择状态、选择产品类型、选择投保日期区间，点击查询。这些条件任意组合，不能用固定 SQL 来实现。

MyBatis 的 <where> 标签配合 <if> 标签是最标准的写法：

xml复制<select id="selectPolicyList" resultType="com.example.insurance.entity.Policy">
    SELECT p.*, c.customer_name, c.id_card, pr.product_name
    FROM policy p
    LEFT JOIN customer c ON p.customer_id = c.customer_id
    LEFT JOIN product pr ON p.product_id = pr.product_id
    <where>
        <if test="customerName != null and customerName != ''">
            AND c.customer_name LIKE CONCAT('%', #{customerName}, '%')
        </if>
        <if test="status != null">
            AND p.status = #{status}
        </if>
        <if test="productId != null">
            AND p.product_id = #{productId}
        </if>
        <if test="startDate != null">
            AND p.start_date &gt;= #{startDate}
        </if>
        <if test="endDate != null">
            AND p.end_date &lt;= #{endDate}
        </if>
    </where>
    ORDER BY p.create_time DESC
</select>

<where> 标签会自动处理 AND 前缀，第一个条件前不会出现多余的 AND，这是 MyBatis 最常用的高级特性之一。

再谈 MyBatis 缓存。一级缓存是 SqlSession 级别的，同一个 SqlSession 内两次相同查询只发一次 SQL。这个特性在项目里实际上会造成过一次困扰：我在同一个事务里先查询了保单信息，然后更新了保单状态，接着再次查询同一个保单，没想到拿到的是缓存中的旧数据。解决办法有两个：一是更新操作后手动调用 sqlSession.clearCache()，二是把涉及缓存敏感数据的 Mapper 上的 <cache> 标签全部不启用，默认不开二级缓存。保险业务对数据实时性要求高，我最后选择了默认不启用二级缓存，每次查询都走 SQL。数据量在百万级别以下，加上索引优化，性能完全够用。

4.3 分页插件正确用法与配置细节

页面的保单列表查询，后端做分页是必须的。MyBatis 里最主流的分页插件是 PageHelper，使用起来非常简单，但有几个细节值得注意。

PageHelper 的引入只需要在 pom.xml 里加依赖，然后配置一个拦截器：

java复制@Configuration
public class MybatisConfig {
    @Bean
    public PaginationInterceptor paginationInterceptor() {
        PaginationInterceptor paginationInterceptor = new PaginationInterceptor();
        paginationInterceptor.setOverflow(false);
        paginationInterceptor.setLimit(500);
        return paginationInterceptor;
    }
}

代码中使用分页的标准写法是：

java复制PageHelper.startPage(pageNum, pageSize);
List<PolicyVO> list = policyMapper.selectPolicyList(queryDTO);
PageInfo<PolicyVO> pageInfo = new PageInfo<>(list);

这里有个非常重要的点：PageHelper.startPage() 后面必须紧跟第一个 Mapper 查询，中间不能夹任何其他 SQL 操作。如果用 PageHelper.startPage() 之后又先执行了别的 Mapper 的查询，分页会作用到那个错误的查询上。团队里有人就踩过这个坑，查询结果数量不对，排查了半天才发现是 startPage 和查询之间插入了一条日志查询。

PageHelper 做了分页拦截后，实际上会在原始 SQL 后面追加 LIMIT ?, ? 语句，并自动执行一条 COUNT 查询。这里要注意 COUNT 查询对复杂 SQL 来说开销不小，如果数据量大可以考虑关闭自动 COUNT，改为自己单独执行 COUNT 查询。

4.4 拦截器的两种落地方案：登录鉴权与审计日志

后端拦截器我实现了两种，都是通过 Spring MVC 的 HandlerInterceptor 实现的。

登录鉴权拦截器逻辑清晰：从请求头中取出 Token，调用 JWT 工具类解析，解析失败直接返回 401 状态码，不让请求进入 Controller。放行规则用 WebMvcConfigurer 注册时配置，登录接口本身不需要 Token，其余接口一律拦截。

java复制public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        if (StringUtils.isBlank(token) || !JwtUtil.verify(token)) {
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
        }
        // 将用户信息放入 ThreadLocal，方便 Controller 获取当前用户
        Long userId = JwtUtil.getUserId(token);
        UserContext.set(userId);
        return true;
    }
}

审计日志拦截器用的是 MyBatis 拦截器（Interceptor）。我写了一个基于 MyBatis 核心接口的拦截器，拦截所有的 UPDATE 和 DELETE 操作，在执行之前获取 SQL 和参数，然后异步写入日志表。这个功能在保险业务中很重要，比如退保操作、保单批改、理赔审核都属于敏感操作，必须留痕。MyBatis 的拦截器机制是走动态代理，拦截 Executor 接口的 update 方法，取到 MappedStatement 的 ID 和参数就可以分析出是什么操作。

4.5 事务与并发控制：缴费操作的原子性保证

保险系统的缴费模块有一个典型的并发安全问题：同一张保单的同一期缴费记录，如果两个操作员同时点击“确认缴费”，会不会出现一笔缴费重复入账的情况？

我用两种方式来解决。第一种是数据库层面控制，对缴费记录使用乐观锁：premium_plan 表里加一个 version 字段，UPDATE 语句带上 WHERE version = #{oldVersion}，更新成功后 version 自增。如果两条请求同时读取了 version=1 的记录，只有第一条能把 version 更新成 2，第二条 update 影响行数为 0，说明冲突，直接返回“请刷新后重试”。

第二种是事务层面控制，在 Service 层的缴费方法上加上 @Transactional，保证缴费记录的更新和保单状态的更新要么同时成功，要么同时回滚。这里要注意事务的隔离级别，MySQL 默认的可重复读在这个场景下已经足够，不需要额外调整。

还有一个细节值得说明：@Transactional 注解默认只回滚 RuntimeException 和 Error，如果业务代码中抛出的是受检异常（checked exception），需要显式设置 rollbackFor。我习惯统一使用 rollbackFor = Exception.class，避免这种问题。

5. 前端实现：Vue3 后台管理系统的搭建过程

5.1 项目初始化与组合式 API 的组织方式

前端项目初始化用 Vite 的官方脚手架：

bash复制npm create vite@latest insurance-admin -- --template vue
npm install vue-router@4 pinia axios element-plus

组合式 API 的核心是 setup 语法糖。以保单列表页面为例，我把逻辑拆成三块：查询表单的状态和查询方法、表格数据的加载与分页、操作按钮的逻辑（新增、编辑、查看详情、删除）。每块用 ref / reactive 管理响应式状态，最后在 onMounted 中加载第一页数据。

一个关键的组织原则是：如果页面逻辑复杂，可以抽成独立的 composable 函数。比如 usePolicyList 如果被多个页面复用（保单列表、我的客户保单列表），就可以拆成 src/composables/usePolicyList.js。这样能做到逻辑复用，而不是每个页面都复制粘贴一遍查询代码。

5.2 路由守卫与权限控制的联动实现

前端的权限控制和后端不同，它主要做的是视图层控制：未登录用户跳转登录页、没有权限的用户不显示对应菜单、接口返回 401 时自动跳转登录。

路由守卫我用 Vue Router 的前置守卫实现：

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

菜单权限这块，我实现的是最简单的方案：用户登录时后端返回该用户的角色，前端根据角色决定是否渲染某个菜单项。比如只有 admin 角色能进系统管理模块，普通操作员角色不显示系统管理的菜单入口。真正的数据级权限校验还是靠后端接口保证，前端隐藏菜单只是体验层面的优化，不是安全手段。

5.3 Axios 封装与接口联调

Axios 我使用统一封装方式，主要做了三件事：请求拦截器加上 Token 头、响应拦截器统一处理业务错误码和 HTTP 状态码、封装了 get/post 请求方法。

javascript复制import axios from 'axios';
import { ElMessage } from 'element-plus';

const request = axios.create({
    baseURL: '/api',
    timeout: 10000
});

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

request.interceptors.response.use(
    response => {
        const res = response.data;
        if (res.code !== 200) {
            ElMessage.error(res.message);
            return Promise.reject(new Error(res.message));
        }
        return res.data;
    },
    error => {
        if (error.response && error.response.status === 401) {
            localStorage.removeItem('token');
            window.location.href = '/login';
        } else {
            ElMessage.error(error.message || '请求失败');
        }
        return Promise.reject(error);
    }
);

有一个开发细节：联调阶段避免跨域问题，我使用 Vite 的 devServer proxy 把 /api 开头的请求代理到 localhost:8080，这样浏览器访问的是同源地址，后端那个 CORS 配置类甚至都可以不用配了。

Vite 的代理配置在 vite.config.js 中：

javascript复制export default defineConfig({
    server: {
        proxy: {
            '/api': {
                target: 'http://localhost:8080',
                changeOrigin: true
            }
        }
    }
});

5.4 Element Plus 表格和表单的性能优化

后台管理系统大量使用表格组件，Element Plus 的 el-table 数据量小的时候流畅，一旦数据量上千就需要注意性能优化。我的经验是：

不要一次性渲染全量数据，用后端分页控制，每页 10-20 条数据是合理的。如果确实需要展示大量数据，用虚拟滚动。el-table 的 v-loading 指令配合 loading 状态变量，避免用户在接口返回前看到空白或者旧数据。还有 column 的设置，尽量用固定的 width 而不是自适应宽度，不然表格列宽重算也会有性能开销。

表单校验我用 Element Plus 的 el-form 的 rules 属性，写好每个字段的校验规则后，可以省去大量手动判断代码。特别说一个小技巧：电话、身份证号这些有格式要求的字段，除了必填和非空校验，还可以用正则表达式校验格式，身份证号的 18 位格式是最基础的校验。

6. 常见问题排查与避坑实录

6.1 SpringBoot 版本太高的兼容性问题

很多刚开始学的人喜欢直接下载 Spring Initializr 最新版，结果引入 MyBatis 的 starter 之后发现各种配置不生效。这个问题的根源在 SpringBoot 3.x 开始使用 Jakarta EE 规范，javax.* 包全部改成了 jakarta.*，很多老版本的 starter 根本没有适配。

像我前面说的，目前阶段建议使用 SpringBoot 2.7.x + Java 8 的组合。如果需要使用 SpringBoot 3.x，那么 MyBatis-Spring-Boot-Starter 必须使用 3.x 版本，同时注意 Java 版本必须 17 及以上。这些信息在引入依赖之前一定要先确认清楚，否则会浪费很多时间在环境兼容性上。

6.2 MyBatis 缓存导致的数据不一致处理

前面提到过 MyBatis 一级缓存造成的脏读问题，处理方法有两个层面：第一个是 SqlSession 隔离级别的层面，Spring 管理的 Mapper 默认每个数据库操作使用独立的 SqlSession，所以一级缓存基本不会跨操作生效。但如果同一个 Service 方法里有查询-更新-再查询的操作序列，一级缓存真的可能导致拿到旧数据。

第二个层面是二级缓存，我直接不启用。对于保险合同系统这种数据实时性要求高的业务，缓存带来性能提升的同时也带来了数据一致性的风险，权衡下来性价比不高。如果确实有性能瓶颈，建议在 Redis 层做可控的缓存策略，并且设置合理的过期时间，而不是用 MyBatis 的二级缓存。

6.3 @Update 执行慢和 MySQL 排序的问题定位

在使用 MyBatis 写 @Update 注解时，如果发现执行特别慢，我建议按这样的顺序排查：先看 SQL 条件字段有没有索引，再看有没有行锁等待，最后用 EXPLAIN 分析执行计划。我遇到过 @Update 执行慢的情况，最后定位到问题是 UPDATE 条件里的关联字段没有索引，导致全表扫描。加上索引后从秒级降到了毫秒级。

MySQL 排序字段的坑前面提过，这里补充一个实际案例：保单列表页按 premium_amount 排序，这个字段是 DECIMAL(10,2) 类型，不存在字符串排序问题。但如果把保费金额设计成 VARCHAR，就会出现 99.5 排在 1000 后面的情况。所有涉及数值排序的字段，数据库类型一定要用数值类型而不是字符串类型。

6.4 Vue3 + TypeScript 报错的常见原因

Vue3 项目中引入 TypeScript 后，最常见的报错是找不到模块声明。Element Plus 的类型定义要正常使用，需要在 tsconfig.json 中配置 "types": ["element-plus/global"]。还有一种报错是 ref 类型的自动解包问题，使用 ref<T>(null) 时会推导成 Ref<T | null>，访问 xxx.value 时可能报类型错误，通常的解决方法是显式指定泛型类型。

如果不想用 TypeScript，直接用 JavaScript 写 Vue3 也可以，小团队内部工具类的项目用 JS 开发效率更高，减少类型层面的纠结。

6.5 报表对接场景的扩展说明

保险合同管理系统往往需要输出各种报表，比如保单清单、保费收入统计、理赔汇总等。有一部分需求需要集成专业的报表工具来生成和打印单据。这类场景的集成思路通常是：后端生成对应格式的数据源，交给报表引擎模板渲染，服务端对接时要注意分页和大数据量内存溢出的问题，可以分批生成或使用临时文件的方式。前端预览则一般通过报表工具提供的前端组件或 iframe 嵌入实现。

7. 部署上线与常见注意事项

7.1 环境变量和配置文件分离

项目开发完成后要部署到测试环境、生产环境，不同环境的数据库地址、账号密码肯定不一样。我习惯用 SpringBoot 的多 profile 机制来管理：application-dev.yml、application-prod.yml，启动时通过 --spring.profiles.active=prod 指定使用哪个环境的配置。敏感信息比如数据库密码，不放在配置文件里提交到 Git，而通过环境变量注入。

7.2 构建打包的几个小细节

前端构建用 npm run build 生成 dist 目录，部署时可以放在 Nginx 里，并把 /api 路径反向代理到后端服务。后端打包用 mvn clean package -DskipTests 生成可执行的 jar 包，启动命令加上 -Xms256m -Xmx512m 设置 JVM 初始内存和最大内存。

这里有一个实际经验：前后端分离项目的跨域配置，如果在 Nginx 层面已经做了反向代理，后端 Java 代码里就不需要再配 CORS，否则会出现重复的跨域头导致浏览器报错。反之，如果前端开发时用的是 Vite 代理，后端也不需要 CORS 配置。跨域问题要在架构层面理清楚，谁是同源访问、谁是跨域访问，配置一次就好，不要多配。

7.3 上线前的数据备份与安全建议

保险业务数据的重要性不言而喻。上线前建议配置好 MySQL 的定期备份任务，至少每天凌晨一次全量备份，使用 mysqldump 命令即可。连接数据库的账号不要用 root，单独创建业务账号，只授予该数据库的必要权限。前端接口可以考虑在网关层做请求频率限制，防止恶意刷接口。管理后台的登录页可以加入简单的验证码校验，虽然不复杂但对暴力破解有一定防御作用。

做了快十年的 Java 开发，回头看这类管理系统，技术上其实没有太多神秘的东西。真正难的是把业务规则理清楚，把容易出错的地方通过合理的架构和编码习惯防住。如果你正准备上手一套 SpringBoot + Vue3 的前后端分离项目，我建议不要只盯着增删改查的代码怎么写，把数据建模、状态流转、权限边界和事务一致性这些设计层面的东西想明白，收获会更大。