企业官网建设流程全解析

做课设或者毕设选到这个题目，我先说句实在话——你的选择挺划算。SpringBoot进销存管理系统是Java后端里最经典的练习场景，而“智能药箱”这个前缀又比普通的图书管理、学生管理系统多了点创新亮点，在答辩和查重层面都很讨巧。这篇文章我不给你讲空泛的概念，直接把这个题目拆到骨头里，从功能设计、数据库建模、核心代码写法，到源码怎么跑起来、文档怎么写、答辩怎么答，一条龙给你捋清楚。全程没有藏着掖着的部分，适合想真正把系统搞懂而不是只改个名字交差的人。

1. 项目整体设计与功能拆解

1.1 “智能药箱”和“进销存”到底是什么关系

很多同学拿到这个题目会有点懵：药箱和进销存听起来是两个方向的东西，怎么合在一起了？

实际上这个组合非常合理。智能药箱侧重的是“药品使用端”——患者或者护理人员对于居家药箱、病房药柜里药品的管理和提醒；医药进销存系统侧重的是“药品流通端”——药店或者医药公司对采购、库存、销售的管理。一套完整的医药管理项目，天然的链路就是“采购入库-库存管理-销售出库”，而智能药箱的定位就是这个链条终端的医药物资使用容器。系统把这二者打通：药箱中存放的每一盒药品都有进销存的数据支撑，库存不足时自动触发采购提醒，近效期药品自动预警。也就是说，智能药箱在这里不是一个纯硬件项目，而是进销存系统的一个业务延伸模块。

这个设计在答辩时非常好讲：一方面技术栈是纯Java后端通用技术，难度可控；另一方面业务上有完整闭环，从采购到销售到用药监控都覆盖了，评委会觉得你的系统有想法、有成体系的应用场景。

1.2 核心功能模块拆解

基于标题和典型的进销存业务逻辑，这套系统至少要包括以下几个核心模块：

药品信息管理：药品的通用名、商品名、剂型、规格、生产厂家、批准文号（国药准字）、存储条件（阴凉/冷藏）、有效期。这块是整个系统的数据基础。

供应商管理：供应商名称、联系方式、资质证号、供货药品范围。进销存系统必须有供应商档案，否则采购单就成了无源之水。

客户管理：在医药零售场景下，客户可以是普通消费者，可以是医院药房，也可以是下级经销商。管理客户信息、信用额度、历史购买记录。

采购入库管理：创建采购单、选择供应商和药品、录入采购数量和采购单价、确认入库后自动增加库存，同时生成入库流水。

销售出库管理：创建销售单、选择客户、选择药品、录入销售数量和销售单价、确认出库后自动减少库存，同时生成出库流水。

库存管理：实时库存查询、库存上下限预警、近效期药品预警、库存盘点、报损报溢。这是进销存系统的核心价值所在。

智能药箱管理：药箱与用户/家庭/病房绑定，记录药箱中存放的药品清单，支持用药提醒配置（服药时间、剂量）、药品余量低预警。这个模块是“智能药箱系统”命名的主要支撑。

系统管理：用户登录认证、角色权限（管理员/操作员/查看者）、操作日志、数据字典。

功能确定之后，再往数据库设计层面走，你要保证每张表、每个字段都能对应到上面某一个业务动作，这样后面写文档描述数据流的时候会非常顺手。

1.3 为什么选SpringBoot而不是SSH或者SpringCloud

技术选型也是答辩必问的问题。这个项目选SpringBoot，原因有三：

第一，SpringBoot简化了Spring的配置流程，内嵌Tomcat，通过一个main方法就能启动Web服务。课设和毕设阶段不需要你操心复杂的XML配置，能把精力集中在业务逻辑上。

第二，SpringBoot是当前Java后端岗位实际使用的主流框架，学了之后直接对口工作。如果选SSH（Struts2+Spring+Hibernate）或者更老的技术栈，答辩老师反而会质疑你学了过时的东西。

