做这套城乡居民基本医疗信息管理系统的时候，说实话最大感触是：业务本身不算复杂，难的是把SSM时代的那套老思路彻底掰过来，同时还要兼顾乡镇卫生院这种场景下的真实使用习惯。项目用的是SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0的组合，前后端分离，源码带完整文档。这篇文章不打算做那种目录式的功能介绍，而是把我在开发过程中踩过的坑、反复纠结过的技术选型、以及真正落地的业务设计思路都梳理一遍，给准备拿Java Web做毕设或者接类似外包项目的朋友一个参考。

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

1.1 为什么是这个技术组合

选定这四样技术栈，并不是因为它们各自多新潮，而是它们在“Java Web医疗信息管理系统”这个具体场景下能形成一套低内耗的组合。

先说SpringBoot2。核心目标是快速落地、减少配置负担。医疗卫生类系统需求变化非常频繁——今天加一个体检字段，明天补一个报销比例参数，后天又要调菜单权限。如果继续用传统的Spring MVC + XML配置，每改动一次都要重启、排查配置、处理各种Bean定义，开发节奏会被拖垮。SpringBoot2的自动配置机制极大缩短了这个反馈回路，依赖管理、内嵌Tomcat、健康检查、统一配置项，开发者能专心写业务代码而不是折腾环境。这里不选SpringBoot3，是因为当时很多依赖（尤其是部分MyBatis-Plus版本和旧版网关注册组件）在3.x上还没有完全稳定过渡，而2.7.x版本处于最成熟的维护期，兼容性风险最低。

再说Vue3。管理端界面里面大量的表单、弹窗、标签页切换、动态表格操作，Vue3的Composition API让代码组织更清晰。比如处理居民参保信息录入的时候，同一份表单既要在新增时用、又要在编辑时复用，用Composition API把逻辑抽成useForm钩子，比Options API里 mixin 混杂要清爽得多。同时Vue3搭配Vite开发服务器，热更新速度比Vue2 + Webpack时代快了不止一个级别，调试表格组件和权限指令时反馈很快。

MyBatis-Plus是数据库操作层的核心。它最大的价值不是免写SQL，而是允许开发者专注于自定义SQL和业务查询。医疗系统的查询条件往往又碎又多：按姓名模糊查、按身份证号精确匹配、按参保状态过滤、按时间段区间查询，这些条件组合用MyBatis-Plus的LambdaQueryWrapper处理效率很高。更关键的是，多表联查和复杂统计SQL可以继续写在XML里，两条路都走得通。相比Spring Data JPA，MyBatis-Plus在复杂查询的可控性上更适合国内这种偏“SQL思维”的开发习惯。

MySQL8.0作为存储层，主要看中窗口函数和JSON数据类型的支持。比如统计各年龄段的参保人数分布、计算医保报销费用时使用窗口函数，代码里少写很多临时表的逻辑。另外，MySQL8.0默认的utf8mb4字符集彻底规避了Emoji字符和生僻字存入数据库报错的问题——这一点在居民姓名和地址字段上非常实用，毕竟户籍信息里经常出现“𠮷”“玥”这类扩展区字符。

1.2 前后端分离与目录结构规划

项目没有采用传统Java Web的JSP页面方案，而是彻底的前后端分离部署。前端运行在Nginx上，通过HTTP请求调用后端接口；后端只处理JSON数据，不关心页面渲染。

这种结构带来的直接好处是团队协作的并行度提升。前端开发可以先用Mock数据调通页面交互，后端可以同步调试接口逻辑，最后联调时只需要对齐接口文档和异常返回格式。更重要的是，乡镇卫生院如果要后续嵌入大屏展示或者微信端查询功能，后端接口可以被多个端复用，不需要重写一套服务。

后端代码按标准分层架构组织。

com.health.system ├── controller // 接口层，仅做参数接收与结果包装 ├── service // 业务逻辑层，处理事务、校验、状态流转 ├── mapper // 数据访问层，MyBatis-Plus接口继承 ├── entity // 数据库实体映射 ├── dto // 传输对象，避免实体直接暴露给前端 ├── vo // 视图对象，聚合多表数据 ├── config // 配置类，拦截器、跨域、分页插件等 ├── utils // 工具类，如身份证校验、医保编号生成

