牙科诊所管理系统全栈实战：SpringBoot+Vue+MyBatis+MySQL深度拆解

牙科诊所管理系统这个项目，我从标题到源码完整过了一遍。先说结论：这是一套典型的SpringBoot+Vue+MyBatis+MySQL全栈架构的中小型企业管理信息系统，业务域清晰、模块边界完整，代码组织方式非常适合用来做毕业设计、简历项目，或者作为接私活时快速交付的底座。但如果你只是想跑起来看看界面，那太浪费了。这篇我会从业务建模、数据库设计、后端实现、前端落地的完整链路带你拆一遍，把里面值得细看的点全部抠出来。

1. 牙科诊所为什么需要Web管理系统：业务本质与需求拆解

1.1 诊所管理现场的真实痛点

牙科诊所和综合医院的信息化管理需求差异很大。综合医院讲究HIS、LIS、PACS这类大而全的系统，而牙科诊所通常几十到几百平米的规模，医生五到十五人，前台一到三人，管理的核心是三件事：患者、预约、诊疗记录。

去一家中等规模的牙科诊所观察一天就会发现，前台的工作状态基本是这样的：座机响个不停，一次性要接五六个预约电话，手里的纸质登记本翻来翻去，还要抽空回答微信上的复诊咨询。诊疗结束后医生口头交代几句医嘱，护士手写一个复诊卡片，患者下次来的时候那张卡片大概率已经找不到了。

这套系统解决的就是这些真实场景里的问题：把预约从电话本搬到线上，把病历从纸质变成结构化数据，把收费从模糊记忆变成可追溯记录，把库存从月底盘点变成实时预警。搞清楚这个业务场景，你才能真正理解代码里那些表为什么这样设计，字段为什么这样命名。

1.2 角色权限与核心业务流程

一套完整的企业级管理系统，角色权限一定是第一个要梳理清楚的。牙科诊所系统通常涉及四类角色：

核心业务链路其实只有一条：患者建档 → 预约/挂号 → 医生接诊 → 病历记录 → 诊疗计划 → 收费 → 复诊/回访。这条链路里的每一个节点都有明确的状态流转，这也是系统设计中最有技术含量的部分。

从这条链路上可以推断出系统的模块划分：患者管理、预约管理、诊疗/病历管理、收费管理、医生排班管理、库存管理、系统管理。每一块对应一组数据表和一组前后端页面。标题里说的是"完整版"，那这套源码里大概率这几个模块是齐全的，你在阅读源码时应该先按这个模块清单去核对，而不是漫无目的地从第一个文件往后翻。

1.3 模块边界与功能优先级

如果这个项目要作为你自己的作品来讲，模块边界比功能列表更重要。你不需要跟面试官说"我这个系统有20个功能"，你只需要说清楚"我是按预约-诊疗-收费这条主线来组织的，患者数据和业务数据分开管理"。

优先级上，预约冲突检测、诊疗记录的完整性、收费的准确性这三个功能是整个系统的生命线。预约冲突做不好，诊所前台用两天就会弃用；病历记录缺字段，医生不愿意用；收费对不上账，老板第一个不答应。所以在阅读源码时，这三个模块的实现细节值得重点研究，也是面试时最能体现深度的地方。

2. 技术选型这套组合为什么是经典答案：从场景反推技术

2.1 后端SpringBoot：中小型信息系统的默认正确答案

SpringBoot在这套系统里几乎是必然选择，不是因为它是"最先进的"，而是因为它是"最合适的"。SpringBoot的核心价值是约定大于配置——它把Spring生态里繁琐的XML配置全部收敛成自动配置，让你用最少的配置启动一个生产可用的Web应用。

对牙科诊所这种并发量不高（同时在线用户几十人级别）、逻辑复杂度中等（业务规则清晰但没有海量计算）的系统来说，SpringBoot的启动速度、开发效率、生态成熟度都是最优解。更重要的是，招人容易。任何一个学过Java的开发者都能快速上手SpringBoot项目，这对诊所这种没有专职IT团队的单位来说非常重要。

看SpringBoot源码时有个小技巧：去看pom.xml的依赖版本管理。父工程（spring-boot-starter-parent）帮我们锁定了各依赖版本，避免了版本兼容问题。如果你自己去搭一套同类系统，直接复用这个依赖清单能省掉大量踩坑时间。

2.2 前端Vue：管理后台场景的务实之选

