企业官网建设流程全解析

做社区医院管理系统这类项目，最怕的不是功能多复杂，而是“病人排队一小时、医生开个药卡半天”这种体验直接崩盘。今天要聊的这套源码，用的是一套在中小型医疗信息化里特别稳的组合：SpringBoot + Vue + MyBatis + MySQL。它覆盖了门诊挂号、医生接诊、药房发药、收费结算、住院管理、系统权限这些社区医院的核心场景，前后端分离，源码完整，很适合正在做毕业设计、准备找实习项目、或者想系统梳理一遍 Java 全栈开发流程的朋友拿来当蓝本。

我拿到这套源码之后，没有急着双击启动，而是先把整个项目从数据库到控制器再到前端页面完整捋了一遍。说句实在话，这类业务系统的难度不在某个框架用得多花哨，而在表结构设计、状态流转控制、还有前后端接口约定这些“软功夫”上。这篇文章我就把我梳理出来的架构思路、核心模块拆解、本地运行步骤和排坑记录全部写出来，顺便把一些热门的衍生问题——比如 MyBatis 缓存怎么用才不会留坑、Vue 动态路由怎么设计、MySQL 连接报 SSL 错误怎么快速解决——一次讲清楚，帮你省掉几天的摸索时间。

1. 项目整体拆解与架构设计思路

1.1 为什么这套技术栈能成为“企业级常青树”

先说结论：这套组合不是最新的，但它是目前找工作、做项目、上生产环境时面试官和业务方认可度最高的一套。

SpringBoot 的核心价值在于“自动装配”和“约定优于配置”。你不需要写一堆 XML 去配置事务、数据源、拦截器，依赖引入 starter 之后，大部分东西开箱即用，内嵌 Tomcat 也让部署变成一个 java -jar 的事。对于社区医院这种 IT 运维力量薄弱的场景，这个特性太重要了——升级、回滚、迁移的成本都低。

Vue 的优势在交互层的开发效率。社区医院的页面数量不多，但每个页面里都有大量的表单、弹窗、联动校验，比如挂号时要选科室再选医生、开处方时要按药品分类筛选库存。Vue 的响应式数据和组件化开发，能把这些复杂 UI 快速拆成一个个可复用模块。而且 Vue 的学习曲线比很多前端框架平缓，团队成员上手快。

MyBatis 是这套组合里最有争议但也最实用的一个选择。相比 JPA/Hibernate，MyBatis 把 SQL 的控制权完全交还给你。医院系统里有大量复杂的多表关联查询、统计报表 SQL，用 MyBatis 写出来的 SQL 你能一眼看明白执行计划、能手动优化索引命中，而 JPA 在某些复杂查询下生成的 SQL 会让你无从下手。社区医院的数据量还没到需要上中间件的程度，MySQL 完全扛得住，经济成本和技术维护成本都是最低档。

1.2 系统功能模块与核心业务流梳理

这套系统的功能模块，我建议先按“患者就诊主链路”去理解，而不是按菜单死记：

• 挂号管理：患者建档、选择科室/医生/号别（普通号、专家号）、生成挂号记录。这个模块是整条链路的起点。
• 医生工作站：医生查看候诊列表、接诊、书写诊断、开具处方（药品/检查/检验）。这是业务复杂度最高的地方。
• 药房管理：药品入库、库存管理、发药/退药、库存预警。处方开具后要和库存做联动校验。
• 收费结算：挂号费、药品费、检查费、住院费用的收取与退费。这个模块直接和“钱”相关，事务控制必须严格。
• 住院管理：入院登记、床位分配、医嘱执行、出院结算，属于相对独立的闭环。
• 系统管理：用户、角色、菜单、权限（RBAC），还有基础数据维护（科室、医生排班、药品字典）。
• 统计报表：门诊量、收费汇总、药品消耗等报表，一般用 ECharts 展示趋势图。

一条典型的主链路是：患者建档 → 挂号 → 候诊 → 医生接诊开方 → 收费处缴费 → 药房发药 → 患者离院。这个过程涉及至少 4 个不同角色的操作系统，任何一环的状态不对，都会造成“病人来回跑”的体验问题。所以源码里对每个单据都设计了明确的状态字段，比如挂号单有“待就诊/已就诊/已退号”，处方有“待收费/已收费/已发药/已退药”。这个设计思路很值得学习——医疗系统的核心不是 UI 好不好看，而是状态流转严不严谨。