第三，SpringBoot庞大的生态整合能力很强，如果需要登录认证，可以引入Spring Security或Sa-Token；如果需要接口文档，集成Knife4j；甚至哪怕做智能药箱的设备数据上报模拟，也能结合MQTT或者定时任务实现。换句话说，项目做完想加亮点，SpringBoot都接得住。

有一点建议：如果基础一般，不要强行上SpringCloud微服务。微服务不是课程设计的目的，单体应用加上清晰的模块分层，真的足够拿高分了。技术栈简单且能自圆其说，远比堆一堆自己都说不清楚的概念要强。

2. 数据库设计的核心逻辑与表结构

2.1 数据建模的思路：从业务流转推导表关系

进销存系统的数据库设计是整套系统最见功底的部分。不要一上来就画表，先梳理业务流程：

采购员创建采购单 -> 入库员确认入库 -> 库存增加 -> 销售员创建销售单 -> 出库员确认出库 -> 库存减少 -> 库存低于阈值自动预警 -> 采购员继续创建采购单

这个流程指向的表结构非常清晰：

基础档案表：药品表、供应商表、客户表、用户表

业务单据表：采购单主表、采购单明细表、销售单主表、销售单明细表

库存流水表：库存流水表（记录每一次库存变动的来龙去脉）

药箱业务表：药箱表、药箱药品关联表、用药提醒表

为什么要拆成主表和明细表？核心原因是业务需求：一张采购单里包含多种药品时，主表只存单据编号、供应商、单据日期、总金额、审核状态等公共信息，明细表存“药品ID、数量、单价、金额”这种行项目。主表一条记录对应明细表多条记录，通过单据编号关联。这种结构在后端代码里就是一对多查询，在报表里可以按照主表维度汇总单据数，按明细表维度统计药品采购量，非常灵活。

2.2 药品表和库存表的字段设计要点

药品表是基础中的基础，字段设计直接影响后续所有模块的开发。给出一份可以直接用的设计：

药品表（drug）

注意一个问题：药品有效期的设计有两种思路。一种是在药品表里直接放一个总有效期，另一种是把药品按批次管理，每一批入库记录自己的生产日期和有效期。对于课设级别，第一种就够用；如果你想加分，可以引入“批次管理”——库存表中加batch_no字段，同一药品不同批次的效期分别跟踪，销售出库时按先进先出原则扣减批次库存。这个属于亮点设计，写文档时可以单独讲一节，含金量很高。

库存表的设计同样重要。最推荐的做法是独立设计一张药品库存表，与药品表一对一关联：

库存表（drug_stock）

为什么不直接把库存数量怼在药品表里？因为药品表是基础档案，库存是动态变化的业务数据，混在一起会导致药品信息每次修改都要连带处理库存，逻辑混乱。分离之后，查药品信息走药品表，查库存数量走库存表，职责清楚。

2.3 采购、销售单据与流水表的一对多模型

采购和销售的结构非常相似，写数据库脚本时直接对应着来。

采购单主表（purchase_order）

采购单明细表（purchase_order_item）

销售订单表结构同理，把supplier_id换成customer_id即可。

库存流水表是进销存系统里必须有的审计表。每一次库存变动，不管来自采购入库、销售出库、报损还是盘点调整，都要写入一条流水：

库存流水表（stock_flow）

流水表是排查库存差异的利器。系统运行一段时间后如果发现账面库存和实际库存对不上，直接按流水表逐笔核对就行。写文档时把流水表的设计意图说清楚，评委一眼就能看出你有实战经验。

2.4 智能药箱模块的表设计

智能药箱涉及三张表：药箱表、药箱药品关联表、用药提醒表。

药箱表（medicine_box）

药箱药品关联表（box_drug）：box_id关联药箱，drug_id关联药品，单独记录放入药箱的数量。这张表的价值在于：药箱里的备药情况和仓库库存解耦。仓库库存描述的是“整个企业/药店有多少药”，药箱药品数量描述的是“这个家庭或者病房里实际放了哪些药”。

