SpringBoot+Vue3+MyBatis+MySQL：实验室管理系统开发与实践

1. 需求先行的实验室系统五个核心流程决定表结构走向先交代一下背景。我去年帮学校信息中心做了一套实验室管理系统技术栈就是标题里的那套Java SpringBoot Vue3 MyBatis MySQL。做之前我去实验室转了一圈发现管设备的老师还在用Excel登记仪器借出记录学生预约实验要在群里接龙耗材库里库存有没有货完全靠记忆。这种场景在国内高校、职校、科研院所里非常普遍。所以这套系统要解决的问题很明确把设备借用、实验预约、耗材领用这几件日常高频的事情搬到线上让每个环节有记录、有审批、有状态追踪。听起来就是普通的增删改查吧但真正动手设计的时候才发现如果业务流程没有提前想清楚表结构后面一定返工。我整理下来实验室管理系统最核心的是五个流程设备台账管理设备信息录入、编号生成、状态流转空闲、借用中、维护中、报废。设备借用与归还学生或老师发起借用申请管理员审批到期归还并登记设备状态。实验预约按设备或实验室预约时间段系统必须避免重复预约。耗材入库与领用耗材入库登记、按用量扣减、库存低于阈值自动提醒。统计报表设备利用率、耗材消耗汇总、借用频次排行。这五个流程里前两个是核心第三个最容易出错第四个看着简单但字段设计容易遗漏第五个往往被忽略但实际使用中老师最喜欢看。1.1 一套实验室系统常见的五个核心流程先说设备台账。设备表需要记录的不只是名字和型号。我踩过的坑是只设计了设备名称、编号、状态三个字段结果部署之后老师问这台设备哪个实验室的什么时候采购的保修期到没到上次保养是什么时候所以设备表至少要包含设备编号、名称、型号规格、所属实验室、存放位置、采购日期、资产编号、当前状态、当前借用人、下次保养日期。其中当前借用人是一个冗余字段不用它做关联查询纯粹为了列表页直接展示这台设备现在在谁手里避免每次列表都联一次用户表。借用归还流程要注意的是状态机。我用的状态枚举是可借、待审批、借用中、已逾期、维护中、已报废。有人会问已逾期算不算一种状态我的做法是设备表里存实际状态逾期是预约记录和借用记录上的标记字段定时任务扫一遍把应还时间小于当前时间且未归还的记录标记为逾期设备状态同时改为借用中-已逾期只是展示层的拼接。这样不会把状态枚举搞得很复杂。实验预约流程要处理时间冲突。这个下一节单独说因为它是整个系统最容易写错的地方。耗材管理的核心是每一笔消耗都要能追溯到一次领用申请。也就是说耗材库存表不能只存一个总量还需要一张领用明细表。库存表负责维护当前余量领用明细表记录每一次谁领了多少、用于什么实验、审批人是谁。库存扣减时要用乐观锁防止并发超领后面部署部分我会再讲这个问题。1.2 用最简单的角色模型收敛权限复杂度权限这块我做了很久的思想斗争。一开始想用RBAC用户-角色-权限三级模型还设计了一张权限表。后来发现实验室系统撑死就三类人管理员、教师、学生。管理员管设备台账和审批教师可以预约和审批学生申请学生只能预约和借用。最后我把角色表去掉直接在用户表上用一个role字段区分。管理员和教师算一种可审批角色学生算普通用户。SpringBoot后端做接口权限校验时只需要在拦截器里判断user.getRole()是否在允许列表里就够了。这种设计对课程设计、毕业设计或者小规模的实验室管理系统来说完全够用。如果你确实想要更通用的权限模型可以把角色和权限拆成两张表但系统复杂度会明显上升接口鉴权也不再是一个注解能搞定的事。2. 技术选型复盘SpringBoot Vue3 MyBatis MySQL这套组合是否合理网上关于这套技术栈的争议其实不少尤其是MyBatis和JPA的对比。我当初选这套组合不是随大流而是结合实验室管理系统这个具体场景做的判断。2.1 后端为什么是SpringBoot而不是SSH或SpringMVCSSH是十年前的老黄历了Struts2的配置繁琐程度现在再回去写真的会怀疑人生。SpringBoot的自动配置把绝大部分基础设施都替你做好了内嵌Tomcat、数据源自动装配、事务管理、JSON序列化、参数校验。我建项目时只需要引入依赖配置一个application.yml就能在十分钟内跑起一个带数据库连接的Web服务。SpringBoot还有一个优势是生态不需要操心。Spring Security、PageHelper、EasyExcel、Hutool全是现成的版本由spring-boot-starter-parent统一管理基本不会遇到让你头痛的版本冲突。2.2 Vue3比Vue2好在哪以及为什么配Element Plus前端这块实验室管理系统是典型的中后台界面表格、表单、弹窗、下拉选择、日期选择、分页。Vue3的组合式APIComposition API写这种界面最大的好处是逻辑复用。Vue2时代写一个设备列表页逻辑都堆在data、methods、watch这些选项里页面一复杂一个组件上千行很常见而且很难拆。Vue3把同一类逻辑抽成一个function放回setup里调用比如我可以把分页查询设备列表这一整套逻辑封装成useDeviceList()组件里只用一行去调用。UI库选Element Plus而不是Ant Design Vue原因是我更熟悉Element的API风格而且Element Plus对Vue3的适配很成熟表格、表单、日期选择器这些组件开箱即用不需要二次封装。后端管理系统不比C端门户网站不需要炫酷的动画和复杂的交互Element Plus的表单校验和表格操作列已经覆盖了95%的需求。2.3 MyBatis在这套系统里的角色定位实验室管理系统的数据访问有几个特点单表查询多、多表联查也频繁、统计类SQL复杂、写入逻辑相对简单。比如查询某台设备上最近三个月的预约记录并统计按时完成率这种需求用ORM的自动查询语法写起来非常绕但在MyBatis的XML里就是一段清晰的SQL。MyBatis的本质是半自动ORM映射规则你定SQL也你定框架只负责参数绑定和结果集映射。这种模式对开发者的SQL能力有一定要求但换来的好处是查询性能可控、SQL可读性强、排查问题直观。JPA当然也能干这活但遇到复杂统计查询时JPA的Criteria API写出来的代码可读性远不如一段精心调优的SQL。所以我最后的选择是简单的单表CRUD用MyBatis-Plus的BaseMapper省去大量重复的增删改方法复杂的多表查询和统计报表写在XML里手动控制SQL。两条路都走不偏科。3. 核心表设计设备台账与预约冲突是系统的两块硬骨头表结构设计阶段我走了两次回头路。第一次是漏了审批记录表导致预约驳回时不知道该在哪存拒绝理由。第二次是设备表和实验室表一开始做成了一对一后来发现一台设备可能在不同实验室间移动只好把所属实验室改成设备表上的冗余字段移动时直接更新字段不建关系表。3.1 核心表用户、设备、预约、耗材、审批记录下面是我最终定下来的核心表结构你可以直接拿来用-- 用户表 CREATE TABLE sys_user ( id bigint PRIMARY KEY AUTO_INCREMENT, username varchar(50) NOT NULL UNIQUE COMMENT 登录名, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, real_name varchar(50) NOT NULL COMMENT 姓名, role varchar(20) NOT NULL COMMENT ADMIN/TEACHER/STUDENT, phone varchar(20), create_time datetime DEFAULT CURRENT_TIMESTAMP ); -- 设备表 CREATE TABLE lab_device ( id bigint PRIMARY KEY AUTO_INCREMENT, device_code varchar(50) NOT NULL UNIQUE COMMENT 设备编号, device_name varchar(100) NOT NULL COMMENT 设备名称, model varchar(100) COMMENT 规格型号, location varchar(100) COMMENT 存放位置, lab_name varchar(100) COMMENT 所属实验室, purchase_date date COMMENT 采购日期, status varchar(20) NOT NULL DEFAULT AVAILABLE COMMENT 状态, current_user_id bigint COMMENT 当前借用人ID, next_maintain_date date COMMENT 下次保养日期, remark varchar(500) ); -- 预约/借用表共用一张表 CREATE TABLE reserve_record ( id bigint PRIMARY KEY AUTO_INCREMENT, device_id bigint NOT NULL, user_id bigint NOT NULL, start_time datetime NOT NULL, end_time datetime NOT NULL, purpose varchar(500) COMMENT 用途说明, status varchar(20) NOT NULL DEFAULT PENDING COMMENT PENDING/APPROVED/REJECTED/FINISHED/CANCELLED, approve_user_id bigint COMMENT 审批人, approve_remark varchar(500) COMMENT 审批备注, create_time datetime DEFAULT CURRENT_TIMESTAMP ); -- 耗材表 CREATE TABLE consume_material ( id bigint PRIMARY KEY AUTO_INCREMENT, material_name varchar(100) NOT NULL, stock int NOT NULL DEFAULT 0 COMMENT 当前库存, safe_line int NOT NULL DEFAULT 0 COMMENT 安全库存阈值, unit varchar(20) COMMENT 单位, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 耗材领用明细 CREATE TABLE consume_record ( id bigint PRIMARY KEY AUTO_INCREMENT, material_id bigint NOT NULL, user_id bigint NOT NULL, count int NOT NULL COMMENT 领用数量, purpose varchar(500), create_time datetime DEFAULT CURRENT_TIMESTAMP );注意几个细节。设备表里我没有建物理外键。物理外键在并发量稍高的场景下会拖慢写入速度而且当你做逻辑删除、数据迁移的时候外键约束会变成绊脚石。现在的主流做法是表结构上不建外键在应用层维护数据一致性。这要求你在写删除和更新接口时多做一步检查例如删除用户前先查这个用户名下有没有未归还的设备。密码字段存的是BCrypt加密后的密文。BCrypt的特点是每次加密同一个密码生成的密文都不一样内部随机盐所以即使两个人密码相同数据库里存的哈希值也不同。这比MD5加固定盐的安全性高很多Spring Security的BCryptPasswordEncoder可以单独拿来用不一定要引入全套Security。3.2 一个容易翻车的设计点预约时间冲突怎么判断这是整套系统里我觉得最值得单独讲的地方。很多第一次做预约系统的人会这样判断冲突查询某个时间段内有没有记录然后比较start_time是否相等。这完全不对。两个时间段重叠的条件是已有的预约时间段是 [A_start, A_end]新请求的时间段是 [B_start, B_end]两者冲突当且仅当 A_start B_end 且 A_end B_start。SQL写出来就是SELECT COUNT(*) FROM reserve_record WHERE device_id #{deviceId} AND status IN (PENDING, APPROVED) AND start_time #{endTime} AND end_time #{startTime}我来解释为什么。A_start B_end 保证了新预约开始之前旧预约还没结束A_end B_start 保证了旧预约结束之后新预约还没开始。只有这两个条件同时成立才说明两个时间段真的重叠了。举个例子已有预约10:00-12:00新请求11:00-13:00。此时A_start(10:00) B_end(13:00)A_end(12:00) B_start(11:00)两个条件都满足冲突。再试一个已有预约10:00-12:00新请求13:00-14:00。A_start(10:00) B_end(14:00)成立但A_end(12:00) B_start(13:00)不成立所以不冲突。这样的判断才能覆盖完全包含、部分重叠、首尾相接的边界情况。还有一个边界要注意如果允许首尾相接也就是12:00还、13:00借这种场景判断条件要处理成start_time #{endTime} AND end_time #{startTime}我上面写的就是允许首尾相接的版本。如果你要求必须有间隔就把改成把改成。我实际测试中发现还有一种隐藏情况同一用户在同一时段重复提交了两次预约第一次提交后页面卡顿用户又点了两次。所以要加一个相同设备、相同用户、相同开始时间、状态为待审批的去重判断否则会出现两条一模一样的PENDING记录。最简单的做法是在reserve_record上建一个普通索引然后在Service接口里先查一次。4. 后端落地JWT鉴权、分页插件与业务接口的实现细节后端开发我是按基础设施先行、业务接口随后的顺序来的。基础设施指统一返回结构、全局异常处理、JWT鉴权、分页封装这四样业务接口反而简单大部分是往Service里填CRUD逻辑。4.1 登录认证JWT 拦截器的组合为什么够用前面说过这个系统角色维度很窄所以我没有引入Spring Security的三件套UserDetailsService、过滤器链、方法级安全。我用的是登录接口校验用户名和密码成功后签发一个JWT里面包含用户ID和角色。一个LoginInterceptor拦截除/api/auth/login之外的所有后端接口从请求头Authorization里解析token取用户信息放到ThreadLocal里。Service层需要权限时从ThreadLocal取当前用户角色做判断。JWT工具类核心就三件事生成token、解析token、校验过期时间。用io.jsonwebtoken:jjwt这个库代码大致长这样// 生成 token String token Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 2 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); // 解析 token Claims claims Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token) .getBody();secretKey放配置文件里别硬编码在代码中。过期时间我设的2小时前端每1小时调一次刷新接口拿新token或者干脆在axios响应拦截器里发现401时自动跳登录页。对于实验室管理系统这个使用频率来说2小时完全够用。拦截器里有两个坑。第一个是跨域预检请求OPTIONS不携带token所以拦截器要放行OPTIONS请求否则前端调用接口时会先收到一个CORS错误再加一个401。第二个是白名单设计。除了登录接口我还把静态资源路径和/error放行了避免Spring Boot内置错误页被拦截导致问题难以排查。4.2 PageHelper分页的正确打开方式与常见坑分页这块直接用MyBatis的分页插件PageHelper热搜词里很多人也在查它的用法。我快速说一下完整流程。pom.xml引入依赖dependency groupIdcom.github.pagehelper/groupId artifactIdpagehelper-spring-boot-starter/artifactId version2.1.0/version /dependencyapplication.yml里配pagehelper: helper-dialect: mysql reasonable: true support-methods-arguments: truereasonable: true的意思是当页码超过总页数时自动回退到最后一页小于1时回到第一页这个配置在系统里十分实用不然前端乱传一个page999后端会返回一个空列表而不是正常兜底。业务代码里的用法PageHelper.startPage(pageNum, pageSize); ListDeviceVO list deviceMapper.selectDeviceList(query); PageInfoDeviceVO pageInfo new PageInfo(list);返回结果里pageInfo.getTotal()是总记录数pageInfo.getList()是当前页数据前端分页组件需要的就是这两样。PageHelper最大的坑是startPage必须紧接着下面那条要分页的Mapper查询。如果中间隔了另一个查询语句分页插件会作用在错误的SQL上导致数据错乱。我见过有人把startPage写在循环里结果每次循环都重新set一次Page最后一次生效的Page覆盖了前面所有的查询。另外多表联查时PageHelper自动生成的count语句有时会慢因为插件会用count(0)去包原SQL如果原SQL里带group bycount的结果会不对。复杂统计场景我建议手写count查询不要依赖插件。4.3 设备借用审批接口的设计状态驱动比单独写一堆方法靠谱设备借用和实验预约的审批逻辑我是用状态驱动来做的。reserve_record.status有五个值PENDING待审批、APPROVED已通过、REJECTED已拒绝、FINISHED已完成、CANCELLED已取消。对应到接口上我没有写四个不同名字的方法而是设计了两个通用操作审批传入recordId、approveResult通过/拒绝、approveRemark。如果通过同时把设备状态改成借用中如果拒绝设备状态不动只回写审批信息。归还传入recordId校验当前时间是否晚于end_time如果晚于则顺带记录一条逾期标记设备状态改回可借。这样做的好处是逻辑收敛在一个Service方法里状态流转肉眼可见。我曾经见过有人把通过审批和拒绝审批拆成两个Controller方法结果前端传错一个字段就找不到对应的逻辑分支调试起来非常痛苦。审批通过时会有并发问题两个人同时对一台设备发起审批后审批的人可能覆盖前一个人的操作。我的方案是先通过SELECT ... FOR UPDATE锁住reserve_record记录再更新设备状态。这在高并发场景下会有性能问题但实验室系统的访问量一天撑死几百次请求悲观锁完全够用且逻辑简单。5. 前端Vue3实现脚手架、请求封装与三个容易卡壳的集成点前端这部分我用的是标准中后台三件套Vue3 Vite Element Plus状态管理用的Pinia路由用的Vue Router 4。整体开发体验比Vue CLI时代舒服太多Vite的热更新几乎秒级生效。5.1 项目脚手架与目录结构创建项目npm create vitelatest lab-admin -- --template vue安装依赖npm install vue-router4 pinia element-plus axios dayjs目录结构我习惯这样组织src/ ├─ api/ # 接口定义按模块拆分 │ ├─ device.js │ ├─ reserve.js │ └─ auth.js ├─ router/ # 路由配置 ├─ stores/ # Pinia只放用户信息 ├─ views/ # 页面组件 │ ├─ device/ │ ├─ reserve/ │ └─ dashboard/ ├─ utils/ # axios 实例、工具函数 └─ layout/ # 后台布局为什么把接口定义单独放api目录而不是直接在组件里写axios.get因为接口地址集中管理后后端改动路径只需要改一个文件而且接口出问题时排查范围也小。组件里调用只关心业务参数和返回值。5.2 请求封装与鉴权状态管理axios实例的封装极其重要。核心逻辑是请求拦截器里注入token响应拦截器里统一处理错误码。我放一段实际在用的代码// utils/request.js import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.msg || 请求失败) return Promise.reject(new Error(res.msg)) } return res.data }, error { if (error.response?.status 401) { localStorage.removeItem(token) router.push(/login) } ElMessage.error(error.message || 网络异常) return Promise.reject(error) } ) export default request这里有个边界要提醒当后端接口返回code401时axios的响应拦截器走不到error分支HTTP状态码还是200所以统一返回格式里必须保证code200才放行否则直接报错并跳登录。我的做法是在后端写一个全局异常处理器把未认证异常统一转成HTTP 401这样前端拦截器只需要关心error.response.status就够了。不过如果后端格式不统一前端就得在成功分支里也做一次401判断两个地方都要写很容易漏。Pinia里只存一个用户对象和token不做复杂的状态树。页面级的列表搜索条件、分页页码这些本地状态就用ref()管不需要全局共享。5.3 页面实现中最容易卡壳的三个集成点集成点一Element Plus表格和后端分页数据的对接。后端返回{total, list}结构前端表格的data属性绑list分页组件的total绑total。注意切换页码时要以后端返回的total为准刷新总页数而不是前端自己算。有人会把当前页数据存进一个数组然后在current-change事件里手动截取这完全是画蛇添足必须用后端分页。集成点二DatePicker时间范围选择与后端LocalDateTime的序列化。后端Java 8的时间类型默认序列化成数组前端拿到的是一坨像[2024, 5, 20, 8, 30]一样的东西根本没法直接用。必须在application.yml里配Jacksonspring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8还有一个坑是时区。如果你不配time-zone: GMT8服务器UTC时间会比北京时间少8小时查询预约记录时会发现所有时间都偏移了。这块我当时排查了半天最后发现数据库时间是对的是Jackson序列化时用了UTC。集成点三路由守卫。实验室管理系统的前端路由其实不需要动态生成静态路由就行。但登录守卫必须有。用router.beforeEach判断如果目标页面不是登录页且本地没有token直接重定向到/login。如果已登录但访问登录页则重定向到首页。这个逻辑写在router/index.js里就行和Pinia联动取用户角色。页面开发顺序我建议先做设备管理和预约记录两个页面因为它们是系统的骨架跑通后你再做耗材和报表页面会发现大部分代码都是复制粘贴改字段名。我之前先做了登录注册页面结果没有设备数据可看白白花了大半天调样式。6. 前后端联调与生产部署Nginx代理、路由回退与字符集问题这一章是系统真正能跑起来的地方。开发模式下前端Vite代理用vite.config.ts里的server.proxy配置就够了但生产环境要把npm run build生成的dist目录扔给Nginx并且让Nginx把/api开头的请求转发给后端。6.1 环境准备JDK/MySQL/Node版本怎么选我在部署时用的版本组合是JDK 8、MySQL 5.7、Node.js 16。这个组合在2024年依然非常稳。SpringBoot 2.7.x对JDK 8支持良好而SpringBoot 3.x要求JDK 17如果你用的是课程设计里老师给的旧代码或者某些老库JDK 17可能会遇到兼容性问题所以新手我更推荐JDK 8加SpringBoot 2.7组合。MySQL 5.7要注意的是默认字符集可能不是utf8mb4。建库时手动指定CREATE DATABASE lab_manage DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;如果建库时忘了指定后面插入中文数据会出现乱码或者报Data truncation: Incorrect string value错误。这是MySQL最常见的问题之一我是建议在任何手册或课程设计文档里都把这一句写进去。Node版本建议18以上Vite 4要求Node 16.14以上Node 18更省心。安装好之后node -v确认一下版本。6.2 Nginx代理与前端路由回退配置Vue3的项目路由默认是HTML5 History模式URL里没有#好看但有一个问题刷新页面时Nginx找不到对应的物理文件会返回404。解决办法是加一个try_files指令把未知路径全部回退到index.html让前端路由接管。我用的Nginx配置参考server { listen 80; server_name localhost; root /opt/lab-web/dist; index index.html; # 前端路由回退 location / { try_files $uri $uri/ /index.html; } # API反向代理 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; } }proxy_pass后面加不加末尾的斜杠区别很大。proxy_pass http://127.0.0.1:8080;会把完整的/api/xxx路径透传给后端如果写成http://127.0.0.1:8080/;会把/api前缀剥掉再转发后端接口路径对不上就会404。这个细节我栽过一次后来把后端所有请求路径统一加了/api前缀Nginx只做透传逻辑简单也利于排查。6.3 部署后我踩到的三个环境问题第一个是端口占用。后端java -jar启动时报Port 8080 was already in use查一下要么是另一个Java进程占着要么是防火墙没关。netstat -tunlp | grep 8080查进程确认后kill -9 PID或者改application.yml里server.port换一个端口并同步改Nginx代理。第二个是MySQL连接失败。后端配置里的数据库名、用户名、密码必须和MySQL实际建库的一致注意jdbc:mysql://localhost:3306/lab_manage?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneGMT%2B8。serverTimezone一定不能丢否则Java 8连接MySQL 8版本会报时区错误。我配的是GMT%2B8%2B是号的URL编码写GMT8在某些情况下也会报解析错误。第三个是跨域。前端Nginx监听80后端监听8080按理说是跨域但因为生产环境通过Nginx的/api反向代理浏览器只看到同源根本不触发CORS。开发模式下才需要Vite代理或后端加CrossOrigin。所以我的建议是生产环境用Nginx代理解决跨域后端不要开全局CORS这是最干净的做法。还有一个部署细节是后端配置文件外置。我用java -jar lab-server.jar --spring.profiles.activeprod指定生产环境配置文件生产环境的数据库密码和密钥和开发环境分开维护。这样重新部署时只需要替换jar包不用改配置。7. 做项目之外的收获与可以继续扩展的方向一套实验室管理系统做完我最大的感受是这类项目的难点从来不是某个技术点而是业务流程的设计和数据之间的一致性保障。技术栈只是工具把设备借用-归还、预约-审批-统计这两个闭环想清楚代码怎么写都不会太差。我给自己定的后续扩展方向按价值排序EasyExcel导入导出设备台账的Excel批量导入和导出老师非常需要这个功能。通知提醒借用即将到期时发邮件或站内信可以用Spring的Scheduled定时任务每天扫一遍超期记录。二维码标签给每台设备生成一个二维码贴到设备上学生扫码就能发起借用申请这个对使用体验的提升立竿见影。设备利用率统计图表按周、月统计每台设备的预约时长和空闲时长用ECharts画一个柱状图放到首页。最后分享一个小技巧做课程设计或毕业设计时第一版不要一口气设计10张表。先把用户、设备、预约记录这三张表跑通一个完整链路再去扩展耗材、审批记录、统计报表。项目最怕的是表结构堆了一大堆结果核心流程还没走通就卡住了。像我现在复盘这个项目真正让老师觉得可用的功能就是设备状态实时可见和预约不冲突其他都是锦上添花。