1.3 前后端分离到底怎么拆

这套源码采用典型的前后端分离架构：后端只提供 RESTful API，前端用 Vue 构建单页应用（SPA）通过 Axios 调用接口。这样做的好处是前端开发和后端开发可以并行，部署上也可以把前端静态文件丢到 Nginx，后端接口单独跑。

但分离架构也有代价——接口约定和鉴权方案必须前置设计好。这套源码里统一用了 JSON 格式的响应体，大概是{ code: 200, message: "success", data: {...} }这种结构，前端在 Axios 响应拦截器里统一判断 code，而不是每个页面各自写 try-catch。鉴权则采用 JWT，登录成功后端返回 token，前端存储后每次请求在请求头带Authorization: Bearer <token>，后端通过拦截器校验。这套方案虽然简单，但在社区医院这种体量下完全够用，而且实现清晰，特别适合学习。

2. 核心技术难点与方案取舍

2.1 SpringBoot 后端的分层设计与事务控制

后端代码我建议你用“从外到内”的顺序去读：Controller → Service → Mapper，这是 Spring Boot 项目最标准的经典三层架构。Controller 只做参数接收和结果包装，不写业务逻辑；Service 层承载核心业务，处理事务边界；Mapper 层对应 MyBatis 的数据库访问接口。

这里我要重点强调事务控制。拿“收费结算”来说，一次缴费动作至少涉及三张表的修改：更新挂号单状态为已缴费、插入一条收费流水、如果是药品处方还要减库存。这三步必须放在同一个事务里，任何一步失败都要整体回滚。源码里在 Service 方法上用了@Transactional(rollbackFor = Exception.class)，这个细节很多人会忽略——默认情况下事务只在遇到 RuntimeException 时才回滚，如果你抛的是自定义检查异常，不加 rollbackFor 会导致事务不生效，钱收了库存却没扣，这种 bug 在医疗系统里是非常严重的事故。

还有一个容易被忽略的点是统一异常处理。源码里有一个@RestControllerAdvice全局异常处理器，把业务异常、参数校验异常、未知异常分别包装成统一的响应体返回给前端。这样做的好处是前端只需要在拦截器里处理 HTTP 200 但 code 非 200 的情况，逻辑非常干净。

2.2 Vue 前端路由与权限控制的工程化实践

Vue 部分最值得研究的是路由设计。社区医院系统有医生、药师、收费员、管理员等多种角色，不同角色看到的菜单完全不一样。如果把所有路由写死在前端，用户通过 URL 直接访问就能越权，这是安全漏洞。所以这套源码用的是动态路由方案：

1. 用户登录后，后端根据角色返回菜单/权限标识列表。
2. 前端用router.addRoute()动态注册当前用户有权限访问的路由。
3. 菜单根据动态路由自动生成。
4. 路由守卫里再校验一遍，没有权限直接跳转 404 或登录页。

这个方案比“写死路由 + 按钮级 v-if 控制”要安全得多。我在实际项目里还见过一种更细的权限控制——后端接口也做权限校验，前端只是隐藏入口，真正的是后端拦截器里比对角色标识。这套源码如果没做到接口级权限校验，我建议你自己补上：在拦截器里解析 JWT 后取出角色，通过@RequiresPermissions之类的自定义注解做方法级控制，这属于医疗系统上线前必须补的“安全底线”。

前端还有一个关键工程化配置是 Axios 拦截器。请求拦截器统一附加 token，响应拦截器统一处理 code 非 200 的情况、token 过期自动跳登录页。这些代码看起来很不起眼，但能避免每个页面都写重复的错误处理逻辑，也让代码量大幅下降。

2.3 MyBatis 持久层的高级细节：缓存、TypeHandler 与动态 SQL

MyBatis 这块能聊的细节非常多，我挑三个面试和实战都绕不开的点来讲。