Vue在管理后台领域的地位和SpringBoot在后端领域几乎一样——不是因为性能最好，而是因为上手曲线平滑、中文生态完善、团队招聘容易。牙科诊所系统的前端本质是一套"表单密集型"应用，主要集中在患者登记、预约操作、病历录入、收费确认这些高频交互上。

Vue的响应式数据绑定在表单场景下特别好用：用户输入患者姓名，页面上关联的年龄、性别、历史病历区域能自动联动更新。组件化开发则让每个业务模块都能拆成独立组件，比如"患者信息卡片"这个组件可以在预约页、病历页、收费页三处复用，只需传入不同的患者ID。

如果你在源码里看到views目录下的结构，建议按这样的思路去理解：路由对应页面，页面由组件拼装，组件通过API调用后端。这个"三明治"架构是整个Vue前端项目的骨架，理解了它，任何管理后台的前端代码对我们来说都没有秘密。

2.3 持久层MyBatis：精细控制SQL的长期价值

MyBatis在这个项目里承担的是ORM（对象关系映射）职责。相比JPA/Hibernate的"全自动"方案，MyBatis是"半自动"的——SQL由开发者自己写，框架只负责参数映射和结果集映射。

对于牙科诊所系统来说，这种半自动模式有实打实的好处。比如病历查询这个场景，你可能需要根据患者姓名、电话、就诊日期、医生姓名、诊断结果等多个条件动态拼查SQL，MyBatis的<if>标签可以优雅地处理这种动态场景。再比如收费统计报表，这种SQL必然比较复杂，需要多表联查+分组聚合，用MyBatis可以精确控制SQL的每一个细节。

从源码里你大概率会看到两个MyBatis相关的目录：mapper（接口）和mapper/xml（SQL映射文件）。接口负责定义方法签名，XML负责写SQL语句。这种"接口+XML"的方式一开始会让人觉得繁琐，但维护长了你会发现，它能让你在上线半年后依然清楚地知道每个方法执行的到底是一条什么SQL——这是JPA的自动生成SQL做不到的。

2.4 数据库MySQL：规模匹配才是硬道理

MySQL在这套系统里是存储底座。牙科诊所的数据量级大概是这样的：患者几万到几十万、预约记录每年几十万条、病历记录每年几万条。这个量级，MySQL单实例能力绰绰有余，不需要引入分库分表、读写分离这类复杂度。

看数据库脚本时重点关注三类东西：一是表结构，看字段设计是否合理、命名是否规范；二是索引，看高频查询条件是否建立了合适的索引；三是外键约束和唯一的逻辑约束，比如一个时段同一医生不能有两个预约，这类约束是在数据库层做还是在应用层做。

尤其注意数据库字符集，项目中一般会统一设置为utf8mb4。这是MySQL针对移动端和表情符号存储的必要配置，很多老系统还是在用utf8，存储患者微信昵称里的emoji时会产生乱码。看这套源码的时候可以顺手确认一下。

3. 数据库设计是这类项目的灵魂：表结构拆解与状态机设计

3.1 核心表结构与ER关系

从业务链路反推，这套系统至少要有下面这些核心表：

• patient：患者基本信息表。字段包括姓名、性别、出生日期、联系电话、身份证号、过敏史、首次就诊日期等。
• doctor：医生信息表。包含姓名、职称、科室（正畸/种植/修复等）、排班偏好等。
• appointment：预约表。核心字段是患者ID、医生ID、预约日期、时间段、预约类型（初诊/复诊）、状态（待接诊/已完成/已取消）。
• medical_record：病历表。主表记录就诊时间、主诉、诊断、医嘱；如果有子表设计，则牙位检查、治疗计划等会拆成子表。
• treatment_item：治疗项目字典表。比如"根管治疗""洁牙""种植体植入"等，关联价格。
• charge_record：收费记录表。记录患者每次缴费的项目、金额、支付方式。
• inventory_item：耗材/药品库存表，包括名称、规格、库存量、预警阈值。
• sys_user / sys_role / sys_user_role：系统用户、角色、关联表。

主外键关系上，患者和预约是一对多，预约和病历是一对一（一次预约对应一次就诊记录），患者和收费是一对多，医生和预约是一对多。把这些关系理清楚，整个数据库设计就基本掌握了。

3.2 预约时间冲突与状态机的设计精髓

我认为这套系统里最值得学习的两个设计点是预约时间冲突检测和状态流转控制。

