简介：这是一份基于Java技术、SSM框架与MySQL数据库实现的自助购药小程序完整成品，面向毕业设计、课程设计及小程序开发者。系统覆盖首页、个人中心、用户管理、商家管理、药品信息管理、药品分类管理、发票信息管理与系统管理等核心模块，可支撑药品搜索、浏览、下单及支付等完整业务链路。压缩包共1319个文件，包含Java后台源码、Vue前端页面、WXML/WXSS小程序文件、JSON配置以及SQL数据库脚本等，体积为22.55MB，目录结构清晰便于按模块查阅。已有57人学习或下载，适合需要快速搭建同类项目并进行二次开发的读者。资源内置部署运行脚本和数据库文件，可帮助使用者省去环境配置与数据初始化环节，直接导入工程即可启动验证。

1. 需求拆解：为什么是“小程序 + SSM”而不是单页应用

做自助购药类的毕业设计或课程设计时，很多同学第一反应是上 Spring Boot 前后端分离，再配一个 Vue 管理后台。但真正动手才发现：课题要求里写的是 Java 实现，演示现场要能跑通从下单到开发票的完整闭环，而 Spring Boot + Vue 这套组合里任何一个版本漂移都可能把自己卡死在环境问题上。这套方案选择了 SSM 框架 + 微信小程序 + MySQL 5.7 的老牌组合，反而是最稳的路线。它适合两类人：一类是正在做 Java 方向毕设、课设，需要一套能跑通、能讲清、能答辩的完整源码；另一类是已经有业务想法、想快速拿一套带管理后台和小程序端的电商底座做二次开发的从业者。本文会从需求背景、技术选型、总体设计、关键实现一直讲到验收答辩，把这份自助购药小程序源码项目的完整方案摊开来讲。

2. 技术选型：SSM 组合、MySQL 5.7 与双端开发环境的分工

自助购药小程序本质上是一个垂直领域的电商系统，核心链路是「用户搜索药品 → 浏览详情 → 下单 → 支付 → 商家处理 → 发票开具」。要支撑这条链路，后端必须处理商品、订单、用户、商家、发票这几类核心数据，前端则需要同时覆盖小程序用户端和后台管理端。技术选型时会优先考虑三点：课题环境的兼容性、代码结构的可讲解性、部署过程的稳定性。这套项目在这三点上做得非常规矩，下面逐个拆解。

2.1 SSM 框架：为什么这个场景不用 Spring Boot

项目后端采用 SSM 框架，即 Spring、SpringMVC、MyBatis 三者的整合。很多同学在课设里已经习惯 Spring Boot 的自动配置，回到 SSM 会觉得配置繁琐，但放在这个场景里，SSM 有三个不可替代的优势。

第一，Spring 负责 Bean 管理和事务控制，SpringMVC 负责请求分发和参数绑定，MyBatis 负责 SQL 与 Java 对象的映射，三层职责边界清晰。答辩时被问到「某个请求进来之后经过了哪些组件」，你可以顺着 DispatcherServlet → Controller → Service → Mapper 这条链路完整讲出来，这是评委最想听到的经典调用过程。第二，MyBatis 的 XML 文件里每条 SQL 都是显式可控的，药品按名称模糊查询、按分类筛选、按上下架状态过滤，这些条件都写在 mapper XML 里，比 JPA 的自动生成 SQL 更好解释。第三，SSM 对部署环境的要求低，Tomcat 7 加 JDK 1.8 就能稳定跑起来，不会碰到 Spring Boot 3.x 要求 JDK 17 这类强制升级的问题。

从工程结构上看，SSM 项目通常按 controller、service、mapper、entity 四层分包，每个层级的职责单一，调试时也容易定位问题。对于课程设计答辩来说，这种结构比「启动类 + 一堆注解」的 Spring Boot 项目更容易展开讲。

2.2 数据库与连接：MySQL 5.7 + Navicat 11 的组合逻辑

数据库选型直接用了 MySQL 5.7，而不是 8.0 或更高版本。这不是保守，而是这个项目场景下的务实选择。MySQL 5.7 是过去几年高校实验室和培训机构中使用最广的版本，它的 SQL 语法、默认字符集、事务隔离级别与很多现成的课设代码完全兼容。最典型的例子是数据库连接驱动：5.7 环境下使用mysql-connector-java5.x 版本，连接串里不需要写serverTimezone参数，JDK 1.8 也不用处理时区换算问题；而一旦换成 MySQL 8.0，驱动必须升级到 8.x，同时要额外配置时区，很多同学翻车就翻在这一步。