第一个是缓存机制。MyBatis 默认开启一级缓存（SqlSession 级别），同一个 SqlSession 内两次相同的查询会命中缓存，不查数据库。这本身是性能优化，但在多表关联场景下有个经典坑：如果你先查了用户列表（联表查出带角色名称），中间别的操作修改了角色表，再查用户列表时命中一级缓存，拿到的还是旧的角色名称。解决办法很简单——涉及多表更新的业务方法上不要共用同一个 SqlSession，或者对更新操作显式调用sqlSession.clearCache()。二级缓存（Mapper 级别）默认关闭，我建议生产环境不要轻易开，尤其多表 join 时缓存失效策略很难控制，容易查出脏数据，这是很多人面试被问倒的地方。

第二个是 TypeHandler。MyBatis 内置的类型转换覆盖了大部分基础类型，但像 LocalDateTime 与数据库 datetime 的映射、Java 对象与 JSON 字符串的互转、枚举类型的存储，都需要自定义 TypeHandler。这套源码里如果有“诊断结论快照”这类字段，通常是存成 JSON 字符串，用自定义 TypeHandler 实现Result和Parameter的自动转换。写 TypeHandler 记住要实现setNonNullParameter和getNullableResult两个核心方法，并在 mybatis 配置里注册。

第三个是动态 SQL。医院的查询条件几乎都是动态的：按时间范围、按科室、按医生、按患者姓名、按是否退费……用<if>、<where>、<foreach>组合是实现条件查询的标准玩法。有一点要提醒：<foreach>在批量插入时虽然方便，但一次插入超过几百条性能会明显下降，建议分批插入（比如 500 条一批）。还有<if>里的 test 条件如果拼错，会出现“某条查询条件永远不生效”这种隐蔽 bug，排查时第一件事就是打开 SQL 日志输出，看真正执行的 SQL 是什么样。

2.4 MySQL 表结构设计与索引规划

数据库设计是这种项目里“上限最高、也最容易翻车”的部分。我拿到库表第一件事是看主键策略和索引设计。医疗系统的表有一个共同特点：核心业务表（挂号、处方、收费流水）数据量大、查询条件多，但写入量相对可控。所以设计上要注意几点：

• 主键建议用数据库自增或雪花 ID，避免 UUID 作为主键（随机顺序会导致 B+ 树频繁页分裂，写入性能受损）。
• 外键在业务层面控制，数据库里尽量不建物理外键，原因很简单：社区医院系统需要频繁做批量导入、历史数据归档，物理外键会锁表、限制操作。
• 索引设计要贴合查询场景。比如挂号表最常见的查询是“按日期 + 科室查当天的号源”，那(register_date, department_id)联合索引就非常关键。收费流水表常见的查询是“按收费员 + 日期对账”，则适合(operator_id, create_time)联合索引。
• 日期字段一定是 datetime 或 timestamp，别用字符串存日期，否则范围查询走不了索引，这个错我在真实项目里见过太多次。

这里还顺带说一个 MySQL 8.0 的坑：如果安装的是 8.x 以上版本，JDBC 连接串里要显式加上serverTimezone=Asia/Shanghai，否则驱动会把服务器时区映射成 UTC，查出来的时间比实际慢 8 小时，对医院系统的“对账”功能来说就是灾难。后面我会在问题速查表里再说几个类似的坑。

3. 完整实操：从环境搭建到前后端联调

3.1 本地开发环境准备

这一步看着基础，但很多人卡住的第一关就在这里。我列一下我验证过的环境组合，照着装基本不会有版本冲突：

Maven 的 settings.xml 里加阿里云镜像这段配置，我相信所有 Java 开发都写过，但新手容易漏掉mirrorOf写成central还是*的区别。我建议直接写<mirrorOf>*</mirrorOf>，把所有仓库请求都指向镜像，能省大量时间。

MySQL 安装有个高频问题：Navicat 连接 MySQL 8.0 提示无法连接。这是因为 MySQL 8.0 默认认证插件是caching_sha2_password，老版本 Navicat 不支持。解决方式是在 MySQL 里执行ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';，或者升级 Navicat 16+。如果提示 SSL 连接错误，就在连接参数里选“不使用 SSL”。这个问题每年都能拦住无数新手，放在这里先排掉一个雷。

3.2 数据库初始化与核心表结构说明