预约时间冲突检测的实现思路是：在插入/更新预约记录时，先查同一医生在同一日期时段内是否已有未取消的预约。这个逻辑可以在两层实现——数据库层加唯一约束（对doctor_id、appointment_date、time_slot、status做联合唯一索引，但这会把"已取消"的记录也纳入冲突），或者应用层先查后插。推荐的方式是应用层查重+数据库联合索引兜底，两者结合。

状态机设计上，预约状态通常是：待确认 → 已确认 → 已完成 / 已取消 / 爽约（未到）。诊疗记录状态可以是：草稿 → 已提交 → 已归档。这种状态流转不能靠开发者在代码里随手改字段值，而应该在Service层封装明确的业务方法，比如confirmAppointment()、cancelAppointment()、completeVisit()，每个方法内部校验当前状态是否允许流转到目标状态。

如果你在源码里看到类似的Service方法设计，说明作者有基本的领域建模意识。如果所有地方都是直接appointment.setStatus(3)这种写法，那就只能算"能跑"的代码，不算是"设计良好"的代码。你完全可以以此判断这套源码的水平。

3.3 关键SQL：查询统计里藏着多少细节

数据库设计的水平，看几个关键SQL就能分辨出来。

比如预约查询：按日期范围+医生+状态组合查询预约列表，需要appointment表joinpatient表取出患者姓名和电话。这里要注意的是索引设计——appointment_date字段必须有索引，doctor_id和status也应该在联合索引里。

再比如收入统计：按月份统计诊所收入，SQL大概是：

sql复制SELECT DATE_FORMAT(create_time, '%Y-%m') AS month,
       SUM(amount) AS total_amount
FROM charge_record
WHERE create_time >= '2024-01-01' AND create_time < '2025-01-01'
GROUP BY DATE_FORMAT(create_time, '%Y-%m')
ORDER BY month;

这类SQL在MySQL里会用到create_time索引的范围扫描，然后做分组聚合。数据量大时（超过百万条），DATE_FORMAT会导致索引失效，需要改为create_time BETWEEN '2024-01-01' AND '2024-01-31'这种写法来配合索引。项目初始数据量不大时可能看不出区别，但这是面试中常见的优化点。

4. 后端实现要点：从MyBatis动态SQL到事务边界

4.1 Mapper接口与XML映射：命名规范决定可维护性

这套系统的后端核心是Controller层调用Service层，Service层调用Mapper接口，Mapper接口通过XML文件执行SQL。这条调用链上最容易出现的问题是命名混乱导致的可维护性崩塌。

好的命名习惯是：查询用selectXxx、插入用insertXxx、更新用updateXxx、删除用deleteXxx，参数带上实体类型，返回结果明确。比如PatientMapper.selectById(Long id)、AppointmentMapper.selectByDoctorAndDate(Long doctorId, String appointmentDate, Integer status)。

看XML时，resultMap很关键。当数据库字段名（如patient_name）和Java属性名（如patientName）不一致时，MyBatis通过resultMap做映射。有的项目偷懒把数据库字段名设置成和Java属性名完全一致（全小写驼峰），这样连resultMap都不用写了，但这种做法在复杂联查时会让SQL难以理解。规范的resultMap是值得模仿的写法。

XML里另一个值得注意的点是<sql>代码片段复用。比如病历查询里经常要查id, patient_id, doctor_id, visit_date, diagnosis, treatment_plan, created_time这一组字段，这段SQL会在多个查询里重复出现，用<sql>标签定义一次，各查询<include>引用，能明显减少SQL冗余。

4.2 动态SQL：解决复杂查询场景的利器

牙科管理系统中最典型的动态SQL场景就是多条件组合查询。比如预约列表页，用户可能选择只看某个日期段、只看某个医生、只看某个状态，也可能什么都不选直接查全部。

如果在Java代码里用StringBuilder拼SQL，拼到后期你会想哭；如果对每个组合都写一条完整SQL，那组合数量会让你爆炸。MyBatis的<where>+<if>组合能优雅解决：

xml复制<select id="selectAppointments" resultMap="AppointmentResultMap">
    SELECT a.*, p.name AS patient_name, p.phone AS patient_phone
    FROM appointment a
    LEFT JOIN patient p ON a.patient_id = p.id
    <where>
        <if test="doctorId != null">
            AND a.doctor_id = #{doctorId}
        </if>
        <if test="startDate != null and startDate != ''">
            AND a.appointment_date &gt;= #{startDate}
        </if>
        <if test="endDate != null and endDate != ''">
            AND a.appointment_date &lt;= #{endDate}
        </if>
        <if test="status != null">
            AND a.status = #{status}
        </if>
    </where>
    ORDER BY a.appointment_date DESC, a.time_slot ASC