用药提醒表（medication_reminder）：记录药品服用计划，包括用药时间（早上/中午/晚上）、剂量，以及是否已提醒的状态。这个模块就是智能药箱“智能”二字的落点。

数据库这块多说一句：建议在实际建表时给每张表都加create_time和update_time字段，后面写MyBatis的insert和update时顺手就能维护，查询页面上展示时间也方便，别嫌字段多，这是行业惯例。

3. 核心功能的后端实现思路

3.1 项目分层结构与目录规划

拿到源码后先别急着跑，先看目录结构是否合理。一个标准的SpringBoot分层结构长这样：

com.example.pharmacy ├── controller 控制层 ├── service 业务层（接口） ├── service.impl 业务层（实现） ├── mapper 数据访问层（MyBatis接口） ├── entity 数据库实体类 ├── dto 数据传输对象 ├── vo 前端展示对象 ├── common 通用结果封装/异常处理 ├── config 配置类 └── utils 工具类

控制层只做参数接收和结果返回，业务逻辑写在service.impl里，数据库操作放在mapper层。这个分层的核心价值用一个词就能概括：职责分离。控制层薄一点，业务层厚一点，既方便单元测试，也方便将来需求变更时快速定位代码。

Controller层建议统一返回Result对象：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } }

所有接口统一走Result包装，前端拿到code=200就知道请求成功，非200就弹message，比裸返回Map或者随意拼JSON规范太多。

3.2 核心业务逻辑：入库、出库、库存扣减

进销存系统最关键的业务逻辑是保证一件事：库存变动的正确性。入库相对简单，核心代码逻辑如下：

