疫苗发布与接种预约系统：基于SpringBoot+Vue+MySQL的毕设全解析

1. 项目到底在做什么一次把毕业设计说透先说结论这是一个典型的“信息发布 在线预约”类管理系统业务面不算宽但胜在前后端分离、功能链路完整、可演示性极强非常适合作为计算机相关专业的毕业设计选题。标题里写得很清楚——SpringBoot Vue MySQL三个关键词几乎就是目前国内高校毕设项目的“标准三件套”一份源码加上数据库脚本、论文、部署文档合在一起就是一个能直接跑起来、能写进答辩PPT、能支撑起几千字论文内容的完整项目。很多同学拿到这种“疫苗发布和接种预约系统”标题第一反应是这跟普通的“XXX预约系统”有什么区别我这里直接说我的理解它本质上是一个带有“发布管理 资源预约”双核心的业务系统比单纯的商城、博客多了一层业务约束又比完全定制化的医疗系统简单可控。所谓疫苗发布对应管理员端的信息录入、上下架、库存维护所谓接种预约对应普通用户的时段选择、名额抢占、取消与记录查询。整条链路做下来覆盖了RBAC权限、前后端交互、数据库事务、状态机变化、报表统计等毕设高频考察点用来展示技术能力非常合适。再说这个题目的实际受众。如果你是准备做毕设的学生或者想快速跑通一个前后端分离项目的开发者这个项目能让你在最短时间内知道一个完整的Web系统到底是怎么分层、怎么联动、怎么部署的。如果你是已经有一定Java基础、想找实战案例练手的人它也足够当做一个“中型项目范本”来研究——不是那种只在PPT里画一画的伪项目而是能真正运行、有数据库表结构、有接口文档、有部署流程的实体项目。我见过太多毕业设计只放截图和论文一到现场演示就卡壳原因无非就两个要么环境没配对要么数据库初始化不完整。而一份带源码、带数据库脚本、带部署文档的预约系统恰好把这些坑提前填平了。你拿到手之后真正要做的不是“重新发明一套系统”而是看懂它、运行它、再根据自己的研究方向做局部改造。这篇文章我就按这个思路把整个项目的设计逻辑、核心实现、部署要点和避坑经验完整拆开讲。2. 整体设计与技术选型为什么是这三个东西组合2.1 前后端分离结构本质是“一个前端房子 一个后端食堂”疫苗预约系统最常见的部署形态是前后端分离Vue负责页面渲染和用户交互SpringBoot负责提供接口和处理业务逻辑MySQL负责持久化数据。三者各干各的又通过HTTP接口串起来。这种结构对毕业设计来说有一个巨大的好处答辩时可讲的东西多。你可以讲Vue的组件化、Axios的请求封装、路由守卫的逻辑也可以讲SpringBoot的分层架构、MyBatis-Plus的CRUD、Shiro或JWT的权限控制还可以讲MySQL表设计、索引优化、事务隔离级别。三个层面各有内容论文至少不愁没有章节。从实际开发效率看前后端分离也让并行开发成为可能。前端只需要Mock接口后端只需要输出JSON两边约好数据结构后基本可以各写各的。很多毕设是单人完成但即使如此分离结构依然值得坚持因为后期你要改样式、要加页面、要调接口分离后的代码组织远比传统JSP项目清爽。2.2 SpringBoot为什么它压倒了SSH和SSM成为默认选择早期高校里大量使用SSHStrutsSpringHibernate或者SSMSpringSpringMVCMyBatis这些不是不能用但配置太啰嗦。写一个HelloWorld级别的Web工程先得配web.xml、spring-mvc.xml、mybatis-config.xml再用IDE插件生成一堆样板代码。SpringBoot的出现相当于把这些配置全部自动化了内嵌Tomcat、自动装配、约定优于配置一个注解就能启动一个Web应用。对毕设而言少折腾环境、多关注业务本身就是最大的优势。具体到这个疫苗预约项目里SpringBoot承担的职责分为四层Controller层接收前端请求做参数校验调用业务方法返回统一格式的Result对象。Service层写核心业务逻辑比如预约时判断库存、判断用户是否重复预约。Mapper层通过MyBatis-Plus操作数据库避免手写大量SQL。Config层配置跨域、拦截器、MyBatis-Plus分页插件、Shiro或拦截器放行规则。这四层不是随意划分的而是为了“可替换性”。比如后来你要加Redis缓存疫苗列表那只需要在Service层插入缓存逻辑Controller和Mapper基本不用动。这就是分层设计最大的价值——改动局部而不影响整体。2.3 Vue从安装到组件化别只停留在“Hello World”Vue在这类项目里的地位说简单点就是“用JS控制页面数据的工具”。但很多同学对Vue的理解就停在“重启项目、看个页面、加个按钮”。实际上Vue在这个项目里至少要用到这几个硬知识点第一是组件化。整个前端不能是一坨代码而是分成Header、导航栏、疫苗列表卡片、预约弹窗、数据面板等独立组件每个组件有自己的模板、脚本和样式。第二是路由管理。vue-router要配置访问路径比如“/admin/vaccine/list”和“/user/reserve”同时要配置路由守卫拦截未登录用户或者非管理员角色的访问。这里有一个极容易踩的坑路由守卫里调用了获取用户信息的接口而接口又依赖TokenToken失效时可能造成循环跳转。我后面在问题排查部分会再说这个。第三是状态管理。虽然这个系统不算大但登录用户信息、当前疫苗列表、预约状态这些数据往往要在多个组件之间共享用Vuex或Pinia管理比用props传来传去清爽得多。第四是Axios封装。把接口地址、请求头、错误提示统一封装起来前端代码才会整洁。很多毕设前端代码里到处散落着axios.post后续维护时会特别痛苦。简单总结SpringBoot决定后端业务能力Vue决定用户界面体验MySQL决定数据可靠性三者组合覆盖了一个Web系统从入口到存储的完整链路。这也是这套技术选型穿透力强的原因——你学的不仅是某个框架的用法而是一套现代Web开发的通用范式。3. 数据库设计一张好的表结构胜过一堆“高级技巧”3.1 核心表拆解从用户到疫苗预约的角色链疫苗发布与接种预约系统的数据库通常不是一张表就能搞定的。对于首页展示、后台管理、预约操作三类功能一般会拆出至少六张核心表用户表、疫苗信息表、接种点表、预约记录表、公告表、管理员操作日志表。先看用户表包含用户名、密码、真实姓名、手机号、角色字段等再看疫苗信息表它要存疫苗名称、类型、生产企业、适用人群、不良反应说明、库存量、上架状态、上下架时间接种点表则负责存地点名称、地址、联系电话、每日接种容量等基础信息。关键的还是预约记录表。这张表是整个系统业务逻辑最密集的地方设计时至少要包含预约编号、用户ID、疫苗ID、接种点ID、预约日期、预约时间段、状态字段、创建时间、取消时间、完成时间。状态字段一般用整数0、1、2、3表示待接种、已完成、已取消、已过期。这个设计看似简单实际上把整个预约生命周期都覆盖了。你通过一个状态字段就能回答“这个用户还有没有未完成的预约”“今天有哪些人该接种”“哪些预约长期挂起需要自动失效”等问题。疫苗信息表和预约记录表之间是典型的一对多关系一个疫苗可以被多次预约。接种点表和预约记录表之间也是一对多关系。用户表与预约记录表同样是一对多。这种关系模型在MySQL里非常常规外键逻辑简单清晰画ER图也好看。论文里放一张ER图基本就能把数据设计思路讲明白。3.2 为什么字段设计要“留后手”而不是“少而精”很多初次写毕设的同学建表时容易犯一个毛病觉得字段越少越简单结果后面加功能时疯狂改动表结构。比如预约记录表如果一开始不设疫苗名称快照字段等管理员后台改了疫苗名称历史预约记录就显示成别的名字了。所以我建议在预约表里冗余一份疫苗名称、接种点名称虽然这违反第三范式但对业务系统来说却是合理的折中——查询历史记录时不用连三张表。另外所有表最好都带上create_time、update_time两个时间字段。一是方便排查数据问题二是论文里写“系统支持数据审计追溯”时有据可依。MyBatis-Plus可以自动填充这两个字段不用每次插入都手动set。实际操作时只需要在实体类上加上TableField(fill FieldFill.INSERT)之类的注解再配置一个MetaObjectHandler处理器就行。数据库设计这块我还要特别提醒一个点不要把密码明文存在库里哪怕这是毕设。用BCrypt或者MD5加盐都行。答辩老师如果看到密码字段是明文第一印象会大打折扣。另外手机号、身份证这类信息在论文中要刻意说明“系统对敏感字段做了脱敏处理”即使代码里只做了简单截取也要把这个理念写出来。3.3 索引设置与SQL优化这是论文里最好写的“技术亮点”疫苗列表在首页打开时是对所有用户开放的预约记录则按用户筛选这两种查询场景频率很高。建议在预约记录表的user_id和status上建立联合索引在疫苗信息表的status和vaccine_name上建立联合索引。别小看这两条索引在论文的性能分析章节写“索引优化前后查询速度对比”时它就是最能直观展示问题解决过程的数据支撑。SQL层面最值得注意的就是避免“SELECT *”。尤其是疫苗信息表有备注字段、预约记录表有取消原因字段时如果你不断把大字段查出来接口响应速度会被压低前端渲染也会变慢。写代码时尽量列出明确字段。还有一个容易忽略的小细节分页查询一定要用LIMIT不要一次性把全表数据捞出来再在前端做滑动加载。MyBatis-Plus自带分页插件直接配置一个PaginationInnerInterceptor就能用开发成本几乎为零。4. 核心功能实现从“能跑”到“跑得对”的关键细节4.1 疫苗发布不是简单的增删改查而是“状态可追踪”疫苗信息管理的本质是CRUD但要注意两个关键点。第一删除操作不要物理删除建议用逻辑删除。原因很直接疫苗可能有过往预约记录如果直接删除疫苗信息预约记录表里的疫苗名称快照就成了无源之水数据关联会断裂。实际开发中我习惯在表里加一个deleted字段按MyBatis-Plus的TableLogic注解配置逻辑删除这样查询时自动过滤已删除数据但对历史链路没有破坏。第二上下架操作需要独立接口。发布疫苗不等于所有客户端立即可见还要有一个状态开关比如status字段为0是草稿、1是上架、2是下架。后台管理页面用一个按钮切换状态前端调用接口后返回最新的上下架状态。这个设计看起来只是多了一个字段但对整个预约流程影响巨大下架疫苗不允许再产生新的预约同时已产生的未完成预约要给出明确的提示和处理方案。如果没有这种状态区分用户抢到一个下架疫苗的预约现场就会出问题。4.2 预约与取消用数据库事务死死守住“库存和名额”预约功能是本系统最核心、最容易出Bug的地方。先说基础流程用户打开疫苗列表、选择一个接种点、选上午或下午的某个时段、点击提交系统检查该疫苗库存和该接种点时段的剩余名额校验用户是否重复预约最后写入预约记录并扣减库存。这里有两个大坑。第一个是并发超卖。两个用户同时点预约各自读到库存为1然后都写预约成功结果库存变成-1。这在真实场景中绝对不允许。解决办法也简单在扣减库存的SQL上用乐观锁或者直接加条件判断。“UPDATE vaccine SET stock stock - 1 WHERE id ? AND stock 0”如果受影响行数为0说明库存不够直接不给预约。这条SQL语句看似朴素但它是防超卖最可靠的防线比先查再判断稳得多。整个预约过程必须在同一个事务里执行你可以在Service方法上加上Transactional注解保证“写入预约记录 扣减库存”要么都成功要么都失败。第二个坑是取消预约时的库存回补。用户取消预约后不能只改一下预约状态还要把疫苗库存加回去同时要判断该疫苗当前是否处于上架状态。如果已经下架取消后库存要不要增加这个可以根据业务自行决定但无论怎么定逻辑必须写清楚。我建议的规则是只要用户取消的是“待接种”状态就无条件回补库存如果疫苗本身已经逻辑删除那就更新记录即可不回补库存因为这条疫苗记录对普通用户已经不可见了。4.3 用户端页面Vue核心知识点与“交互体验”怎么结合用户端是答辩时最容易被老师操作的模块所以页面不能只停留在“能看能用”还要有一点交互设计意识。比如首页疫苗列表我建议用卡片布局展示疫苗名称、生产企业、剩余库存和预约按钮。当库存为0时按钮置灰并显示“约满”当疫苗处于下架状态时卡片直接不展示或者加一个“已下架”遮罩。这些逻辑并不复杂但体现出你对业务状态的理解已经超出了CRUD层面。在预约页面用户选择日期和时段后前端应该实时展示“剩余名额”。这个剩余名额可以从后端预约时段统计接口获取在时间或地点变更时重新请求避免用户提交后才发现名额不足。前端的Axios请求最好封装成统一的api.js所有接口集中在同一个文件里维护方便后端端口改动时快速替换。Vue Router的使用也要规范比如在路由配置里对“/user/reserve”加meta:{ requiresAuth: true }然后在全局前置守卫中判断Token是否存在不存在就跳转到登录页面。这里要提醒一下不要为了显示技术栈而强行使用Vue 3的Composition API。如果你的基础还停留在Vue 2的Options API就用Vue 2加Element UI写能保证项目稳定完成反而更重要。如果导师指定新技术那就用Vue 3 Vite Element Plus但要在论文里写清楚Composition API带来的代码组织优势。技术选型没有绝对优劣合适自己能力水平、能稳定交付才是第一位的。4.4 管理员端从“审批视角”看一个管理系统的完整闭环管理员端对应四个主要功能用户管理、疫苗发布管理、预约订单管理、公告管理。用户管理除了列表展示还要有重置密码、禁用账号等操作总之要按“能管制”的标准去设计。订单管理要支持多条件筛选比如按手机号、预约日期、状态查询同时要能导出Excel导出功能用一个EasyExcel或者POI写几十行代码就能实现但给论文增加一个“报表导出”亮点却很划算。疫苗发布管理的写法我已经说过核心是状态的流转。公告管理更简单但在系统里必不可少因为疫苗接种点有时候要临时通知“某日暂停接种”或者“某厂家疫苗到货”没有公告栏这些信息只能靠电话这不符合一个完整信息发布系统的预期。公告表里要有标题、正文、置顶标识、发布时间。用户端在首页顶部轮播或列表展示后台提供编辑、发布、撤回功能。这四块内容串在一起才真正算得上“管理系统”而不是单独的“增删改查页面集”。5. 从源码到上线环境配置、数据库初始化、打包部署全流程5.1 本地环境准备JDK、MySQL、Node.js 的版本踩坑记录很多同学在跑这种项目时第一步就卡在环境上。这里我给出一个相对稳妥的版本组合也是这类毕设最常见、兼容性最好的环境JDK 1.8、Maven 3.6.3、MySQL 5.7或8.0、Node.js 14到16。SpringBoot版本建议用2.x系比如2.5.x或2.7.x不要一上来就选3.0以上。SpringBoot 3要求JDK 17起步如果你的项目依赖是老版本MyBatis-Plus、Shiro等库容易出现兼容性问题到时候排查起来非常耗时间。用我这条组合大概率能绕开很多“版本太高导致启动失败”的问题。MySQL安装是另一个高频卡点。Windows环境下我建议直接装MySQL Installer安装时选择“Server only”端口默认3306编码选utf8mb4这样后续导入数据库脚本时不会出现中文乱码。如果你用的是MySQL 8.0还要注意认证插件问题有的Navicat连接时会报错“caching_sha2_password cannot be loaded”。解决办法是在MySQL命令行执行一条语句把root账号的密码规则改为mysql_native_password。版本不匹配导致连不上数据库是真正常见的起步问题但网上教程大多讲得不够直接。前端环境更简单安装Node.js后在项目根目录执行npm install如果拉取依赖太慢就把registry切换为国内镜像源。工程文件里如果有package-lock.json安装成功的概率更高。如果遇到node-sass安装失败这种经典问题直接把sass-loader和node-sass换成dart-sass也就是在package.json里改用sass包能快速解决编译报错。5.2 数据库初始化别再手动一条条建表了拿到项目之后第一步不是看代码而是先建库。在MySQL中创建一个名为vaccine_system的数据库字符集选utf8mb4排序规则选utf8mb4_general_ci然后把项目自带的vaccine_system.sql导入。如果项目附带的是SQL文件用Navicat直接“运行SQL文件”即可。如果你用的是命令行就执行mysql -u root -p vaccine_system vaccine_system.sql导入完成后检查几张核心表的数据。如果管理员账号密码是默认的admin/123456尽早登录后台验证一下。这里有一个容易混淆的点有的项目SQL脚本里同时包含了建库语句和建表语句导入的时候不需要手动建库但有的脚本默认不建库只建表。你最好打开SQL文件开头看一眼有CREATE DATABASE语句就直接整个脚本导入没有的话先建库再导入。这个细节能帮你省下很多无谓的报错时间。5.3 后端打包与启动mvn clean package 背后发生了什么SpringBoot项目启动前先检查application.yml或application.properties里的数据库连接信息。用户名、密码、url都要改成自己本机的配置。连接字符串里常见的问题是时区serverTimezoneAsia/Shanghai要写清楚否则JDBC连接MySQL 8时会提示Server returns invalid timezone。配置改好后可以先用IDE直接启动在启动类上点运行。看到“Started Application in xx seconds”基本就成功了。后端验证接口是否正常直接用浏览器访问localhost:8080/vaccine/list看是否返回JSON数据。如果不能访问要先看看项目里有没有配置统一的context-path如果有URL就要带上前缀。打生产包时切换到项目根目录执行mvn clean package -DskipTests打包成功后target目录下会生成一个jar文件。运行这个jar包时用java -jar vaccine-system.jar这里要补充一个真实经验jar包运行后控制台里如果频繁输出“Error creating bean with name”之类的异常多半是实体类映射数据库表名失败或者某个字段找不到。你检查一下实体类名是否跟数据库表名大小写对不上MyBatis-Plus默认会把驼峰命名转为下划线命名如果表名不规范就会出错。解决方式是查一下表名是否和实体注解上的TableName一致。5.4 前端构建与部署dist目录就是你的“站点”前端项目启动相对简单在Vue工程根目录执行npm run serve或npm run dev浏览器访问localhost:5173Vite默认或localhost:8080Vue CLI默认。前后端联调时注意跨域问题。开发环境下Vue CLI可以通过vue.config.js里的devServer.proxy把接口请求代理到后端地址避免浏览器直接跨域。Vite则在vite.config.js里配置server.proxy。如果后端接口返回的数据迟迟加载不出来优先看浏览器Console面板里的请求报错信息。后端控制台里如果出现“Cross origin requests are only supported for protocol schemes”之类的提示说明跨域没有配置好SpringBoot侧可以加一个CorsFilter配置类也可以在后端Controller上加CrossOrigin注解但后者只能单点解决不如全局过滤器统一。前端部署时执行npm run build生成dist目录这个目录就是纯静态资源。如果你有Nginx把dist目录放到HTML目录下再配置一个反向代理把包含/api的请求转发到后端。如果没有Nginx本地直接把dist目录用live-server或http-server跑起来也行但真实项目里建议还是走Nginx。部署文档到这里一般会写“前后端已分离部署前端由Nginx承载静态资源后端由jar包独立运行”这句话空泛但确实是生产环境的常规形态。6. 常见问题与排查技巧别人给你源码你也不要慌6.1 启动失败类端口占用、数据库连不上、依赖冲突这类问题最集中。第一种是端口被占用如果你开发环境里已经有其他Java进程占用8080就改SpringBoot配置里的server.port为8081同时记得把前端代理的目标端口也改掉。第二种是数据库连接失败你要检查MySQL服务有没有启动、密码是否正确、数据库名是否匹配。第三种是依赖冲突多见于SpringBoot版本和MyBatis-Plus版本匹配不当。我的建议是查看项目里maven的依赖树在IDE右侧Maven面板里运行依赖分析或者用命令mvn dependency:tree找出重复的、冲突的包再把多余的exclusion掉。排查这类问题有一个很实用的通用思路不要盯着异常信息最后一行看要看最前面的“Caused by”异常栈的最底层往往才是真正的病根。比如日志一大片但最下面一行写着“Access denied for user root”那就说明是账号密码问题根本不用管上面的其他报错。6.2 前端报错类404、405、跨域、渲染空白404通常是接口路径对不上。检查axios调用的URL和后端Controller层的RequestMapping路径是否一致尤其注意项目有没有加context-path或者Controller类上有没有多层路径前缀。405通常是请求方式不匹配前端用了POST后端只允许GET。这种错多花一分钟看后端日志就能确认。页面渲染空白但控制台无报错十有八九是接口返回了空数据或者Vuex里没有初始化默认值。你在模板里渲染list.length之前要先给list一个空数组初始值不然数据未到位时直接访问list[0].name会报undefined错误。我见过很多同学被这种小问题卡一整天实际上只要在data()里把所有用到的字段都给出初始结构问题就消失。6.3 关于“把jar反编译成项目”的一些实话相关热搜词里有“怎么将springboot jar反编译成项目”这确实是真实需求。假如你拿到手的是一个编译好的jar包但丢了源码想恢复出可读的Java文件常用的方案是用反编译工具。之前比较常用的是JD-GUI现在也可以配合使用CFR或Procyon这类命令行工具把jar包里的.class文件反编译回.java文件再配合resources目录下的配置、静态资源能恢复出“可读但不够原始”的工程结构。要注意的是反编译得到的代码不是100%可编译源码尤其泛型、注解、Lambda部分会有损失只能作为阅读和重建的参考。如果反编译的目的是为了继续开发我建议别抱太大期望直接按原有表结构和接口文档重写业务层可能更快。反编译工具更适合用来阅读第三方库的逻辑或者“在没有源码的情况下弄清某个接口的参数逻辑”。真正常见的做法是拿到jar先运行起来然后用接口测试工具如Postman前后端交互行为逆向出接口文档。这个思路其实也是排查线上问题时的通用技能对答辩也有帮助。6.4 部署文档里你没注意到的“小字”才是关键很多毕设项目的部署文档会写“将sql脚本执行到数据库”但不会告诉你执行前要确认当前连接用户有建表权限文档会写“前端npm install”但不会告诉你如果node_modules已经损坏需要删掉重新安装文档会写“访问后端接口”但不会告诉你防火墙可能拦截端口。所以你拿到部署文档后不要照着顺序机械执行而要保持“每执行一步都观察输出”的习惯。比如npm install结束后看一下有没有warning和errorjava -jar启动后看一下最后一行是Started还是APPLICATION FAILED TO START。部署这件事本质上是“把开发环境的状态复制到另一台机器”每一步报错都是在告诉你环境差异在哪里。解决思路永远是对齐版本、对齐配置、对齐路径。你只要按照这个思维方式走90%的部署问题都能自己排查出来。7. 这系统还能怎么扩展让毕业设计从“合格”到“优秀”很多人的项目做到“能跑”就停止了但如果你想拿高分扩容方向其实非常多。第一个方向是引入Redis做热点缓存。疫苗列表被高频访问完全可以缓存到Redis里库存扣减时先更新Redis再异步同步MySQL这就是“高性能预约系统”的入门姿势。第二个方向是接入短信或邮件通知用户预约成功、预约取消、疫苗到货时通过消息队列发送通知这能把系统的实时性讲出一个亮点。第三个方向是数据可视化。管理员首页放几张ECharts图表展示每日预约量、疫苗库存预警、各接种点使用率视觉效果好论文里也能写“系统提供了数据辅助决策能力”。第四方向是微信小程序或移动端适配Vue项目可以通过uni-app进行改造把原本的Web页面打包到小程序上这就是多端复用的技术亮点。但我要提醒一句扩展的前提是核心链路足够稳固不要在预约事务还没写完时就去加Redis。先把真实场景跑通再把扩展点作为论文的“下一步工作”反而更符合毕业设计的评分逻辑。8. 最后分享一点我自己的实操体会在帮很多人跑通同类型毕设项目后我最想说的其实是技术框架的代码是“死”的但业务流程是“活”的。你要把疫苗发布与预约系统的每一步操作想象成现实医院里的真实流程——什么时候该禁止预约、什么时候该回补库存、什么时候该给管理员提醒这些逻辑想清楚了写代码自然顺。反之如果只盯着语法和框架项目做完也只是“表面会跑”。还有一个小技巧想分享答辩之前一定要在干净环境里完整走一遍“初始化数据库—启动后端—启动前端—用户注册—管理员登录—发布疫苗—用户预约—取消预约”全流程。你会发现很多平时没注意的环节其实藏着Bug比如Excel导出时中文乱码、路由刷新后404、取消预约后库存没更新。提前走通这一遍比背一万字论文都管用。这类的选题看起来普通但它最大的价值在于完整且真实。你在这个项目里积累的“如何设计状态字段”“如何写事务”“如何排查部署问题”换一个订单系统也能用换一个会议室预约系统也能用。这才是毕业设计真正想锻炼你的东西——不是某个框架的API而是分析问题、拆解业务、落地实现的能力。