前端的核心思路是按业务模块划分视图，而不是按页面组件堆叠。

src ├── api // 接口请求封装，统一走axios实例 ├── views // 页面级组件，一个目录对应一个业务域 │ ├── resident // 居民档案管理 │ ├── insurance // 参保缴费管理 │ ├── reimbursement // 报销审核管理 │ └── system // 系统管理（用户、角色、菜单） ├── router // 路由配置，与后端菜单表动态生成 ├── store // Pinia状态管理，存放用户信息和全局记录 ├── components // 通用业务组件，如分页搜索栏、详情抽屉 ├── directives // 自定义指令，如按钮级权限v-permission

这个结构的核心用意只有一个：业务代码内聚，横向依赖最小化。新来的开发人员拿到项目，能快速定位“报销审核”相关代码在哪个目录，改起来不迷路。

2. 后端核心模块设计与业务实现细节

2.1 数据库模型的边界划分

城乡居民基本医疗信息管理系统的核心数据域围绕“人、保、费、报”四个字展开。

人指居民基础档案，核心表是resident_info，包含姓名、身份证号、户籍地址、联系人电话、困难属性标记等。身份证号是业务上的唯一标识，设计了唯一索引，并且所有与居民关联的业务表都统一使用resident_id作为外键逻辑关联，不直接用身份证号做主键——这样在身份证信息变更时（极少发生，但存在），不需要级联修改所有业务数据。

保指参保关系表insurance_record，记录居民在一个参保年度内的参保状态、参保类型（普通居民、低保对象、特困供养人员）、缴费档次和缴费时间。一个居民在不同年份有多条记录，所以这张表是按“居民+年度”做唯一约束。

费指缴费流水payment_record，每一笔缴费都会生成一条流水，包含缴费金额、缴费方式、操作员和缴费状态。流水表不能直接修改，如果缴费信息录错了，只允许作废后重新生成，以此保留完整的审计痕迹。

报指报销申请与审核记录reimbursement_record，记录门诊或住院报销的申请金额、审核状态、报销比例和最终支付金额。

这四个数据域之间的关联是：先有居民档案，才能做参保登记；参保成功后才能产生缴费流水；在参保有效期内发生的医疗费用才能申请报销。这种强顺序的业务约束，在后端Service层必须校验，不能只依赖前端控制。

2.2 参保登记与缴费状态机设计

参保登记是整个系统里最容易出逻辑漏洞的模块。按照业务要求，居民先登记参保意向，然后缴费确认，缴费后系统自动变更参保状态为“已参保”。但实际操作中会出现各种分支：登记后未缴费、缴费中支付失败、缴费成功后需要退费重缴。

我把参保记录的状态设计成一张状态机流转图在代码里实现。

INIT（已登记）——> PENDING（待缴费）——> ACTIVE（已参保） | | |——> EXPIRED（已失效） |——> CANCELLED（已退保）

每个状态流转动作都在Service层做了幂等处理。比如缴费回调接口，支付平台的通知可能重复推送，同一笔缴费记录重复处理时必须返回相同结果，不能重复更新参保状态。

这里有一个细节值得展开：缴费成功后的状态更新，我采用了补偿机制而不是分布式事务。秒杀类高并发系统需要分布式事务，但一个乡镇卫生院级别的医保系统，单日缴费笔数最多几百，简单可靠的事务操作完全能处理。Service方法上直接加@Transactional，一张流水表加一张参保记录表，两次更新在一个事务里完成。如果保证强一致，就是最简单有效的方案。

2.3 报销审核流程的权限控制

报销审核流程涉及三个角色：窗口受理员、初审审核员、终审管理员。窗口受理员提交报销申请材料，初审员核对费用明细是否合规，终审管理员决定最终拨付金额。

这个流程用工作流引擎太重，自己手写一套状态流转又怕边界逻辑不完整。我的做法是结合Spring Security的角色权限 + 数据行级过滤来实现。角色权限控制操作入口，比如初审审核员只能看到“待初审”状态的记录，终审管理员才能看到“初审通过”后的数据。