源码里通常带一个sql目录或根目录下的.sql文件，用 Navicat 导入或者命令行source xxx.sql执行即可。导入后建议先看这几张核心表：

• sys_user：系统用户表，包含用户名、密码（通常是 MD5 加盐）、角色 ID。
• reg_registration：挂号表，包含患者 ID、科室 ID、医生 ID、号别、状态、挂号时间。
• doc_prescription：处方主表，关联挂号记录，包含诊断、开方医生、开方时间。
• doc_prescription_item：处方明细表，关联药品 ID、数量、单价、用法。
• pha_drug_info：药品表，包含药品编码、名称、规格、库存、零售价。
• fin_payment：收费表，包含收费类型、金额、操作员、关联业务单号。

我特别建议你关注fin_payment表的结构，它通常会有“关联类型 + 关联单号”两个字段，这样一张表就能同时承接挂号费、药品费、检查费多种收费来源，而不是每种费用建一张表。这种“通用扩展字段”的设计思路在实际工作中非常实用。

3.3 后端项目结构与核心配置

后端项目用 IDE（IDEA 推荐）打开后，先看application.yml。核心配置大概是：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.hospital.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这里有两个关键配置我单独解释一下。

useSSL=false是因为 MySQL 8.0 默认尝试 SSL 加密连接，本地开发时经常因为证书问题报Communications link failure或者 SSL 相关错误。加上这个参数直接关掉，性能还更好。allowPublicKeyRetrieval=true是因为 8.0 驱动默认不允许从服务器获取公钥，不加可能报Public Key Retrieval is not allowed。

log-impl配置成StdOutImpl后，每次执行的 SQL 和参数会完整打印到控制台，这对排查动态 SQL 拼接问题是神器。我调试 MyBatis 复杂查询时几乎必开这个配置，定位到问题后再关掉。

然后直接运行main方法启动后端。如果端口被占用，改server.port即可，或者杀掉占用进程：Linux/macOS 用lsof -i:8080，Windows 用netstat -ano | findstr 8080。

3.4 前端项目运行与接口联调

前端项目用终端进入目录（通常是vue-web或frontend），依次执行：

npm install npm run dev

npm install如果慢，先设置淘宝镜像源：npm config set registry https://registry.npmmirror.com。这一步能帮你节省大量时间，尤其是 Windows 上还容易因为 node-sass 编译报错——如果项目用的是旧版 node-sass，建议直接换用sass（dart-sass），或者把 Node 版本降低到项目要求的版本。

启动后前端默认跑在http://localhost:8081，这里有个关键配置：vue.config.js或vite.config.js里的 devServer 代理。因为前端是 8081、后端是 8080，跨域问题必须通过代理解决：

devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求/api/login时会自动转发到后端的8080/api/login，浏览器层面看不到跨域，也就不需要后端额外配置 CORS。等你理解了这个机制，再看网上那些“前端 axios 跨域报错怎么办”的问题，基本一眼就能看出答案。

验证联通性的最好方式是直接登录。用源码自带的初始管理员账号（通常是 admin/admin123）登录，如果能在控制台看到后端打印的 SQL，同时浏览器正常跳转到首页，说明前后端联调已经通了。

3.5 快速部署：把 Vue 打包进 SpringBoot

本地开发没问题之后，很多人想把前端打包后塞进 SpringBoot 打成单 jar，这样部署到一台服务器上就完事，省去单独装 Nginx。这个需求非常常见，做法也不复杂：

npm run build

打包后前端目录下生成dist文件夹，把里面的内容全部复制到后端项目的src/main/resources/static/目录下，重新执行mvn package。这样 SpringBoot 启动后，访问http://ip:8080就是前端页面，/api/**的请求仍然由后端 Controller 处理。

需要注意两点：第一，前端路由如果是 history 模式，刷新二级页面会出现 404，因为 SpringBoot 默认没有把非 API 请求转发到index.html。解决办法是写一个简单的 Controller 或者过滤器，把所有非/api开头的路径转发到forward:/index.html。第二，这种“一体化部署”适合小规模使用，真正上线建议还是前后端分离部署，静态文件交给 Nginx，后端负责 API，各司其职。

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

4.1 环境与安装类问题速查表