数据库管理工具选用 Navicat 11，它提供图形化的建表、导数据、执行 SQL 功能。项目附带数据库文件可以直接导入，导入后能看到完整的表结构和示例数据。这个细节对课设非常重要：评委查看数据库时不会只看 ER 图，他们会直接打开表看字段设计和数据内容，一份带分类、带药品名称、带库存数量的示例数据比空表更有说服力。

2.3 前端工具链：微信开发者工具与 HBuilderX 的分工

小程序端的开发涉及两个工具：HBuilderX 和微信开发者工具。HBuilderX 在这里的作用偏向工程管理——它支持 Vue 语法开发小程序，可以创建小程序项目结构、编写页面代码和逻辑代码；微信开发者工具则承担预览、调试、真机测试的角色。实际工作时存在两种用法：一种是完全用微信开发者工具从零创建原生小程序项目，另一种是先在 HBuilderX 里维护代码，再导入到微信开发者工具里预览。这套项目按后者的思路组织，核心页面代码是原生小程序语法，兼容性强，直接导入微信开发者工具即可运行。

要注意的是，小程序端的网络请求必须指向后端接口地址，由于 Tomcat 部署在本机，开发调试时通常把接口地址配置为http://localhost:8080/项目名。如果项目名带中文或特殊字符，路径解析会出现问题，建议在发布配置里显式设置 context path。

2.4 环境参数对照表

开发环境是课设项目最容易出问题的地方，版本差异会导致各种玄学报错。下面把这份源码的完整环境参数整理成对照表，你拿到源码后按这张表逐项核对，基本可以避免一半的部署问题。

这套环境中，JDK 1.8 和 Tomcat 7 是绑定关系，MySQL 5.7 和mysql-connector-java5.x 是绑定关系。只要版本绑定的逻辑不乱拆，部署阶段基本顺畅。如果你之前只熟悉 Spring Boot 的自动化部署，第一次用 Maven 手动打 war 包可能会不习惯，但多跑两次clean package就能理解整个构建链路。

3. 总体架构设计：七类功能模块与数据库表的映射关系

自助购药小程序的业务规模不大，但角色区分明确：普通用户在小程序端浏览和下单，商家在后台管理药品和订单，管理员处理用户审核、分类维护和系统配置。如果把三个角色的需求混在一起设计，系统会变得臃肿。这套系统的设计思路是先按 B/S 三层结构搭骨架，再按角色划分功能模块，最后用数据库表把模块串起来。

3.1 B/S 三层结构与 Maven 工程目录

系统整体采用 B/S 架构，表现层、业务层、数据层三层分离。表现层由两部分组成：面向用户的微信小程序端和面向管理员/商家的后台管理页面。后台管理页基于 Bootstrap 类的后台模板实现，登录后根据角色加载不同菜单。业务层对应 Service 接口及其实现类，负责具体业务规则，比如用户注册时检查手机号是否重复、下单时校验药品库存、发票申请时校验订单状态。数据层是 MyBatis 的 Mapper 接口和 XML 文件，负责与 MySQL 交互。

Maven 工程结构一眼看去是标准的 SSM 分层：

src/main/java ├── controller # 控制层，接收请求，返回 JSON 或页面 ├── service # 业务层接口 ├── service/impl # 业务层实现 ├── mapper # MyBatis 数据访问接口 ├── entity # 实体类，对应数据库表 └── config # Spring 与 SpringMVC 配置 src/main/resources ├── mapper/*.xml # MyBatis SQL 映射文件 ├── spring/ # Spring 核心与 SpringMVC 配置文件 └── jdbc.properties # 数据库连接配置 src/main/webapp ├── admin # 后台管理页面 └── WEB-INF/web.xml # 项目部署描述文件

controller 层只做参数接收和结果返回，不写业务逻辑；service 层处理核心逻辑，事务注解加在实现类上；mapper 层只做数据读写。这种分层的价值在于答辩时能清晰说出「数据是怎么一层层流转的」。

3.2 七个功能模块的职责边界

系统功能模块按摘要描述包括首页、个人中心、用户管理、商家管理、药品信息管理、药品分类管理、发票信息管理、系统管理。其中首页和个人中心主要在小程序端呈现，其余模块在后台管理端承载管理功能。

首页模块负责药品展示、分类导航、搜索入口和轮播图位，数据来源于药品信息表和药品分类表。个人中心模块管理用户的登录状态、收货地址、历史订单和发票申请入口。用户管理模块面向管理员，负责查看注册用户列表、禁用/启用账号、重置密码。商家管理模块处理商家入驻信息的审核，审核通过后商家才能登录后台维护自己的药品。