数据行级过滤是用MyBatis-Plus的拦截器实现的，根据当前登录用户的角色自动拼接审批状态条件。这样即使前端接口被恶意调用，后端也不会返回越权的数据。这一点在医疗系统里非常重要，居民的健康信息属于敏感数据，级别不同的工作人员必须看到完全不同的数据范围。

3. 前端架构与业务交互实现

3.1 Vue3组合式API改造后台管理页面的方式

用Vue3开发后台管理页面，最关键的变化是组件逻辑的组织方式从“按选项分块”变成了“按功能点聚合”。传统Vue2写法里，一个复杂表单页面的data、methods、watch是分离的，改一个业务功能往往要上下跳跃多次。Vue3的Composition API允许直接按功能块写代码。

比如居民档案管理页面，新增和编辑共用一套表单，但校验规则略微不同。我封装了一个useResidentForm的组合式函数：

// 组合式API封装居民表单逻辑 export function useResidentForm(initialData = {}) { const formRef = ref(null) const formModel = reactive({ name: initialData.name || '', idCard: initialData.idCard || '', gender: initialData.gender || '男', birthDate: initialData.birthDate || '', address: initialData.address || '', phone: initialData.phone || '', povertyFlag: initialData.povertyFlag || '0' }) const rules = { name: [{ required: true, message: '姓名不能为空', trigger: 'blur' }], idCard: [ { required: true, message: '身份证号不能为空', trigger: 'blur' }, { pattern: /^\d{17}[\dXx]$/, message: '身份证格式不正确', trigger: 'blur' } ] } const resetForm = () => { formRef.value?.resetFields() Object.keys(formModel).forEach(key => { formModel[key] = '' }) } return { formRef, formModel, rules, resetForm } }

这段代码的复用性带来了很直接的体验：居民管理、参保登记、报销申请三个页面都要录入居民基础信息，直接调用这个组合式函数，避免复制三遍相似代码。

3.2 基于Pinia的全局状态与权限指令实现

前端状态管理选的是Pinia而不是Vuex。原因很实际：Pinia的API更简洁，TypeScript支持更好，而且去掉了Mutation的概念。后台管理系统的全局状态主要包含三类：用户基本信息、路由权限列表、系统配置参数。

路由权限的设计是这样的：用户登录后，后端返回该用户可访问的菜单树，前端把菜单树存储到Pinia中，通过动态添加路由的方式实现权限控制。具体实现方式是，后端菜单表里每个菜单对应一个前端路由的name字段，前端通过遍历菜单树找到对应的组件并注册。这样不同角色登录系统，左侧菜单本身就是动态变化的，没有权限的路由根本不会注册。

按钮级权限我则是通过自定义指令实现。这是一个很实用的细节，比如报销审核页面中，“提交终审”这个按钮只有初审通过后且当前用户是终审管理员时才显示。如果纯粹用v-if在模板里判断，每一个按钮都要写一遍判断条件，非常啰嗦。封装成指令后，模板层面干净很多：

// 按钮权限指令封装 const permission = { mounted(el, binding) { const { userStore } = useStore() const { value } = binding if (!userStore.permissions.includes(value)) { el.parentNode?.removeChild(el) } } } // 页面中使用 // <el-button v-permission="'reimbursement:finalAudit'">终审通过</el-button>

这里需要特别注意：自定义指令的移除逻辑是单向的，当权限列表是异步加载时，必须等待权限数据加载完成后再挂载路由和渲染页面。否则指令执行时权限列表为空，所有按钮都会被移除。

3.3 动态表格与复杂筛选表单的交互优化

医疗信息管理系统中，表格是绝对的主角。居民列表、缴费流水、报销记录，每一个页面都是搜索区在上、表格在下、分页在底部的布局。

动态表格的核心难点不是数据渲染，而是筛选条件与请求参数的联动。我统一封装了一个useTableQuery组合式函数，把分页信息、筛选条件和请求触发的逻辑封装在一起：