</select>

<where>标签很聪明：如果内部条件都不成立，它不会生成WHERE关键字；如果有条件成立，它会自动去掉第一个AND。这样你就不必在Java层反复判断"这个条件要不要拼AND"。

还有<foreach>标签，用于批量操作。比如批量查询多个患者：

xml复制<select id="selectByIds" resultMap="PatientResultMap">
    SELECT * FROM patient
    WHERE id IN
    <foreach collection="ids" item="id" open="(" separator="," close=")">
        #{id}
    </foreach>
</select>

注意这里有个经典的坑：collection属性名必须和方法参数名一致，如果没有用@Param("ids")注解，MyBatis识别不到。看源码时如果发现某处批量查询报错，大概率就是这个问题。

4.3 事务边界：跨表写入最容易出错的环节

诊疗过程中的数据写入往往是多表联动的：生成病历记录、更新预约状态、可能还要生成收费单。这个"一次操作涉及多张表"的场景，是事务管理发挥价值的地方。

Spring的@Transactional注解就能满足需求。放在Service方法上，方法内所有数据库操作共享同一个事务，任何一个步骤失败，前面已执行的操作全部回滚。

这里要注意三个坑：

• 第一个是事务失效。同一个类内部方法调用时（A方法调B方法，AB都在同一个类里），@Transactional可能不生效，因为Spring事务基于AOP代理，内部调用不走代理。如果你在源码里看到Controller直接调用了多个Mapper方法而不是通过Service，那基本可以断定这个项目的事务保护是缺失的。
• 第二个是事务粒度。不要把整个查询列表的方法也加上事务，只对写操作加。查询加事务会增加数据库连接占用时间，并发高的时候容易拖垮连接池。
• 第三个是异常类型。@Transactional默认只在运行时异常时回滚，如果方法里catch了异常并且不抛出，事务是不会回滚的。新手经常在这里栽跟头——明明加了注解，但异常被吞掉后照样提交了数据。

4.4 批量插入的性能问题

热搜词里有一条是"mybatis plus 批量插入"，说明很多人在这块遇到过性能瓶颈。牙科管理系统里典型的批量插入场景是批量导入患者Excel数据和批量生成诊疗计划明细。

MyBatis的批量插入有两种写法，性能差异巨大。

第一种是循环单条插入：

java复制for (Patient patient : patientList) {
    patientMapper.insert(patient);
}

这种方式每条记录执行一次insert，数据库连接往返N次，1000条数据可能会有几秒到十几秒的耗时。

第二种是MyBatis的批量插入：