这里我特别想展开说“SpringBoot 版本太高”这个坑。现在很多教程默认你用的是最新版 SpringBoot 3.x，但它要求 JDK 17，而且原来javax.servlet全部改成了jakarta.servlet。如果源码是基于 2.x 开发的，你拿 3.x 硬跑，几乎所有依赖 Spring 的老项目代码都要改包名，工程量直接翻倍。所以拿到源码第一步就是看pom.xml里的 spring-boot-starter-parent 版本，然后匹配对应的 JDK。这个原则适用所有老项目：不要盲目升级依赖版本，能跑起来的旧版就是好版本。

4.2 MyBatis 高频踩坑与排查实战

SQL 日志打印不出来。确认application.yml里log-impl配置是StdOutImpl，同时检查是不是用了 logback 等日志框架把 MyBatis 的日志级别压掉了。如果还不行，可以在 mapper 接口上application.yml里配置对应包名的日志级别为 debug。

Mapper XML 找不到。启动报Invalid bound statement (not found)，多数是mapper-locations配置没生效。检查 XML 文件是否在resources/mapper目录下，以及pom.xml里是否把 XML 排除在打包范围之外。Spring Boot 的 maven 插件默认只打包 resources 下的文件，如果你把 XML 放在src/main/java下的 mapper 目录里，必须额外配置 resources 节点把 XML 包含进去，这个坑几乎每个用 MyBatis 的人都会踩一次。

批量插入太慢。如果用<foreach>拼一个超大 SQL，MySQL 对单条 SQL 的长度有限制（max_allowed_packet，默认 64M），而且整体性能并不好。实操中我习惯用 MyBatis 的ExecutorType.BATCH，或者手动拆成每 500 条一批执行，实测插入 5 万条数据的时间从几十秒降到一两秒。

缓存导致数据不同步。前面提过的一二级缓存问题，在医疗系统里尤其要小心。比如医生给病人开了新药，药品库存表更新了，但如果收费模块的查询命中了旧缓存，页面上显示的可售库存还是旧的，就会导致超卖。我的习惯是：所有写操作所在的 Service 方法上，主动加上@Transactional并且避免跨 Mapper 级联查询走缓存；对实时性要求高的数据，直接设置<cache>为不启用，或者用useCache="false"。

4.3 Vue 与 SpringBoot 联调时的经典错误

跨域（CORS）报错。前端 axios 请求被浏览器拦截，报No 'Access-Control-Allow-Origin' header。推荐用 devServer 代理解决，后端不用动。如果坚持用 CORS，后端要配置跨域过滤器，并且注意allowCredentials(true)时allowedOrigin不能写*，必须指定域名。

token 过期后页面白屏。Axios 响应拦截器里要统一判断 HTTP 401 或业务 code 401，然后清除本地用户信息、跳转登录页。很多项目只在前端路由守卫里判断 token 是否存在，忽略了 token 过期的情况，导致用户停留页面半天，点操作才发现所有请求都失败，体验极差。

日期格式不一致。后端返回LocalDateTime时，Jackson 默认序列化出来是一长串带 T 的格式，前端格式化很麻烦。建议后端统一配置spring.jackson.date-format=yyyy-MM-dd HH:mm:ss和time-zone=GMT+8，前端展示直接用格式化函数。这个统一约定要放在项目初期定好，否则后期几十个接口挨个修格式会累死人。

路由 history 模式刷新 404。开发环境还好，部署后如果 Nginx 配置没写try_files $uri $uri/ /index.html;，用户刷新页面就是 404。这是部署阶段最高频的问题，没有之一。

4.4 部署上线阶段我踩过的几个真实教训

这个系统最终要部署到生产环境（比如医院内网 Windows 服务器）时，有几个细节值得单独拎出来说。

第一，数据库密码不要写在 application.yml 明文里。社区医院的内网虽然相对封闭，但运维人员流动大，泄露风险不小。我一般用 Jasypt 对密码加密，或者从环境变量里读取。这套源码如果直接部署，我会建议至少把密码改成独立账号并限制 IP 访问。

第二，生产环境要关掉 SQL 日志输出。开发时开着StdOutImpl方便排查，但生产环境每打印一条 SQL 都消耗 IO，而且可能把病人信息打到日志文件里，涉及隐私合规问题。