药品信息管理是核心模块，支持药品的添加、编辑、上下架、库存调整、价格修改和图片上传。药品分类管理维护药品的一级分类和二级分类，前端首页的分类导航直接读取该表。发票信息管理记录用户申请的开票请求，包含发票抬头、税号、金额、开票状态等字段。系统管理则配置轮播图、公告、系统参数等信息。

七个模块看似各自独立，实际上围绕「药品」和「订单」两条主线交织。模块的职责边界划分清楚之后，数据库表的设计也就顺理成章了。

3.3 数据库设计：核心表结构与字段说明

数据库设计遵循电商系统的常规做法，核心思路是「用户表与商家表分离、药品表与分类表关联、订单表与发票表关联」。实际项目中通常包含以下核心表：

药品表通过category_id关联分类表，实现前端按分类筛选；通过status字段控制上下架，下架药品在小程序端不再展示。订单表用order_no做唯一业务编号，用status字段标记订单状态流转，通常的取值为：待付款、已付款、待发货、已发货、已完成、已取消。发票表通过order_id关联订单，保证一笔订单只能申请一次发票，这个逻辑在 service 层通过唯一性校验实现。

3.4 角色权限与页面路由

系统的权限控制采用「角色 + 菜单」的方式。管理员登录后台看到全部菜单；商家登录只能看到药品信息管理、订单信息、发票信息；普通用户在小程序端没有后台访问权限。这个控制在后台页面路由层面实现，登录后把角色标识存入 session，每个页面加载时校验权限，无权访问时跳回登录页。

小程序端的路由则按用户操作流设计：落地首页 → 搜索/分类浏览 → 药品详情 → 确认订单 → 支付 → 订单列表 → 申请发票。每一步都有对应的页面和接口，路由参数中传递药品 id、订单 id 等关键信息。整体设计对新手很友好，因为每个页面只承担一个职责，调试时定位问题非常直接。

4. 关键实现：从后端 Controller 到小程序端的药品查询与下单闭环

需求设计和数据库表结构确定之后，核心工作落在前后端联调上。这一章选择药品信息查询和下单两条链路做拆解，因为它们覆盖了后端接口、数据库操作、小程序端请求封装三个关键环节。完整的业务代码在源码包里，这里的实现重点是让你理解代码的组织方式。

4.1 后端控制层：药品信息的分页查询接口

药品列表是首页最高频的接口，需要支持分页、名称模糊搜索、分类筛选、上下架状态过滤。Controller 层代码通常写成这样：

@Controller @RequestMapping("/drug") public class DrugInfoController { @Autowired private DrugInfoService drugInfoService; @RequestMapping("/list") @ResponseBody public Map<String, Object> list(DrugInfo drug, Integer page, Integer limit) { PageHelper.startPage(page, limit); List<DrugInfo> list = drugInfoService.selectByCondition(drug); PageInfo<DrugInfo> pageInfo = new PageInfo<>(list); Map<String, Object> result = new HashMap<>(); result.put("code", 0); result.put("msg", "success"); result.put("count", pageInfo.getTotal()); result.put("data", pageInfo.getList()); return result; } }

这段代码用 PageHelper 做分页插件，page和limit由前端传入，分别代表页码和每页条数。DrugInfo实体对象作为查询条件载体，前端传入的drugName、categoryId、status会被自动绑定到对象的对应属性。返回值统一封装为code / msg / count / data结构，这是后台管理表格组件和小程序端都能直接解析的通用格式。

4.2 MyBatis 条件查询：动态 SQL 的写法

Service 层在查询时直接把DrugInfo对象传给 Mapper，MyBatis 在 XML 里动态拼接 SQL。这也是 SSM 项目中最值得在答辩时展开讲的一段：

<select id="selectByCondition" resultType="com.example.entity.DrugInfo"> SELECT * FROM drug_info <where> <if test="drugName != null and drugName != ''"> AND drug_name LIKE CONCAT('%', #{drugName}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC </select>

<where>标签会自动去除第一个条件前的AND，避免 SQL 语法错误。药品名称使用LIKE CONCAT('%', #{drugName}, '%')实现模糊匹配，CONCAT函数避免了传参时手动拼接百分号造成的 SQL 注入风险。这条 SQL 同时服务了首页搜索框、分类页筛选、后台药品列表三个场景，一段 SQL 多处复用，符合课设项目的合理抽象。

4.3 小程序端请求封装与页面数据绑定

小程序端不能直接使用浏览器的 axios 或 fetch，所有的网络请求都通过wx.request发出。实际项目中会做一个统一的 request 封装，避免每个页面重复写回调：

const BASE_URL = 'http://localhost:8080/drug-miniapp'; const request = (url, method = 'GET', data = {}) => { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method, data, header: { 'Content-Type': 'application/json' }, success: (res) => { if (res.data.code === 0) { resolve(res.data.data); } else { reject(res.data); } }, fail: reject }); }); }; // 页面中调用：搜索“感冒”分类下的药品 request('/drug/list', 'GET', { page: 1, limit: 10, drugName: '感冒', categoryId: 3 }).then((list) => { this.setData({ drugList: list }); });

