企业官网建设流程全解析

又是一个被"智能药箱"四个字吸引的毕设选题。说实话，前年我帮某高校的学弟做信息管理系统方向密集评审时，见过很多版本的药箱项目——有的其实就是个带CRUD的药品台账，有的硬塞一堆物联网硬件最后根本跑不通。而这个基于Spring Boot的智能药箱系统，是我认为在纯软件条件下，功能完整度和答辩可讲性平衡得相当不错的一个方向：它既有常规的药品信息管理，又包含了"我的药箱"这类用户维度业务，还串起了服药提醒的定时任务逻辑，恰好能让评委看到你不仅会写增删改查，还能处理真实业务里的状态流转和时间调度。这篇文章就把这个项目的玩法掰开揉碎讲清楚，无论你是打算直接拿来交毕设，还是想参考它的业务设计写成自己的东西，都能用得上。

1. 智能药箱系统的功能边界：药品信息、我的药箱、服药提醒如何分工

很多人在设计这类系统时容易犯一个毛病：一上来就怼功能，想到哪写到哪，最后权限乱成一锅粥。我在搭建这个项目前，先把业务拆成了两条主线：一条是"平台有什么药"，另一条是"用户吃了什么药"。药品信息管理管前者，我的药箱和服药提醒管后者，三条线各有侧重，页面归属也完全分开。

1.1 药品信息管理：不只是药品表增删改查

药品信息模块在系统里承担的是主数据角色。它包括药品名称、通用名称、规格、生产企业、批准文号、用法用量、库存数量和药品分类。这里要特别注意区分"药品名称"和"通用名称"两个字段——很多人在做毕设时直接合并成一个字段，这在答辩时很容易被问住：为什么同一款药在不同厂家下名称不一样？怎么保证用户搜索"布洛芬"能同时找到混悬液和缓释胶囊？如果你不做字段分离，就没法给出去一个合理的回答。

在这个模块里，我设计了一个药品分类的层级结构，比如按"处方药/非处方药"、按"内科/外科/皮肤科"双维度标记。页面上用关键字模糊搜索 + 分类联动筛选，列表支持分页。后端对应的接口就是标准Restful风格：GET /api/drugs、POST /api/drugs、PUT /api/drugs/{id}、DELETE /api/drugs/{id}。所有数据落在MySQL里，字段约12个左右，足够撑起主页面展示和管理员操作。

1.2 我的药箱：用户和药品之间的"从属关系"

"我的药箱"是这个项目区别于普通药品管理系统的关键模块，也是评委比较关注的用户维度业务。它的本质是一张关联表：当前登录用户ID + 药品ID + 药品数量 + 有效期截止日期 + 加入时间。换句话说，用户从平台药品库中挑选药品放进自己药箱，可以调整数量，也可以移出。这个设计实实在在体现了"系统有用户体系"和"数据按用户隔离"，不是所有用户看同一份数据。

在实现上，药箱列表还需要回显药品信息，所以查询时要关联药品主表。这里我用了一个小技巧：不要把药品的所有字段都冗余到药箱表里，只需要冗余一个药品名称快照字段，其余信息实时关联查询。为什么不做全冗余？因为药品信息是管理员统一维护的，如果药箱表冗余过快照，管理员修改库存时用户药箱里显示的还是老数据，逻辑上说不通；但完全不做冗余，列表页每行都要跨表join，写着也累。折中方案就是冗余一个名称字段用于展示，数量、有效期这类药箱特有属性存自己表里。

1.3 服药提醒：从"数据记录"到"业务闭环"

服药提醒是整套系统里最有技术故事可讲的部分。它不是一个简单的表加几个字段就完事，而是涉及到计划、执行、反馈的闭环：用户为药箱中的某条记录设定服药计划，例如"每天早饭后一粒、睡前两粒"，系统在到达计划时间时生成提醒（站内消息或记录待办），用户点击确认服药后，计划状态由"待提醒"变为"已完成"；如果用户没有操作，超过计划时间后状态自动变为"已过期"。

这种状态流转是毕设答辩中特别容易出彩的细节。我会在下面的章节里单独展开讲它的数据库设计和定时任务实现思路，这里先理清概念：药品信息管"有什么药"，我的药箱管"谁有什么药"，服药提醒管"什么时候吃、吃了没有"。三层递进，边界清晰，评委一眼就能看懂你的业务建模能力。