第三，备份策略比系统本身更重要。医院系统的数据价值极高，库表数据一旦丢失，业务直接停摆。我的习惯是：MySQL 每天凌晨做一次全量备份 + binlog 增量备份，备份文件保留至少 30 天，并且不要把备份存放在数据库所在的同一台机器上。这个习惯在社区医院这种“服务器就一台、出了问题没人救”的场景里尤其救命。

5. 项目扩展方向与个人体会

5.1 这套系统还能往哪些方向扩展

源码跑通只是起点，真正有价值的是在这个基础上延伸能力。我根据自己的项目经验，列几个比较典型的扩展方向：

文件存储与影像展示。社区医院通常需要存储患者检查报告、CT 影像、病历附件。本地磁盘存储不够灵活，业界常用 MinIO 这种对象存储来做，SpringBoot 整合 MinIO 的流程非常标准：引入依赖、配置 endpoint/accessKey/secretKey、封装上传下载服务。如果涉及健康宣教视频，还会牵出 m3u8 流媒体播放这类需求，Vue 端可以用 video.js 等播放器处理，后端则负责转流或对接流媒体服务。

消息通知与排队叫号。收费完成、药房发药这些事件可以通过 ActiveMQ 或 RabbitMQ 做异步通知，大厅叫号大屏实时刷新。给 SpringBoot 整合 ActiveMQ 的过程不复杂，但引入消息中间件需要考虑消息可靠性和重复消费的问题，如果只是单纯叫号提醒，其实用 WebSocket 更轻量，没必要上 MQ。

智能搜索与病历分析。病历数据积累到一定规模后，可以做基于 HanLP 等中文分词工具的搜索和辅助分析。比如输入“高血压 三年”就能检索出相关病历。这个方向很有意思，但属于加分项而不是刚需，先把基础系统做稳再考虑。

报表可视化升级。源码自带的统计页面如果用 ECharts 做了基础图表，还可以进一步做管理驾驶舱：门诊量趋势、科室收入占比、药品消耗 TOP10、医生工作量对比等。这些数据全部可以从现有表结构里聚合出来，不需要改库，只需要写复杂的 SQL 和前端图表配置。

5.2 基于这套源码的几点个人建议

最后聊点掏心窝的话。我前后看过不少类似的“企业级管理系统源码”，也帮人排查过好多基于这种项目二次开发的问题。有几个体会想分享给准备拿这套源码做事的你。

第一，先把业务流程图手画一遍再动代码。不要一上来就打开 IDEA 到处点。你要做的第一件事是把挂号到发药这条主链路用纸笔画出来，标清楚每个环节操作哪个模块、改变哪些表的状态。业务理顺了，代码读起来事半功倍。

第二，一定要亲手改动一个功能。只看源码你很难真正掌握，哪怕只是给挂号表加一个“预约来源”字段，把页面、接口、SQL 全部通一遍，你对这个系统的理解会比看十遍源码都深。我见过太多人“跑通了”就说自己会了，一问细节全懵。动手改，是检验理解的唯一标准。

第三，做二次开发时保持向后兼容。如果你要在这个系统上接新的模块，尽量不要去改核心表的字段，而是通过扩展表、加关联关系实现。这个系统之所以设计得还算灵活，就是因为核心业务表的字段都是够用就好，你非要在挂号表上硬塞十个扩展字段，后期维护会让你痛不欲生。

第四，代码里养成留注释的习惯。这套源码本身的注释可能不够详细，你在读代码的时候顺手把你理解的逻辑写进去，对你后期复现、答辩、交接都有巨大帮助。别嫌麻烦，好记性不如烂笔头，在源码上写注释是在“接管”这个项目。

我在实际跑这套项目时最大的感受是：它不是一个炫技的项目，而是一个把企业级开发规范执行得比较到位的样板。分层清晰、状态流转严谨、接口约定统一，这些才是真正能在工作中保命的“内功”。你照着它把每个细节走一遍，SpringBoot、Vue、MyBatis、MySQL 这套全栈体系基本就通了。后面换任何业务系统，你会发现核心套路都差不多——无非是换一批表、换一套页面、换一些业务规则，而架构和工程化的东西，全都是相通的。