BASE_URL中的端口号必须与 Tomcat 的部署端口一致，项目名如果修改了，这里也要同步。封装后的 request 返回 Promise，页面代码可以用then链式调用，避免了回调嵌套的「金字塔」结构。数据绑定方面，小程序用setData更新页面数据，所有字段拼接在data中一次传入，多次调用会触发多次渲染，因此要避免在循环里频繁setData。

4.4 下单与发票的交互链路

下单链路是用户端到后端数据库的完整闭环。用户在药品详情页点击「立即购买」后，小程序端携带drugId和quantity请求下单接口；后端先查询药品当前库存，判断是否大于下单数量，库存不足则返回提示；库存充足则生成订单号，状态置为待付款，同时扣减库存。用户支付成功后回调更新订单状态为已付款。这个过程在 Service 层必须加@Transactional事务注解，保证扣库存和生成订单要么同时成功，要么同时回滚，避免超卖。

发票申请在订单完成后发起，用户提交发票抬头和税号，后端写入发票表，状态初始为待开票，商家在后台确认后更新状态。这里有一个常见的设计陷阱：发票表没有做订单唯一性约束，导致同一笔订单可以重复申请发票。通常的做法是在发票表给order_id加唯一索引，并在 Service 层插入前再查一次订单的发票状态。

5. 常见问题与避坑：部署、版本与中文乱码的排查手册

SSM 项目最折磨人的不是写业务代码，而是环境问题。这一章的每一条都是实际部署和调试中反复遇到的坑，按「现象 → 原因 → 解决」的方式梳理，拿到源码后如果跑不起来，直接对照排查。

5.1 Tomcat 7 启动报错：JDK 编译版本不匹配

现象：项目在 Eclipse 或 IDEA 里编译通过，部署到 Tomcat 7 后启动立即报UnsupportedClassVersionError，提示版本号 55.0 或 52.0 之类的错误。

原因：本机 JDK 是 17 或 11，而 Tomcat 7 运行时的类加载器无法识别高版本 JDK 编译出的 class 文件。Tomcat 7 最高支持 JDK 8，源码里的 JDK 版本配置却可能被 IDE 自动改成了高版本。

解决：在 IDE 中把项目编译级别统一改为 1.8。IDEA 中打开 Project Structure，把 Project SDK 设为 1.8，Modules 里的 Language Level 也同步为 8。同时在pom.xml里检查maven.compiler.source和maven.compiler.target是否都是 1.8。改完之后执行 Maven 的clean再重新package，不要只点 Tomcat 的重启按钮，否则仍会使用旧的 class 文件。

5.2 数据库连接失败：MySQL 8.0 驱动与时区问题

现象：项目启动后访问接口，后台报Communications link failure或者The server time zone value ... is unrecognized。

原因：本机安装的是 MySQL 8.0 而不是 5.7，但项目用的驱动还是mysql-connector-java5.x。8.x 版本的 MySQL 服务端默认启用了时区校验，驱动连接串里如果没有serverTimezone参数就会失败。

解决：两种方案任选其一。最省事的方案是本机重装或改用 MySQL 5.7，并导入项目附带的数据库文件。如果必须使用 MySQL 8.0，则把pom.xml中的 mysql 驱动版本改为 8.0.x，并在jdbc.properties的连接串末尾追加serverTimezone=Asia/Shanghai&useSSL=false。要注意驱动升级后，部分tinyInt(1)字段的返回类型可能从 Boolean 变成 Integer，检查实体类中的对应属性类型。

5.3 中文乱码：数据库、页面、Tomcat 三层字符集不一致

现象：后台管理页面新增药品时输入中文，保存后刷新列表变成问号；或者页面上显示正常，但导出数据后 Excel 里乱码。

原因：字符集在三个位置不统一。MySQL 数据库表默认字符集可能是latin1，项目里jdbc.properties连接串缺少年份的characterEncoding，Tomcat 对 POST 请求的编码默认不是 UTF-8。