2. 数据库设计：四张核心表如何撑起整个业务闭环

如果只看前端页面，你可能觉得这系统也就那么回事。但把数据库表结构设计好，才是项目能跑通、答辩能讲深的基础。我印象最深的是某次评审时有个学生做类似的系统，业务逻辑写在SQL里，表结构却只拆了三张表，用户和药箱关系直接靠user_id字段一对多硬塞，结果服药提醒根本没法实现"一条记录对应多条计划"。这个项目里我把表结构拆成了四个核心部分，下面逐个讲清楚。

2.1 药品信息表与药箱表：一对多还是多对多？

先看药品主表（drug_info），核心字段我定义为：

药箱表我命名为user_medicine_box，它不叫user_drug，原因是你存的是"药箱里的一件物品"，它有自己的数量、有效期、加入来源，而单纯叫"用户药品关联表"会让人以为这只是个关系表。这个表里有user_id、box_drug_id、quantity、expire_date、add_time几个字段，每一行都代表用户药箱里的一种药品。

关联关系上，一个用户可以拥有多种药品，一种药品也可以存在于多个用户药箱中，所以这是一张多对多关联表。不要试图在药品主表上直接加user_id字段，否则所有用户共享同一份药品数据，一改全局都变，会乱套。

2.2 服药计划与记录表：时间驱动型业务的关键建模

服药提醒要落实，必须有服药计划表medication_plan，对应的是"用户药箱里某一药品的一个用药计划"。字段设计上我列了这些：

• id：主键
• user_id：用户
• box_id：药箱记录ID
• drug_name：药品名快照，方便提醒展示
• plan_time：计划执行时间，比如2025-05-01 08:00
• dosage：本次用量描述，比如"1粒"
• status：状态，0待执行、1已完成、2已逾期、3已取消
• remind_time：实际生成提醒的时间
• confirm_time：用户确认服药的时间

你可能注意到我加了一个box_id而不是直接关联drug_id，这很重要：同一个用户可能在药箱里有同一药品两条库存不同、有效期不同的记录，计划必须指向具体的那一条药箱记录，否则盘点时无法确认是消耗了哪一批次。这就是我在前面强调的表结构分层：计划表依赖药箱表，药箱表依赖药品表。

另外，我还单独建了一张reminder_log表来处理历史提醒记录，每次定时任务触发生成提醒时往这里插一行。这样即使用户从未查看，也能在页面上看到"今天系统提醒过你3次服药"，这个展示数据在答辩演示时能发挥很大作用——它证明定时任务真正在跑，而不只是演示点按钮。

2.3 数据关系汇总：一张图讲清链路（但用文字）

如果要把关联关系用最简短的话总结：药品信息是字典，我的药箱是该字典复制到用户维度的实例化结果，服药计划是药箱记录在时间轴上的动作安排，提醒日志是动作的执行痕迹。在写对话和答辩时，反复强调"字典 - 实例 - 动作 - 痕迹"这四层结构，会比你背诵任何概念都更有说服力。整体来说，这套表结构匹配了Spring Boot + MyBatis-Plus的简单查询逻辑，不碰多级嵌套查询就能实现全部页面，对毕设来说支撑力完全够了。

3. 服药提醒核心逻辑：定时任务如何扫描、判状态、触达用户

服药提醒一旦进入实现层面，就不再是"用Quartz配个cron表达式"那么一句话带过的事。这里真正的难点有三个：什么时候扫描、怎么判断一条计划是否需要提醒、提醒之后怎么让用户在页面上看到状态变化。这套逻辑如果用不好，最典型的翻车现场就是——数据库里存了一堆plan_time，到了时间没有任何动作，答辩现场演示翻车。

3.1 定时扫描策略：轮询 vs 延迟队列，实际怎么选

当前项目用的是Spring Boot内置的@Scheduled注解配合固定间隔轮询实现，核心代码贴在下面：