export function useTableQuery(fetchFunction) { const loading = ref(false) const tableData = ref([]) const total = ref(0) const queryParams = reactive({ pageNum: 1, pageSize: 10, keyword: '', status: '' }) const loadData = async () => { loading.value = true try { const res = await fetchFunction({ ...queryParams }) tableData.value = res.records total.value = res.total } finally { loading.value = false } } const handleSearch = () => { queryParams.pageNum = 1 loadData() } const handleReset = () => { queryParams.keyword = '' queryParams.status = '' queryParams.pageNum = 1 loadData() } onMounted(() => loadData()) return { loading, tableData, total, queryParams, loadData, handleSearch, handleReset } }

筛选按钮触发handleSearch时重置页码并重新请求，这是避免“搜索后不再第一页”这个低级错误的通用手笔。很多开发者在实现搜索功能时容易忘记把当前页重置为1，导致搜索结果为空时停留在一个超出总页数的页码上。

4. 环境搭建、数据库配置与系统部署实操

4.1 MySQL8.0在Windows和Linux下的安装避坑

MySQL8.0的安装过程比5.7版本多了一些细节。这里按下不表常规安装步骤，强调几个我实际调试中容易翻车的点。

第一个坑是字符集。MySQL8.0默认字符集就是utf8mb4，按理说不会出现中文乱码问题。但如果是从5.x升级上来的旧库导入数据，配置文件里的character-set-server可能还是老参数，需要手动检查：

[mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci

第二个坑是认证插件。MySQL8.0默认使用caching_sha2_password，而很多老的图形客户端或老版本驱动（如旧版mysql-connector-java）只支持mysql_native_password。连接SpringBoot项目时如果报Authentication plugin错误，要么升级驱动版本，要么在创建用户时手动指定认证插件：

CREATE USER 'health_admin'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password'; GRANT ALL PRIVILEGES ON health_db.* TO 'health_admin'@'%'; FLUSH PRIVILEGES;

第三个坑是时区问题。MySQL8.0默认时区是UTC，而医疗系统的报销时间、缴费时间必须精确到东八区时间。连接池配置里必须加上serverTimezone=Asia/Shanghai，否则插入时间字段会比实际时间少8小时。这属于极其隐蔽的数据错误，等到月底对账时发现问题，排查成本极高。

4.2 SpringBoot2整合MyBatis-Plus与分页插件的配置

SpringBoot2整合MyBatis-Plus非常顺滑，但要特别注意兼容性版本。我用的是MyBatis-Plus 3.5.2版本，这个版本对SpringBoot2.x的兼容性最稳。

分页插件现在通过配置类注入，不再像老版本那样扫描注解：

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

这里有一个容易忽略的细节：如果表数据的增长达到百万级，MySQL深分页性能会显著下降。比如查询第10000页的数据，LIMIT 99990,10会让MySQL扫描大量无用行。医疗系统里记录数不至于到这种量级，但如果后面要对接省级平台做数据交换，这个隐患需要提前考虑。我的方案是：当页码超过一定阈值时，改用游标分页（基于上次结果的ID查询），尽管前端没有这么大数据量的展示场景，但接口层要预留这种能力。

4.3 前端项目构建与Nginx部署要点

Vue3项目的构建流程不复杂，npm install、npm run build就能生成dist目录。真正容易出问题的是部署阶段的接口路径配置。

开发环境下，前端通过Vite的proxy配置解决跨域问题。生产环境部署到Nginx后，仍然需要配置反向代理，否则前端的/api请求会因跨域直接被浏览器拦截。Nginx的关键配置如下：

server { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }

这里proxy_pass后面的URL是否带斜杠是有讲究的。写成http://127.0.0.1:8080/，转发到后端时会把location匹配部分去掉，也就是把/api/user/list转发为/user/list，这要求后端Controller的RequestMapping里不要带/api前缀。

如果后端接口路径里保留了/api前缀，那么proxy_pass就应该写成http://127.0.0.1:8080。这个差别虽然小，但配置错了整个系统都会404，调试时比较容易踩坑。

另外一个关键点是Vue Router的history模式。如果使用createWebHistory()而不是默认的hash模式，刷新页面时Nginx必须配置try_files回退到index.html，否则刷新非根路径会返回404。上面的配置已经包含了这一点。

4.4 前后端联调与接口文档管理

项目带文档，我认为文档不能只是把接口列出来，重点是约定清晰的请求响应格式。整个项目的统一返回结构是这样的：

{ "code": 200, "message": "操作成功", "data": { "total": 180, "records": [...] } }

code为200时表示业务成功，非200表示业务异常，HTTP状态码统一使用200，由业务code判断实际结果。这种做法在前后端分离项目里有争议，但我觉得在管理后台系统中非常好用——网络层面的错误和业务层面的错误被清晰区分，前端axios拦截器只需要判断业务码进行提示，减少很多重复代码。

我要求所有接口定义都包含：请求方法、请求路径、请求参数说明、响应示例。因为这套系统涉及角色权限和审批流程，接口文档中必须标明哪些接口需要哪些角色权限。漏掉这一点，前端开发只能靠猜，联调阶段就变成灾难。

5. 核心数据流与统计报表实现

5.1 参保率统计与年龄分布数据看板

告别单纯只有增删改查的CRUD系统，当前项目里数据看板是必要模块。乡镇卫生院的经办人员需要快速掌握本辖区的参保覆盖情况。

参保率统计的关键SQL逻辑是：以辖区居民总数为分母，以参保状态为ACTIVE的居民数为分子，按乡镇分组计算。如果直接在主表里做多表聚合，性能会很差，我的做法是维护一张每日统计快照表。

CREATE TABLE daily_insurance_stats ( id BIGINT PRIMARY KEY AUTO_INCREMENT, stat_date DATE NOT NULL, area_code VARCHAR(20) NOT NULL, total_residents INT NOT NULL, insured_residents INT NOT NULL, coverage_rate DECIMAL(5,2) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_area_date (area_code, stat_date) );

每天凌晨通过定时任务统计前一天的参保情况，新增下班后看不到的昨日数据，前端看板直接查这张快照表，响应速度极快。这种以空间换时间的思路，对于报表场景比实时统计更实用。定时任务我用的是Spring自带的@Scheduled注解，没有引入额外的分布式任务调度框架，因为单机部署完全够用。

5.2 报销费用按病种聚合的SQL优化

报销模块还有一个典型功能：按病种（ICD-10编码）统计报销金额Top10。这个查询涉及报销明细表和疾病字典表，如果直接在明细表上做GROUP BY，表数据量增加时性能下跌严重。

MySQL8.0的窗口函数在这里可以派上用场。我用ROW_NUMBER()按报销费用排序，直接完成TopN统计：

SELECT disease_name, total_amount, total_count, row_no FROM ( SELECT d.disease_name, SUM(r.reimburse_amount) AS total_amount, COUNT(r.id) AS total_count, ROW_NUMBER() OVER (ORDER BY SUM(r.reimburse_amount) DESC) AS row_no FROM reimbursement_record r INNER JOIN disease_dict d ON r.icd_code = d.icd_code WHERE r.status = 'APPROVED' AND r.apply_time >= #{startTime} AND r.apply_time < #{endTime} GROUP BY d.disease_name ) t WHERE row_no <= 10

在同样查询逻辑下，如果使用MySQL 5.7实现，需要先查出全量聚合结果再到应用层排序截取，要么就在SQL里用临时变量模拟窗口函数，两种方式都不够优雅。MySQL8.0的原生窗口函数让这个统计逻辑非常简洁。

6. 常见问题与排查技巧实录

6.1 身份证号18位校验与性别提取的逻辑

医保系统里身份证号是贯穿所有业务的核心标识，它的校验逻辑必须放在后端Service层，不能只依赖前端正则。前端校验可以通过，但恶意请求可以直接绕过浏览器访问接口。

后端校验的核心实现包含两部分。第一部分是格式校验，正则表达式校验前17位是数字、最后一位是数字或X；第二部分是校验码验证，这是更容易被忽略的。身份证最后一位是由前17位通过特定算法计算得出的校验码，计算方式为将前17位数字分别乘以不同加权因子后求和，再对11取模得到校验码。不加这一步校验，随便编一个貌似合法格式的身份证号也能通过。

性别提取相对简单，身份证第17位（倒数第二位）的奇偶性决定性别。如果是奇数则性别为男，偶数为女。但要注意，对于15位旧版身份证号的情况，系统应提示居民更新换代证件而不是直接解析。

6.2 分页查询总数统计慢怎么办

在分页查询中，MyBatis-Plus默认会执行一条COUNT查询来获取总数。当表数据量大且筛选条件复杂时，COUNT查询可能非常慢。

我遇到的情况是：报销查询页面的筛选条件包含了状态和日期范围，COUNT语句执行了接近1秒，用户体验很差。排查后发现是日期范围的隐式类型转换导致索引失效。

优化方案是保证在表设计时就将日期字段设置为date类型，查询时也统一传入字符串格式的日期，避免MySQL对字段做函数处理后无法使用索引。还有一个偏方是：在明确不需要精确总数的场景下，采用近似总数。比如首页展示的参保人数统计可以接受误差，直接通过MyBatis-Plus的selectCount加缓存实现，而不是每次查询全部数据。

对于百万级数据的分页，更加极端的优化方案是使用子查询先缩小数据范围再COUNT，但这种做法对医疗系统这个体量来说属于过度设计，知晓即可。

6.3 El-Table动态表格渲染卡顿的排查

Vue3 + Element Plus的表格组件在渲染大量行时，会遇到明显的卡顿问题。缴费流水表或报销明细表一次性返回上千条数据时，页面滚动和筛选操作会出现掉帧现象。

排查后主要发现两个原因。第一个原因是表格列数过多，每列都有复杂的插槽内容，比如状态Tag的颜色判断、金额列的数字格式化、操作列的多个按钮。上千行乘以十几列，虚拟DOM节点数量激增，渲染压力很大。解决方案是启用Element Plus表格的虚拟滚动功能，只渲染可视区域的行。

第二个原因是数据结构嵌套过深。后端返回的记录里包含了关联的居民信息对象，前端表格直接取res.resident.name。深层嵌套的响应式代理在渲染时会触发更复杂的依赖追踪，性能开销随之而来。我的处理方式是在前端将嵌套数据扁平化处理，从后端返回时就直接构造好展示层的扁平对象。页面只负责展示，数据结构设计向前端倾斜，减少模板里的深层访问。

6.4 权限系统验证的常见坑

动态路由和按钮权限的实现过程中，最常遇到的问题是刷新页面后菜单消失。原因是用户信息存在Pinia中，刷新后内存数据清空，需要重新调用后端获取用户信息和权限菜单。

我在项目中通过登录后把用户信息和菜单权限存储在LocalStorage中，刷新页面时再从LocalStorage恢复状态，同时校验token是否过期。这种方式在安全要求极高的系统中有争议，但对于乡镇卫生院级别的后台系统，能极大提升使用流畅度。

另外还要注意退出登录时必须清理LocalStorage中的全部数据，包括token、用户信息、菜单列表、权限码。清理不彻底会导致下次登录时出现权限残留或者看不到当前用户所属的路由。

7. 我的实操体会与项目扩展方向

经历这个项目后我对医疗类管理系统的开发有了更深的体会。这类系统虽然业务逻辑不算复杂，但对数据的准确性和操作审计的要求非常高——每一笔缴费、每一次报销审核都需要可追溯、可纠错。代码实现过程中最值得投入时间的不是花哨的前端交互，而是把边界条件理清楚。参保状态怎么流转、重复缴费怎么处理、身份证号校验为什么不能只写前端，这些才是真正体现系统价值的地方。

如果你拿到这套源码想二次开发，我的建议是先跑通本地环境、熟悉菜单结构和数据表关联，再从你最关注的业务模块下手改造。比如增加一个“慢性病随访管理”模块，或者对接省级医保平台的接口，这些都是很自然的扩展方向。

最后再分享一个小技巧：开发调试阶段，不要只依赖前端控制台看Network请求。建议使用Apifox或者直接在浏览器里写一个fetch测试脚本，单独测试后端接口的权限控制和参数校验是否生效。很多时候前端传参正常，但绕过前端直接调用接口时，后端的校验逻辑反而不够严密。把这些漏掉的校验补上，系统才真正算得上可以交付。