解决：先确认数据库字符集，执行SHOW CREATE TABLE drug_info，看到DEFAULT CHARSET=latin1就说明中枪了，需要执行ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4。然后改jdbc.properties连接串，追加characterEncoding=utf8。最后在 Tomcat 的server.xml的 Connector 节点上加上URIEncoding="UTF-8"。三处都改完，重启 Tomcat，乱码问题才会彻底消失。

5.4 小程序端请求失败：开发者工具域名校验拦截

现象：小程序页面加载时一直 blank，控制台报request:fail或者提示「不在以下 request 合法域名列表中」。

原因：微信开发者工具默认校验请求域名，本地调试时接口地址是http://localhost:8080，既不是 HTTPS 也不在合法域名列表中，所以请求被拦截。

解决：开发调试阶段，在微信开发者工具的详情设置里勾选「不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」。这个选项只影响本地调试，真机预览时如果关闭了调试模式，同样会被拦截。真实上线必须把后端接口部署到配置了 HTTPS 证书的服务器上，并且在微信公众平台配置 request 合法域名。课设演示通常只需要局域网内真机调试，打开调试模式即可。

5.5 Maven 依赖下载缓慢或失败：镜像与本地仓库

现象：首次导入项目时 Eclipse 或 IDEA 一直卡在 Maven loading，或者报Cannot resolve symbol PageHelper等依赖缺失错误。

原因：默认 Maven 中央仓库在国内访问速度慢，某些依赖版本被限速或连接超时，导致本地仓库里只有残缺的 jar 包。

解决：修改 Maven 的settings.xml，配置阿里云镜像，同时把本地仓库默认路径改为非 C 盘位置。改完后在 IDEA 里执行 Maven 的reimport按钮，强制重新解析依赖。如果某个依赖始终解析不了，可以直接到本地仓库找到对应文件夹，删除.lastUpdated结尾的文件后重新下载。这是 Maven 依赖问题的标准「后悔药」操作。

6. 验收与答辩：按角色走查的演示脚本与高频提问

课设答辩的验收环节，评委不关心你写了多少行代码，他们只关心两件事：系统能不能按需求完整跑通，以及你能不能讲清楚关键设计的理由。提前准备一份按角色走查的演示脚本，比临时翻代码有效得多。

6.1 按角色走查的演示脚本

演示路径建议按照业务链路推进，而不是按菜单顺序挨个点击。推荐顺序是先以普通用户身份在小程序端完成一次完整购药流程，再切换到管理后台查看订单和发票状态，最后用管理员账号演示审核和配置功能。

每完成一步，口头说明对应的数据库变化。比如用户下单后，你在 Navicat 里刷新订单表展示新增记录；商家上下架药品后，刷新药品表展示status字段变化。评委最喜欢看到数据层面的实时联动，这比停留在页面截图有说服力得多。

6.2 答辩高频问题与回答思路

答辩时有三个几乎必问的问题值得提前准备。问「为什么用 SSM 而不是 Spring Boot」时，可以回答：课题环境要求 Java 传统企业级架构，SSM 对 Spring、SpringMVC、MyBatis 各层职责拆分清晰，更容易展示事务控制、SQL 映射等核心知识，同时 Tomcat 7 与 JDK 1.8 的搭配保证了部署环境的稳定性。问「为什么选 MySQL 5.7」时，回答重点是版本兼容性和低成本运维：5.7 与项目使用的驱动版本完全匹配，数据导入导出工具链成熟，适合课程设计场景。问「下单时怎么防止库存超卖」时，直接讲 Service 层的实现逻辑：先查询库存再扣减，两条操作放在同一个事务里，扣减库存的 SQL 使用UPDATE drug_info SET stock = stock - #{num} WHERE id = #{id} AND stock >= #{num}，受影响行数为 0 则说明库存不足，这种原子操作能避免并发下的超卖问题。

答辩演示前把所有环境项检查一遍，这是我做课设项目以来吃过亏后的固定习惯。有一次直接在评委的电脑上插入 U 盘跑项目，结果对方机器装的是 MySQL 8.0，连接参数不匹配当场报错，后来我每次演示都强制走一遍环境清单：JDK 1.8 是否就位、MySQL 5.7 是否启动、端口是否被占用、数据库文件是否已导入、微信开发者工具是否勾选了域名校验。检查一遍只需要两分钟，但能避免的尴尬远超这两分钟的价值。希望这份完整的自助购药小程序方案能帮你顺利跑通项目，答辩时也能稳稳接住评委的每一个提问。

本文还有配套的精品资源，点击获取