@Override @Transactional public Result<?> purchaseInbound(PurchaseOrderDTO dto) { // 1. 构建采购单主表 PurchaseOrder order = new PurchaseOrder(); BeanUtils.copyProperties(dto, order); order.setOrderNo(generateOrderNo("PD")); order.setStatus(1); purchaseOrderMapper.insert(order); // 2. 循环处理明细行 List<PurchaseOrderItemDTO> items = dto.getItems(); BigDecimal totalAmount = BigDecimal.ZERO; for (PurchaseOrderItemDTO item : items) { // 2.1 插入采购单明细 PurchaseOrderItem orderItem = new PurchaseOrderItem(); BeanUtils.copyProperties(item, orderItem); orderItem.setOrderId(order.getId()); purchaseOrderItemMapper.insert(orderItem); // 2.2 查询当前库存 DrugStock stock = drugStockMapper.selectByDrugId(item.getDrugId()); if (stock == null) { stock = new DrugStock(); stock.setDrugId(item.getDrugId()); stock.setStockQuantity(item.getItemQuantity()); drugStockMapper.insert(stock); } else { // 2.3 库存累加 stock.setStockQuantity(stock.getStockQuantity() + item.getItemQuantity()); drugStockMapper.updateById(stock); } // 2.4 写入库存流水 StockFlow flow = new StockFlow(); flow.setDrugId(item.getDrugId()); flow.setFlowType("IN"); flow.setRelatedNo(order.getOrderNo()); flow.setChangeQuantity(item.getItemQuantity()); flow.setBeforeQuantity(stock.getStockQuantity() - item.getItemQuantity()); flow.setAfterQuantity(stock.getStockQuantity()); stockFlowMapper.insert(flow); // 2.5 累加总金额 totalAmount = totalAmount.add(item.getItemPrice().multiply(BigDecimal.valueOf(item.getItemQuantity()))); } // 3. 更新采购单总金额 order.setTotalAmount(totalAmount); purchaseOrderMapper.updateById(order); return Result.success(order); }

注意看几个关键点：第一，整个方法加了@Transactional注解，中途任何一步报错，前面插入的明细和改掉的库存都会一起回滚，不会出现“单子建了一半，库存改了但没记录”的情况。第二，库存流水记录的beforeQuantity和afterQuantity要在更新前后分别取，逻辑顺序不能乱。第三，金额计算一律用BigDecimal，禁止使用double或float，这是财务相关系统的铁律——浮点数的二进制精度问题会导致金额算错。

销售出库（出库扣减库存）是进销存系统的另一个难点，核心逻辑方向倒过来：

// 1. 判断库存是否充足 DrugStock stock = drugStockMapper.selectByDrugId(item.getDrugId()); if (stock == null || stock.getStockQuantity() < item.getItemQuantity()) { throw new BusinessException("药品【" + drug.getDrugName() + "】库存不足"); } // 2. 扣减库存 stock.setStockQuantity(stock.getStockQuantity() - item.getItemQuantity()); drugStockMapper.updateById(stock); // 3. 记录流水 StockFlow flow = new StockFlow(); flow.setDrugId(item.getDrugId()); flow.setFlowType("OUT"); flow.setChangeQuantity(-item.getItemQuantity()); flow.setBeforeQuantity(stock.getStockQuantity() + item.getItemQuantity()); flow.setAfterQuantity(stock.getStockQuantity()); stockFlowMapper.insert(flow);

销售出库的校验环节尤其重要，必须在扣减前检查库存数量，并且在多线程并发场景下这个检查需要更严谨的锁机制。课设层面通常不需要上分布式锁，但建议大家了解一个概念：乐观锁。可以在库存表加version字段，UPDATE时带上version条件，如果影响行数为0说明有并发冲突，提示用户重试。这份理解写到文档“技术难点”一节，属于加分项。

3.3 库存预警与到期提醒的具体实现

库存预警的实现思路是：定时任务扫描 + 页面高亮展示。

SpringBoot自带的定时任务注解@Scheduled足够用。在启动类或者定时任务配置类上加@EnableScheduling，然后在任务方法上加@Scheduled(cron = "0 0 8 * * ?")表示每天早上8点执行一次：

@Scheduled(cron = "0 */30 * * * ?") public void checkStockAlert() { List<DrugStockVO> alertList = drugStockMapper.selectLowStockList(); for (DrugStockVO vo : alertList) { // 生成预警消息或发送通知 alertService.createStockAlert(vo.getDrugId(), vo.getStockQuantity()); } }

对应的SQL在mapper中如下：

<select id="selectLowStockList" resultType="com.example.pharmacy.vo.DrugStockVO"> SELECT d.id AS drugId, d.drug_name AS drugName, d.drug_code AS drugCode, s.stock_quantity AS stockQuantity, d.stock_min AS stockMin FROM drug_stock s INNER JOIN drug d ON s.drug_id = d.id WHERE s.stock_quantity &lt; d.stock_min </select>

注意这个SQL里用了JOIN，把库存表的数量和药品表的库存下限关联起来做条件筛选。这体现出一个数据库设计原则：业务判断字段放在最合理的表里，然后通过JOIN关联，而不是把stock_min重复存到库存表中。

近效期预警同理，在药品表中查有效期距今不到90天的药品：

SELECT * FROM drug WHERE expiry_date BETWEEN NOW() AND DATE_ADD(NOW(), INTERVAL 90 DAY)

如果启用了批次管理，这个查询要改成关联药品批次表，逻辑更细，但核心思路一样：把“过期时间是否落在警戒区间”作为筛选条件。

3.4 智能药箱的用药提醒如何实现

用药提醒这个模块实现方式很多，最朴素可行的是：定时任务扫描提醒表，到点的任务生成待提醒记录。更进一步可以做消息推送、短信通知、微信公众号通知，但课设阶段考虑到资源和复杂度，在系统内生成“待办提醒”即可。

具体逻辑：medication_reminder表存用药计划，每个计划有box_id、drug_id、remind_time、dose、status字段。定时任务每5分钟扫描一次当前时间匹配的记录，如果今天是计划执行日期且当前时间到达remind_time，就更新状态为“已提醒”，同时在系统的消息中心生成一条通知。

这块业务在答辩时很有讲头。智能药箱的关键价值是“依从性管理”——药品按时按量服用比单纯囤一堆药更有意义。你可以大胆地把这套逻辑总结成一句话：进销存管理保证“药从哪来、库存够不够”，智能药箱保证“药到哪去、吃没吃对”。这句话一抛出来，整个项目的高度就有了。

3.5 关键配置与pom.xml依赖

这里给出核心依赖供参考：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

MyBatis版本要和SpringBoot版本对齐，SpringBoot 2.7对应mybatis-spring-boot-starter 2.3.x，SpringBoot 3.x对应MyBatis-Spring-Boot-Starter 3.0.x。这个版本的坑非常经典，如果项目跑起来报“Property 'sqlSessionFactory' or 'sqlSessionTemplate' are required”错误，十有八九是版本不匹配。

application.yml里最关键的几项配置：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/pharmacy_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.pharmacy.entity configuration: map-underscore-to-camel-case: true spring: mvc: static-path-pattern: /**

关于url这个配置多说一句：serverTimezone=Asia/Shanghai必须加上。MySQL 8.x驱动默认使用UTC时区，不加这个参数连接时经常报错干扰到你怀疑人生。charset=utf8同样不能省，否则插入中文数据全是问号。这些都是新手最容易踩的坑，配置好后记在笔记里，以后任何SpringBoot项目都用得上。

4. 源码部署与本地运行指南

4.1 拿到项目后第一步的梳理顺序

无论源码是从哪下载来的，拿到一个SpringBoot项目先别急着启动，按以下顺序检查：

看数据库脚本。项目根目录或者doc目录下通常有一个.sql文件，用Navicat或者命令行执行。执行成功后会生成pharmacy_db库以及所有业务表。如果脚本文件较大，建议分段执行，一段执行完看是否有报错再执行下一段。

检查pom.xml中的依赖版本。重点看SpringBoot父级版本号、MySQL驱动版本、MyBatis-Plus版本或者MyBatis版本是否和你本地的JDK版本兼容。JDK 17搭配SpringBoot 2.x部分场景会有问题，建议下载项目时优先看README里标注的运行环境；该死的环境兼容问题占坑率最高，提前避雷。

修改application.yml数据库配置，用户名密码改成你本机的。注意：配置文件里如果出现数据库名pharmacy_db，但你执行脚本时建了别的库名，也要同步修改。看日志启动。如果启动成功但控制台没日志输出，检查logback/log4j2配置是否完整。

4.2 常见启动失败案例与应对

NO.1 端口被占用。启动时报Web server failed to start，基本就是8080端口被别的进程占了。解决方案：杀掉占用进程，或者直接改application.yml的server.port换一个端口，比如8081。开发环境下换端口是最省事的。

NO.2 数据库时区报错。报错信息里包含The server time zone value '�й���׼ʱ��'，就是时区问题。把url中serverTimezone=Asia/Shanghai加上，重启即可。

NO.3 表名映射不上。启动正常但查询报“Table 'xxx' doesn't exist”，检查实体类上@TableName注解或者mapper.xml里SQL的表名是否正确。MySQL在Linux和Windows下对大小写敏感程度不同，尽量统一使用小写表名，避免折腾。

NO.4 Mapper扫描不生效。启动报Invalid bound statement (not found)，检查启动类上有没有加@MapperScan("com.example.pharmacy.mapper")，以及mapper.xml文件是否放在了mapper-locations配置的路径下。这个错误在SSM转SpringBoot的人身上非常常见，XML文件和接口必须同名且包路径一致。

4.3 前端页面如何对接后端接口

如果项目前端是Vue独立部署，那后端接口全部走RESTful风格，前端通过axios请求。如果前端用的是Thymeleaf模板引擎，那访问路径直接映射Controller返回的视图名称。

这里聊一下最近很多人在折腾的“Vue打包放进SpringBoot”：原理是在Vue项目执行npm run build后，把dist目录下的文件复制到SpringBoot的src/main/resources/static目录下，然后前端请求后端时使用相对路径/api。如果前后端分开部署，前端跑在5173端口、后端跑在8080端口，那就需要给后端Controller加@CrossOrigin注解或者配置全局CORS。推荐的做法是配置全局CORS：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true); } }

这个配置类在前后端分离项目里几乎是必需品。如果没有它，前端访问后端时浏览器会拦截请求，报CORS error。一些从GitHub下载的开源项目故意不加这个配置，因为生产环境需要更严格的跨域策略，但课设阶段直接加上能省大量排查时间。

5. 万字文档的写作组织与答辩准备

5.1 论文/设计说明书的目录结构建议

标题里明确提到“万字文档”，说明源码有一套完整的设计说明书或毕业论文。文档写得好不好，直接决定课设分数的上限。推荐目录结构如下：

第一章 绪论：项目背景、国内外管理信息系统现状、研究意义、开发环境介绍（JDK/MySQL/IDE），这一章大约是背景铺垫，写2000字左右

第二章 需求分析：功能性需求（六大模块逐一描述）、非功能性需求（性能要求：页面响应时间不超过3秒；安全要求：权限控制、日志审计；稳定性要求：7x24小时不宕机）、可行性分析（技术可行性：SpringBoot成熟稳定；经济可行性：开源免费；操作可行性：界面友好易上手）

第三章 总体设计：系统架构图、功能模块图、技术架构描述、数据库设计（E-R图、数据字典、每张表的设计理由与字段说明）

第四章 详细设计与实现：每个核心模块的流程图、核心代码片段、实现截图。注意流程图可以用Visio或者ProcessOn画，答辩时必须能说清楚每一步的作用

第五章 系统测试：测试用例表（功能测试、边界测试、异常测试）、测试结果展示

第六章 总结与展望：项目完成情况总结、不足之处、未来改进方向（引入RFID自动识别、对接医院HIS系统、基于SpringBoot整合Flink做实时销售分析等）

这个目录是一个万金油结构，对绝大多数管理系统类的毕业设计都通用。关键是每一章都要紧密结合你的实际代码，不能光写概念名词。数据库设计章节直接把DDL语句亮出来；系统测试章节必须贴真实运行的测试截图。把文档写成“你项目的说明书”而不是“百度百科搬运工”，分数自然高。

5.2 测试用例怎么写才显得专业

测试章节是很多同学偷懒的重灾区，动辄就是“系统经过测试，运行稳定，满足需求”。这种话等于没写。专业一点的测试章节要有测试用例表：

写十个到十五个这种用例，覆盖正常流程、异常输入、边界情况、权限控制四类，文档的专业度直接拉满。手头的测试记录里，特别注意记录边界和异常场景，因为评委往往喜欢问“如果库存刚好等于0再出库会怎么样”。

5.3 答辩高频问题的提前演练

答辩是项目的最后一步，也是一些人翻车的地方。把高频问题提前背熟：

问题1：为什么选择SpringBoot做这个系统？答SpringBoot简化配置、自动装配、生态完善、适合快速开发，同时方便后期扩展；结合项目需要快速搭建Web应用的需求，SpringBoot的内嵌容器和自动配置能力大幅提升了开发效率。

问题2：库存变动的并发问题怎么考虑？答通过事务保证数据一致性，在高并发场景可以引入乐观锁（version字段），在更新库存时校验version是否变化，否则重试。虽然本系统面对的并发量不大，但设计上预留了优化空间。

问题3：你说智能药箱，核心的智能体现在哪里？答药箱本身是一个硬件概念，本系统中用软件还原了药箱的远程管理能力：药品存放清单可视化、余量不足自动提醒、服药计划个性化设置、到期/过期药品预警。如果对接智能硬件，只需增加一个设备通信接口。

问题4：库存预警是怎么实现的？答通过SpringBoot的@Scheduled定时任务定期扫描药品库存表，与药品表中的库存下限字段比较，低于下限就生成预警消息并推送到前端展示；近效期预警类似，扫描有效期在90天内的药品并提醒。

问题5：数据库为什么拆主表和明细表？答主表存单据公共信息，明细表存行项目信息，符合数据库范式设计；同时也方便统计报表，比如按月统计采购额直接查主表，按药品统计采购量直接查明细表，查询效率更高，数据冗余更少。

问题6：项目还有什么可以改进的？答三个方向：引入Redis缓存热点数据；对接硬件实现真正的智能药箱，比如自动感应出药、生成用药记录；引入消息队列实现异步通知，比如药品过期前推送提醒。注意：改进方向要具体，能联系当前系统的实际模块讲，不说空话。

答辩的核心原则是：你所写的每句话、每个功能，都要保证自己能口头讲清楚。背代码背得滚瓜烂熟，但问一句“SpringBoot自动配置的原理是什么”就卡壳，反而会被扣分。自动配置原理至少要知道：SpringBoot通过@SpringBootApplication中的@EnableAutoConfiguration开启自动配置，根据引入的依赖和SpringFactories机制自动装配相应的Bean。

5.4 给项目加分的三个扩展方向

完成基础版本之后，如果时间和精力允许，建议扩展以下能力：

引入MyBatis-Plus增强工具：实体类加@TableName注解后，BaseMapper直接提供insert、selectById、updateById等常用方法，省掉大量XML文件。项目中80%的单表CRUD可以简化，只保留复杂查询的XML。成品课设如果还没用MP，可以自行引入，这个改动会让代码量急剧下降，同时体现你对业界常见工具的掌握。

增加Excel导出功能：使用阿里巴巴EasyExcel，把药品库存列表导出为Excel表格。这个功能在真实业务场景中是刚需，医药公司每个月都需要导出进销存报表给财务。答辩时演示一下“查询药品列表-点击导出-浏览器下载xlsx”，效果极其加分。

引入日志记录切面：使用AOP统一记录用户操作日志。用@Aspect定义一个切面，拦截Controller层的所有请求，记录操作人、操作时间、调用的方法、传入的参数。这在进销存系统里是合规审计的要求，也侧面体现你有工程意识。

前面提到的“SpringBoot整合Flink做实时销售分析”，在毕业设计级别属于高阶扩展，难度较大且很难在短时间内跑出让人信服的效果。真正想做数据分析展示，更务实的方案是结合定时任务和MySQL分区表统计每日销售汇总即可，这个实现量可控，还能演示出“数据汇总-可视化展示”的闭环。

5.5 源码使用过程中的思路建议

最后给尚在纠结要不要直接用这套源码的同学说几句掏心窝的话：

直接用现成源码本身没有错，错的是拿过来之后不做任何理解和改造就交上去。我的建议是：第一阶段完整跑通项目，挨个功能点操作一遍，搞清楚每个按钮背后发生了什么SQL操作；第二阶段把核心业务的代码精读一遍，尤其是采购入库和销售出库的Service实现类，确保你能用自己的话复述整个流程；第三阶段做“换皮改造”，比如把药品模块扩展为中草药、添加药品批号管理、药箱绑定变更为社区用药点，这些改动让你的项目与原始版本拉开差距。

改的时候优先从数据库入手，加表和加字段是最简单的差异化；其次加页面，多写几个查询和统计接口，前端菜单加几项；最后才是动核心逻辑，因为核心逻辑的改动极易引入Bug。保持“数据库先行、接口次之、页面最后”的顺序，改造效率最高。

我见过太多同学，答辩的时候被问到自己项目的表结构都答不出来，或者项目启动日志一堆红色报错不明所以，与其这样，不如笨办法多跑几遍，把日志中每一个WARN和ERROR都搞清楚来龙去脉。这套系统对你而言，不仅仅是一个毕业设计的学分，更是第一次完整地经历“需求-设计-开发-测试-文档-答辩”的软件工程全流程，认认真真走完这一轮，你收获的东西远超分数本身。