xml复制<insert id="insertBatch">
    INSERT INTO patient (name, gender, birth_date, phone, address)
    VALUES
    <foreach collection="list" item="item" separator=",">
        (#{item.name}, #{item.gender}, #{item.birthDate}, #{item.phone}, #{item.address})
    </foreach>
</insert>

一条SQL插入全部数据，1000条可能在几百毫秒内完成。但要注意SQL长度限制，max_allowed_packet默认是64MB，如果单条SQL太长，需要分批处理，比如每500条一批。

另外还要注意，批量插入通常不能用<insert>的useGeneratedKeys属性批量返回自增主键（不同数据库支持情况不同，MySQL在foreach的批量插入中可以返回第一个插入ID，但不会返回全部ID）。所以如果后续逻辑需要用到新插入记录的主键，可能需要调整插入策略。

5. 前端Vue落地细节：管理后台的组件化与状态管理

5.1 项目结构与路由规划

Vue前端项目打开后，第一眼看目录结构：

text复制src/
├── api/            # 接口请求封装
├── assets/         # 静态资源
├── components/     # 通用组件
├── router/         # 路由配置
├── store/          # Vuex状态管理
├── styles/         # 全局样式
├── utils/          # 工具函数
├── views/          # 页面视图
├── App.vue
└── main.js

路由规划上，管理后台一般遵循"登录页+主框架+业务模块"的层级。主框架通常是一个布局组件Layout.vue，包含左侧菜单栏、顶部导航栏、主体内容区（router-view）。业务页面都挂在这个布局之下，只有登录页是独立的。这种设计的好处是菜单和顶栏只写一次，切换路由时只刷新内容区。

看路由配置时重点关注路由守卫。正常情况下router.beforeEach里会做登录态校验：如果未登录，跳转到登录页；如果已登录但不是管理员，访问管理页面时拦截并提示。这是"企业级"系统的基本修养。

5.2 登录态管理与axios拦截器

Axios是Vue项目里最常用的HTTP库。看源码时重点看两个文件：utils/request.js（axios实例封装）和api/目录下的接口定义。

request.js里一般做了这么几件事：创建axios实例、设置baseURL、请求拦截器（在请求头里加token）、响应拦截器（统一处理错误码，比如401跳转登录页，500弹错误提示）。

javascript复制// 响应拦截器伪代码
service.interceptors.response.use(
  (response) => {
    const res = response.data
    if (res.code === 200) {
      return res.data
    }
    if (res.code === 401) {
      // token过期，清除本地登录态，跳转登录页
      store.dispatch('user/resetToken')
      router.push('/login')
      return Promise.reject(new Error('登录状态已过期'))
    }
    Message.error(res.msg || '系统错误')
    return Promise.reject(new Error(res.msg || '系统错误'))
  },
  (error) => {
    Message.error(error.message || '网络异常')
    return Promise.reject(error)
  }
)

封装到这个程度后，业务代码里只需要写login(username, password).then(res => {...})，不用关心token怎么带、错误怎么提示。

注意一个细节：token一般存在localStorage或sessionStorage中。放sessionStorage，浏览器关闭后登录态消失，适合诊所这种相对固定的办公场景；放localStorage，关闭浏览器后仍然保持登录，省去反复登录的麻烦，但安全性略低。源码里选哪种方案，你可以观察一下。

5.3 表格、表单与口腔专科视图的实现思路

管理后台的页面主要就两种：表格页和表单页。表格页展示列表数据，支持搜索、分页、排序；表单页负责新增、编辑数据。

Element UI的el-table组件加el-pagination分页组件是标配。看分页实现时注意一个细节：分页是后端分页还是前端分页。数据量大时必须后端分页——Vue页面请求current=1&size=10，后端返回total和records。数据量小（比如牙位图，只有32颗牙）就直接用前端数据渲染。

口腔专科的特殊性在牙位图——一张图上标记32颗恒牙的位置，用于可视化记录哪颗牙做了治疗。如果这套源码里有牙位图组件，值得好好研究。实现思路通常是：用<svg>或Canvas绘制32个牙位区域，每颗牙绑定状态（健康/龋齿/根管治疗/已拔除等），点击牙位弹出治疗操作菜单，选中状态通过Vue的数据绑定驱动。

这个组件是牙科系统区别于普通进销存系统的最大亮点，也是你在面试或展示项目时可以重点讲的部分。

6. 源码部署与踩坑实录：从环境配置到稳定运行

6.1 环境准备：版本号是对齐的第一步

拿到源码第一件事不是急着跑，而是核对环境版本。这套系统涉及四个核心环境的版本适配：

最容易踩的坑是SpringBoot版本和JDK版本不匹配。如果pom.xml里用的是SpringBoot 2.x，JDK 1.8是稳妥的；如果是SpringBoot 3.x，必须JDK 17以上。热搜里有一条"springboot jdk1.8打包到docker desktop"，本质就是版本匹配问题。

MySQL这里有一个特殊提醒：如果安装的是MySQL 8.0，驱动类名是com.mysql.cj.jdbc.Driver，连接URL需要加serverTimezone=Asia/Shanghai，否则时区报错。如果你在本地用5.7连不上，或者8.0连不上，先检查这两个配置。

6.2 后端配置文件与前端接口联调

后端核心配置都在application.yml或application.properties中。

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/dental_clinic?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai
    username: root
    password: yourpassword

mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.dental.entity
  configuration:
    map-underscore-to-camel-case: true

map-underscore-to-camel-case这个配置特别重要：开启后，数据库的patient_name字段能自动映射为Java的patientName属性，不需要每个字段都写resultMap。但如果有些SQL用了复杂的别名查询，还是需要显式的resultMap来兜底。

前端联调时,request.js里的baseURL要指向后端地址。常见的做法是用Vue CLI的代理：

javascript复制// vue.config.js
module.exports = {
  devServer: {
    port: 3000,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

本地启动前端后，浏览器访问localhost:3000，前端请求/api/patient/list会被代理转发到localhost:8080/api/patient/list。这样避免了跨域问题。

6.3 我在部署这套系统时遇到的三个典型问题

问题一：MyBatis绑定异常。

启动后访问接口报Invalid bound statement (not found): com.xxx.mapper.PatientMapper.selectList。排查步序：先检查XML文件的namespace是否和Mapper接口全限定名一致；再检查mapper-locations路径是否正确；最后确认编译后的target目录里有没有XML文件。前两个是配置问题，第三个是Maven构建没把XML打包进去，需要在pom.xml的<build>里配置resources标签，将src/main/java下的XML文件一并打包。

问题二：前端安装依赖时node-sass报错。

Node版本过新，node-sass编译不过。两步解决：把Node切换到14.x或16.x；或者把依赖从node-sass换成dart-sass（在package.json里把node-sass改为sass）。长期维护角度，建议换dart-sass，它不需要本地编译，纯JavaScript实现，跨平台更稳定。

问题三：MySQL插入中文乱码或emoji变问号。

根因是数据库连接字符串没有characterEncoding=utf8mb4，或者数据库本身的字符集不是utf8mb4。修复SQL：

sql复制ALTER DATABASE dental_clinic CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

如果已经建好的表也乱码，还需要改表：

sql复制ALTER TABLE patient CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

6.4 上线前必须做的检查项

项目跑通后，别急着上线，按这个清单过一遍：

• 默认密码强制修改：Admin密码不能是123456，普通用户初始密码也需要有修改机制。
• 数据库备份策略：MySQL定时mysqldump，至少保留最近7天的备份。
• 日志监控：SpringBoot的日志要落到文件，配置logback-spring.xml，按天切割，保留30天。
• 配置文件安全：application.yml里的数据库密码不要用明文，至少使用环境变量注入。
• 接口权限校验：检查每个Controller方法是否做了登录校验和角色校验，不能只在前端隐藏菜单。

7. 源码阅读顺序与二次开发进阶建议

7.1 推荐的源码阅读路线

这套系统的源码拿到手后，我建议按下面的顺序阅读，效率最高：

1. 先看数据库脚本（sql文件）。不用急着看懂每一张表，重点理解表命名规范、主外键关系、核心字段含义。这一步花半小时，后面看代码会快很多。
2. 再看pom.xml和application.yml，摸清技术栈版本、依赖清单、环境配置。
3. 进入后端代码，从entity（实体类）开始，对照数据库表理解字段映射。
4. 看mapper接口和XML，理解每个方法对应的SQL。
5. 看service层，理解业务逻辑的组织方式。
6. 看controller层，理解接口如何暴露给前端。
7. 进入前端，从router开始，理解页面结构；再看api目录，理解接口调用方式；最后看views里的页面组件。

7.2 二次开发的方向

如果你想在这套系统上做个性化扩展，有三个方向价值最高：

第一个是集成预约日历视图。用FullCalendar组件替换当前的列表式预约展示，按周/月维度展示所有医生的排班和预约情况。这个改造对前端的提升最大，也更符合诊所前台的使用习惯。

第二个是消息通知模块。当患者预约成功时，通过短信或微信模板消息推送预约确认；就诊前一天自动发送提醒；超时未到诊自动标记爽约并通知前台。这个功能非常实用，能显著减少诊所的爽约率。

第三个是数据可视化看板。在首页做一个诊所运营驾驶舱：今日预约量、接诊量、收入、患者新增量、热门治疗项目TOP5，用ECharts图表展示。这个功能对管理者的价值最大，也最容易在简历项目里单独作为亮点来写。

热搜词里还有一条"芋道源码"，指的是开源的芋道（RuoYi-Vue-Pro）脚手架。如果你看完这套源码，还想看更企业级的项目组织方式，去研究一下芋道源码的后端代码规范、权限设计、代码生成器，会获益更大。但那套框架的复杂度比这套牙科系统高不少，建议先把这套吃透再进阶。

这套牙科诊所管理系统对SpringBoot+Vue+MyBatis+MySQL这套组合的展示，客观上比很多大而全的脚手架项目要直观得多。建议你把它跑通之后，基于真实的业务理解重构一遍部分模块代码，而不是停留在"能跑通"的层面。重构一次，比看十遍源码都能学到更多东西——这也是保持技术敏感度和编码手感最有效的方式之一。