@Component @Slf4j public class MedicationRemindTask { @Autowired private MedicationPlanMapper planMapper; @Autowired private ReminderLogMapper logMapper; // 每30秒扫描一次待执行计划 @Scheduled(cron = "0/30 * * * * ?") public void scanPendingPlans() { List<MedicationPlan> pendingList = planMapper.selectList( new LambdaQueryWrapper<MedicationPlan>() .eq(MedicationPlan::getStatus, 0) .le(MedicationPlan::getPlanTime, new Date()) ); if (pendingList.isEmpty()) { return; } for (MedicationPlan plan : pendingList) { processOnePlan(plan); } } private void processOnePlan(MedicationPlan plan) { plan.setStatus(1); // 已完成 plan.setRemindTime(new Date()); planMapper.updateById(plan); ReminderLog log = new ReminderLog(); log.setPlanId(plan.getId()); log.setUserId(plan.getUserId()); log.setDrugName(plan.getDrugName()); log.setRemindContent("该服药了：" + plan.getDrugName() + " " + plan.getDosage()); logMapper.insert(log); // 可选：接入WebSocket推送消息 } }

为什么选轮询而不是延迟队列？因为这是单机项目，没有引入消息中间件，也没有高并发量级的真实在线用户。用一个线程每隔30秒扫一次状态为"待执行"且计划时间已经到达的记录，足够满足演示需求。如果你硬要上RabbitMQ延迟队列或Redis过期键监听，反而会让项目复杂度失控，而且断电重启后Redis过期监听可能丢消息，到时候排错的代价会大到你怀疑人生。所以毕设场景里，轮询是最稳、最能自洽的方案。

这里有个性能相关的坑：@Scheduled默认是单线程调度池，如果任务扫描一次耗时太长会阻塞后面的任务。在真实项目里并发量上来后要自己定义ThreadPoolTaskScheduler并设置pool-size，但这个毕设项目里数据量撑死几万条，默认配置完全没问题。答辩如果要往深讲，提一句你了解这个限制即可，千万别画蛇添足。

3.2 状态机处理：已过期不是"更新一下"那么简单

在提醒的执行动作里，我把状态字段设计成四个值，每两个状态之间的切换都有一套明确的逻辑限定。比如计划时间到了但用户没确认，不能直接标记为"已过期"，否则页面下拉刷新后提醒消息突然从"待执行"变成"过期"，用户一头雾水。正确做法是：到计划时间的那一刻先生成提醒日志、把状态置为"已完成"，这个"已完成"可以理解为"系统已完成提醒动作"，而不是"用户已完成服药"。

那"用户确实没吃"这个信息怎么表达？我增加了一个独立的逾期定时任务，每天零点跑一次，把前一天状态是"已完成"且confirm_time is null的计划记录标记为"已逾期"，同时生成一条"您昨天有1次未确认的服药计划"的日志。这样逻辑就闭环了：

• 状态0：计划已创建，时间未到 → 定时任务A扫描触发提醒
• 状态1：系统已提醒，等待用户确认 → 用户点击确认，填confirm_time
• 状态2：超期未确认 → 定时任务B每天零点标记，状态不可变回

这个设计是我在写这个项目时觉得最有答辩价值的一个点。很多人做出来的药箱系统只有"提醒"没有"逾期"概念，而这个设计本质上引入了简单的状态机，它能让评委看到你不只是会用if else判断页面按钮，而是懂得用状态约束业务流转。

3.3 触达用户的两种方案对比：站内轮询 vs WebSocket

提醒生成之后怎么让用户"立刻"知道？常见两种实现：前端Ajax定时轮询接口拉最新提醒数据，或者后端接入WebSocket主动推送。当前项目为了让演示效果足够直观，我在前端做的是每5秒钟请求一次/api/remind/latest接口，把最新3条提醒放在页面顶部横幅。这个方案在局域网演示时几乎无延迟，代码量也小。

如果在答辩时被问到"为什么不直接用WebSocket"，你要能回答出来：WebSocket建立连接后服务端需要维护长连接，多用户场景下要写连接管理器，应用重启后连接全部断开，还要处理心跳重连，这些对毕设来说都是额外的复杂度；而轮询虽然做不到毫秒级实时，但对"服药提醒"这种分钟粒度场景完全够用。如果你想让项目显得更有能力，可以在轮询接口里加一个timestamp参数做增量查询，只返回新提醒，这样网络开销也很小，还能讲出一套"基于时间戳的增量拉取"方案。

4. 从源码到可演示：项目落地过程中的关键路径与排错记录

拿到一套带源码带文档的Spring Boot项目，第一件事不是打开IDEA就点运行，而是先把环境和代码结构捋一遍。我在第一次跑通这个项目时，前后也遇到过一些不大不小、但确实很多初学者会卡壳的问题。把这段落地的真实过程整理出来，帮你少走弯路。

4.1 环境准备：JDK版本、MySQL字符集、初始化数据的三件套

这个项目的运行环境大概是这样：JDK 1.8以上（建议直接上JDK 11，兼容性和Spring Boot 2.x配合更稳）、Maven 3.6+、MySQL 5.7或8.0。拿到源码后先把application.yml打开，改三处：数据源URL里的数据库名字、用户名、密码。很多人栽在数据库字符集上——SQL脚本里包含中文药品名，建库时如果没指定utf8mb4，导入后中文全部变问号。建议建库时执行：

CREATE DATABASE IF NOT EXISTS smart_medicine_box DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

所有表默认都用utf8mb4，因为这个字符集不仅支持中文，连生僻字和多字节Emoji都能存，属于一步到位的选择。初始化数据不要手动一条条录，直接使用项目自带的sql/init.sql脚本导入，里面有测试账号、药品分类、药品样例数据。我第一次演示时就是懒得导数据，手动插入药品信息花了一个多小时，还差点把外键关系弄崩，血泪教训。

4.2 运行阶段最常踩的坑：参数映射失效、懒加载序列化报错、时间差8小时

我整理一下调试过程中最有代表性的三个问题，每个都附上解决思路，让你遇到时不至于一脸懵。

第一个坑是前端传参后端的实体映射全是null。排查下来发现原因是对接时前端传的是drugName，后端实体字段叫drug_name，在Spring Boot默认配置下application.yml里的map-underscore-to-camel-case没打开，导致下划线字段无法自动映射到驼峰属性。解决方法是确保MyBatis-Plus配置文件里设置了map-underscore-to-camel-case: true，或者在实体字段上写@TableField("drug_name")。简单说，任何字段映射问题优先检查全局下划线转驼峰配置，不用急着改实体。

第二个坑是查询药箱列表后向前端返回JSON时报LazyInitializationException或无限递归序列化错误，原因是我把MedicationPlan里关联了MedicineBox对象，而MedicineBox里又反向关联了MedicationPlan的集合，Jackson序列化时出现循环引用。处理方案是保持实体只存ID不做对象关联，需要展示药品名时直接从关联的MedicineBox拉取后再封装到VO。这也是我在2.2里设计字段时特意加了drug_name快照的另一个原因——回避掉复杂的懒加载序列化问题，代价只是多存了一个冗余字段，这在毕设项目里完全可以接受。

第三个坑是服药计划时间相差8小时。计划设置的是早上8点，数据库存的时间却是凌晨0点，原因是JDBC连接串里的serverTimezone=UTC把时区写死了。把它改成Asia/Shanghai即可。排查这类问题的最快姿势是：先在数据库客户端执行select now()看数据库时间，再在后端打印new Date()看系统时间，两边差出来的时间差就是时区问题的根源。

spring: datasource: url: jdbc:mysql://localhost:3306/smart_medicine_box?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

4.3 演示彩蛋：如何让评委一眼看出系统在"动"

有一个小技巧很多人不知道，如果纯静态展示页面，评委很难直观感受"定时任务在跑"。我在演示时会把系统时间调成比当前时间快1分钟，然后打开计划列表页，刷新页面时恰好看到一条新提醒冒出来，配合页面的时间记录，观众立刻就能理解这个系统的提醒链路是真实工作的。如果不想改系统时间，也可以在数据库里把某条计划的plan_time改成两分钟之后，然后打开提醒横幅区域，等它自动弹出。这个小操作几乎零成本，但演示效果非常好。

5. 文档阅读与答辩加分：别把一手好牌打成流水账

源码和文档同时到手，很多人的做法是直接看代码、不看文档。但我建议反过来：先读文档的需求分析部分，读完后在脑子里形成一个业务地图，再去看代码验证，效率会高很多。对于要参加答辩的同学，文档结构实际上等于你答辩的讲稿大纲。

5.1 毕设文档的标准结构：需求到实现的映射逻辑

一套像样的毕设文档通常包含这六个部分：课题背景与意义、需求分析（功能需求+非功能需求）、系统设计（总体架构+功能模块+数据库设计）、系统实现（核心代码+主要流程截图）、系统测试（测试用例+结果分析）、总结与展望。在这个智能药箱项目里，文档质量的好坏取决于需求分析和数据库设计是否一致。我见过太多文档，需求分析里写了"管理员可以审核药品信息"，但数据库里连审核字段都没有，代码也没有对应逻辑，这就是明显的文不对题，答辩几乎必被挑刺。

读文档时，建议重点关注"需求分析 -> 数据库设计 -> 核心实现"这三者的对应关系，每读到一个功能需求就去数据库表里找对应字段，再去代码里找对应Controller方法。这个习惯不仅帮你快速吃透项目，还能在答辩时展现出你对系统整体脉络的把握力。

5.2 能让你拿高分的三个扩展方向

如果做完基础功能还想往深处走一步，我推荐以下三个方向，每个都有可落地的方案，不会变成空中楼阁：

第一个是接入简单的数据统计。目前系统已经记录了每次提醒和确认的日志，完全可以加一个页面展示"本周按时服药率""累计提醒次数"等图表数据。实现上不需要引入复杂报表组件，用ECharts从后端接口拉JSON数据就能画出来。这个功能成本低、演示效果好，还可以把服药提醒的价值从"功能"提升到"数据洞察"。

第二个是设计一个合理的管理员审核机制。药品信息不是管理员一提交就能上架，而是进入待审核状态，由另一个管理员账号审核通过后才可展示。这需要你在药品信息表加一个audit_status字段，并写一个简单的状态更新接口。它也不复杂，但能体现出权限角色分工的设计意识。

第三个是给服药提醒接入第三方推送能力。当前系统用的是站内轮询，扩展时可以选择接入邮件提醒或微信模板消息。虽然网关和资格是我们普通人不容易拿到的，但短信和邮件API是有的。你可以设计一个通用的Notifier接口，先实现邮件提醒、再扩展其他渠道，这种"面向接口而非面向实现"的设计思路在答辩中是很受欢迎的。

5.3 答辩高频追问的应答思路

根据我多年跟毕设项目打交道的经验，针对智能药箱这一类系统，评委最爱问的其实就那几个角度：为什么选择Spring Boot而不选SSM？你要回答的是Spring Boot自带了内嵌服务器、自动配置和Starter依赖简化，让开发聚焦业务逻辑，而不是花时间配置XML和容器；为什么定时任务用@Scheduled而不是xxl-job或ElasticJob？你要答的是当前场景的单机低并发特性，以及这些分布式任务调度框架引入后的额外成本；表设计时为什么加冗余字段？你要答的是用适当的冗余换查询性能，同时保证核心数据一致性由主表维护。

每个问题都不用长篇大论，抓住"场景匹配"这个核心逻辑去回答，基本不会翻车。怕的就是你背概念，一背就露怯。

写在最后：这个项目对毕设选题的真正启发

如果你只是想要一个能跑的毕设，那么这个智能药箱系统直接按照文档部署，换一套属于自己的页面颜色和Logo，补上数据库里个人化的测试数据，已经足够应付大多数学校的中期答辩和终期演示。但如果你想从"能跑"到"能讲出深度来"，我建议认真花时间吃透的既不是代码本身，也不是某个炫技的中间件，而是前面提到的业务分层设计思路：主数据、用户实例、动作计划、执行痕迹，这四层结构其实是很多业务系统的通用框架。

我在实际接触这类项目的过程中最深的体会是，毕设拿高分的秘诀往往不在于功能有多少，而在于你能否让评委感觉到"这个学生做系统的时候动过脑子"。一个把状态流转图讲得清清楚楚、能解释清楚为什么要用轮询而不是消息队列、能说明白数据库字段为什么这么设计的同学，哪怕功能只做了几个页面，也会比那种堆了十几个模块每个都是Ctrl+C然后背不出一个细节的同组人拿到的成绩好得多。智能药箱系统里埋的这些设计思考，恰好就是你向评委展示"我动过脑子"的最好素材。如果你也准备选这个方向，建议别急着一头扎进代码，先把我上面那张四层结构图在脑子里盘三遍，再动手，绝对事半功倍。