SSM中医方剂管理系统毕设源码详解：从数据库设计到功能实现

1. 项目定位与选型解析

1.1 为什么中医方剂管理系统适合作为SSM毕设

先聊一个很多同学看到这个题目都会问的问题：中医方剂管理系统，听起来平平无奇，为什么每年都有大量计算机专业的毕设选它？我的看法是，这类系统恰好踩中了毕业设计的两个核心痛点：业务域足够清晰，以及技术栈足够经典。

从业务域来看，中医方剂管理本质上是一个“带有专业知识属性的信息管理系统”。它包含用户管理、方剂信息维护、中草药字典、方剂与药材的配伍关系、检索查询等一整套典型业务闭环。相比“学生选课系统”“图书管理系统”这类已经被写烂了的题目，中医方剂又有自己独特的领域特征——方剂有组方、有功效、有主治、有用法用量，不是简单的一张表增删改查就能糊弄过去的，这就能在答辩时撑起“业务复杂度”的讨论空间。

从技术栈来看，SSM（Spring + SpringMVC + MyBatis）是过去多年Java Web开发的标准组合，也是很多高校课程设计、毕业设计仍然指定的技术框架。它不像Spring Boot那样把大量配置自动完成，而是需要你手动配置扫描包、事务管理器、视图解析器、MyBatis映射等，这恰恰是指导教师想看到的“学习痕迹”。选SSM做毕设，既不是炫技自找麻烦，也不是技术过于老旧到拿不出手，而是一个稳妥且有代表性的选择。

再说这个标题里的“附源码”，实际上很多同学买源码或找源码的最终目的不只是“交个作业”，而是想在源码基础上做二次修改，保证查重和答辩时能讲清楚自己的设计思路。所以这篇博文我会从源码出发，把它从环境搭建到核心功能实现拆开来讲，重点讲清楚“为什么要这么设计”和“拿到手后怎么改”。

1.2 技术栈选择的背后逻辑

先列一下这个项目通常使用的技术组合：

这当中每一个选型，都有它存在的理由。

SpringMVC作为控制层，核心是前端控制器DispatcherServlet，它把URL映射、参数解析、数据校验、视图渲染这些琐碎的事情全部接管了，开发时只需写@Controller和@RequestMapping。在方剂管理系统中，像“首页展示方剂列表”“点击方剂查看详情”“管理员新增方剂”这些操作，本质都是HTTP请求与业务方法的对应关系，SpringMVC完整的请求-响应流程恰好能把这些动作组织得很清晰。

Spring在这一套组合里承担的是“粘合剂”角色，它的IOC容器管理Service、Mapper等Bean的创建和注入，这样Controller层不用自己new Service对象，Service层也不用自己new Mapper对象。学生做毕设时最容易犯的错是直接在代码里写new，导致分层形同虚设，而Spring从容器层面强制了你按照接口去调用，养成依赖注入的习惯，这一点在后面的扩展和测试中会明显受益。

MyBatis的核心价值在于SQL可控。像方剂管理系统里的“按方剂名称模糊查询”“按主治病症检索”“按包含药材筛选”这类条件查询，SQL的写法非常灵活，MyBatis的动态SQL能力——也就是if、where、foreach这些标签——可以让你在XML里拼出各种组合条件而不需要写一堆Java代码去判断。在很多老工程师看来，MyBatis是“半自动ORM”，需要手写SQL麻烦，但对于有复杂查询需求的业务系统来说，手写SQL反而意味着对性能的掌控力更强。

大家不妨再想一个问题：为什么很多毕设推荐用MySQL 5.7而不是8.0？一个很现实的原因是SSM项目大多基于旧版驱动和连接方式，MySQL 8.0默认使用了新的认证插件，在不修改连接配置的情况下会报“Unable to load authentication plugin”，对新手来说排查成本较高。而5.7版本稳定、占用内存低、兼容性好，网上参考资料也最多。这不是越新越好，而是越稳越好。

1.3 这个系统到底解决了什么问题

问一个很实际的问题：中医门诊或教学场景下，方剂信息如果存放在Excel里或纸质本上，会怎么样？

一个很典型的情况：带教老师想找“治疗风寒感冒、包含麻黄、并且药味不超过8味”的方剂，传统方式只能靠经验回忆或者一页页翻，效率极低。而方剂管理系统的核心价值就是把这些信息结构化，并且提供多维度检索能力。

具体来说，中医方剂管理系统通常面向三类使用者：系统管理员、医师（或研究者）、普通用户（学生或访客）。管理员负责系统基础数据维护，比如用户管理、方剂分类管理、系统日志查看；医师可以新增、修改、删除方剂信息，维护方剂所包含的药材及用量；普通用户则主要是浏览方剂库、按条件查询、查看方剂详情。

这个权限划分本身对应着实际业务中的“能看”和“能改”的区分。一个学生登录系统后，不应该有删除方剂的权限，更不应该有管理用户列表的权限，这是信息系统最基本的安全边界。如果谁的账号登录进去都能改数据，那这个系统就没有实际部署价值，只能说是“玩具”。

从数据库角度说，方剂和药材是多对多关系：一个方剂包含多种药材，一种药材可能出现在多个方剂中。这种关系在关系型数据库里必须拆成三张表——方剂表、药材表、配伍中间表（即方剂药材关系表）。中间表里除了方剂ID和药材ID，通常还会冗余一个“用量”字段，比如“麻黄9g”，这个字段是组方知识的核心，不能只放在药材表里。这种设计的必然性，我后面在数据库章节里会展开讲。

所以这个系统的本质，是一个面向中医领域知识管理场景的垂直CRUD系统，它的业务复杂度源于领域规则而非技术复杂度，这对毕设来说是一个“跳一跳够得着”的理想难度。

2. 业务模型与数据库设计拆解

2.1 用户角色与权限控制的边界划分

先想明白一件事：系统里有哪些角色，每个角色能干什么，这个答案决定了数据库表的设计，也会直接影响到拦截器、菜单显示这些功能的实现方式。

在基础版中医方剂管理系统里，角色模型通常是三层的：管理员（admin）、医师/编辑（doctor）、访客/学生（user）。管理员管人、管配置、管日志；医师管方剂和药材数据；访客只能看。有的项目会把“审核”逻辑也加进来，方剂要被发布后才能被所有人看到，这个逻辑本身不难，但会引入“状态字段”的概念，属于锦上添花的功能扩展，不建议初版就做。

关于权限控制，毕设项目里最常见的两种实现方式：

• 粗粒度：登录后通过Session存当前用户，菜单根据角色动态渲染，Controller方法里加拦截器做登录校验，操作权限直接判断角色字符串。
• 细粒度：引入Shiro或Spring Security，用注解@RequiresPermissions控制接口权限，数据库增加权限表，但这种方案配置复杂，对SSM毕设来说属于杀鸡用牛刀。

我在实际带项目时更倾向于推荐前者，因为它的核心逻辑非常简单且容易在答辩时讲清楚：登录成功后，把user对象放入Session，自定义一个拦截器HandlerInterceptor，判断用户是否已经登录，未登录则跳转回登录页。菜单权限则用一个后台传递的roleType字段控制页面显示或隐藏。这样做的好处不止是简单，更在于你能说出“我的权限控制是三层结构，拦截器控制功能边界，角色字段控制界面元素”，比“我用了某框架”更能体现你理解权限的本质。

当然，有一个细节必须提醒：菜单隐藏不等于安全。即使界面上把“删除方剂”按钮隐藏了，如果用户直接输入URL访问删除接口，后端依然会执行。所以后端Controller方法里必须做二次校验，比如在方法内判断session.getAttribute("user")的角色类型是否为管理员，否则抛异常或返回错误页。这一点在答辩时经常被评委追问，提前做准备能加分不少。

2.2 核心表结构设计与字段含义

数据库设计是本项目真正拉开分差的地方，也是我要重点讲的部分。以一个实际跑通过的项目为参照，核心表一般有这么几张：

• 系统用户表（sys_user）
• 方剂信息表（prescription）
• 中药材表（herb）
• 方剂药材关系表（prescription_herb）
• 方剂分类表（category）
• 系统操作日志表（operation_log）

下面逐一说明每个表的字段设计以及为什么这么设计。

sys_user表存储用户信息，字段至少包含：主键ID、用户名、密码、真实姓名、角色类型（区分管理员/医师/用户）、状态（是否启用）、创建时间。密码字段我建议存储MD5加盐后的密文，而不是明文，密码是用户最敏感的信息，明文存储一旦数据库泄露就是事故。加盐的思路是在明文密码后拼接一个固定或随机的字符串再执行MD5，这样相同密码产生的摘要不同，安全等级上一个台阶。答辩时提到这一点，会显得你具备基本的安全素养。

prescription表是系统的业务核心，字段设计如下：

注意我把functions和indications拆成两个字段，而不是合并成一个“描述”字段。为什么要拆？因为功效和主治是两个不同的检索维度，用户可能只记得方剂主治“风寒感冒”，但完全忘了是哪个方，如果能按indications字段查询，系统就真正提供了业务价值。如果合并成一个字段，查询时就必须用LIKE '%keyword%'，对功效和对主治的效果一样模糊，而且语义也混乱。字段的粒度决定了查询的精度。

herb表存储药材常识数据，字段设计类似：id、药材名称、别名、性味归经、功效、用法用量、注意事项等。这张表更偏向基础字典，数据量通常不会特别大，几百条到几千条。需要说明的是，药材的最小单位不是“克”而是“药味本身”，这种设计符合中医组方的思维习惯，后面中间表跟它关联时才不会别扭。

prescription_herb表是关系型数据库多对多设计的灵魂。字段至少包含：id、prescription_id、herb_id、dosage、unit（如g）。dosage既可能是数值（9），也可能是文本（3~9），实际项目里我见过用varchar直接存的，虽然规范性差一些，但胜在灵活。这里要重点提一个问题：为什么中间表需要独立的id主键？原因是多对多关系中，同一张中间表可能出现多条记录——同一方剂包含同一药物的不同炮制品类，或同一组合在不同方剂中有不同的剂量含义。中间表有了自增id，删除单条关系时定位才精确。如果觉得设计得不够优雅，也可以不用独立id而是用(prescription_id, herb_id)作联合主键，但在“同一方剂重复录入同一味药”的业务例外场景下会出问题。我的建议是保留独立ID，简单可靠。

2.3 关系映射的取舍与索引设计

说完表结构，再讲讲表和表之间怎么关联。这是很多同学在写MyBatis时容易卡住的地方。

方剂表和分类表是“多对一”关系，一个方剂属于一个分类，一个分类下可以有多个方剂。方剂表和药材表是“多对多”关系，通过中间表连接。对应的MyBatis映射方式一般有两种：用<association>处理多对一，用<collection>处理一对多或多对多。查询方剂列表时，使用resultMap把分类名称映射出来，这样列表页直接显示“解表剂”“清热剂”这样的中文名称，而不是只显示一个category_id。

这里有一个很容易踩的坑：MyBatis的<collection>在查询一对多或多对多数据时，如果主表的字段和子表查出来的数据量比较大，会产生“N+1查询”问题。什么意思呢？就是查1条方剂主记录后，再额外执行若干次子查询。数据量少的时候感觉不明显，一旦方剂数据涨到上千条，页面的响应速度会迅速劣化。解决方案主要有两种：一是用嵌套查询的resultMap时开启懒加载（fetchType="lazy"），二是提前用联表查询一次性查出数据，再用resultMap做自动映射。在方剂列表页推荐的方案是联表查询，因为列表页本来就要一次性显示所有关联药材，没有懒加载的意义。

索引设计方面，至少要给这三类字段建立索引：逻辑外键字段，如prescription表的category_id、prescription_herb表的prescription_id和herb_id；常用于查询条件的业务字段，如prescription表的name和indications；时间字段，如果日志查询需要按时间倒序，create_time也可以加索引。索引不是越多越好，每加一个索引就意味着每次插入数据时多一次写入维护成本，但上面说的三类索引在本系统的查询场景里收益最明显，属于性价比最高的选择。

3. 核心功能模块与实现细节剖析

3.1 登录流程与拦截器的正确写法

登录模块是所有业务系统入口，做得是否专业，直接影响答辩观感。一套完整的登录流程包含四个环节：验证码生成与校验、登录请求处理、Session建立、拦截器注册。

验证码的功能是防止恶意脚本暴力破解密码。SSM项目中常用Google的Kaptcha组件，它可以在后端生成一张带干扰噪点的图片，把校验码文本存入Session。前端提交表单时，除了用户名密码还要带上验证码。Controller里先比对验证码，再比对用户名密码。这里有个非常常见的错误：有些同学登录成功之后忘了从Session里移除验证码属性，导致同一次会话中验证码永远不刷新，暴力破解器可以直接跳过验证码。建议在用户重新访问登录页时调用Kaptcha的输出方法覆盖Session值，而登录成功后不保留该属性。

登录接口的业务代码其实很简单，核心就三段：根据用户名查用户；校验密码摘要是否一致；把用户对象放到Session中。但有三点细节值得注意。

第一，查询用户时要用selectOne而不是selectList再取第一条，保证逻辑上用户唯一性，避免重名账号导致登录错乱。第二，密码校验要用摘要比对，不能把数据库中的密文解密再确认，因为MD5本质上是不可逆的。第三，用户对象的密码字段在放Session之前要置为null，防止前端页面上不小心把密码输出到内存或日志中。

拦截器注册是SSM中最容易写错的地方。SpringMVC中自定义一个HandlerInterceptor，重写preHandle方法，里面从当前请求的Session中获取用户，如果为null则跳转到登录页并返回false，否则放行返回true。但要注意，登录接口、验证码接口、静态资源路径（CSS、JS、图片）必须从拦截器中排除，否则用户还没登录就连登录页样式都加载不出来，甚至会出现登录页重定向的死循环。配置方式可以放在SpringMVC的配置文件中，通过<mvc:interceptors>标签指定。

提示：put拦截器配置为用户未登录则跳转到login页面，但AJAX请求要单独处理。登录时通过AJAX提交表单，后端如果直接返回重定向，前端拿到的其实是302响应而非JSON，解析会失败。建议的姿势是：后端统一返回JSON格式的登录结果，前端根据返回状态决定跳转还是提示错误。

3.2 方剂管理模块的分页与条件查询

方剂列表页是整个系统的门面，也是性能要求相对较高的模块。常用的交互方案是在页面上方放一个搜索面板，包含方剂名称、分类、主治病症几个输入框，下方用表格展示查询结果。表格选用layui或Bootstrap Table都行，但更纯粹的SSM方案是服务端分页配合前端传到后端的pageNum和pageSize参数。

分页插件方面，PageHelper是MyBatis生态里最流行的物理分页插件，用法很简单，直接在查询前调用PageHelper.startPage(pageNum, pageSize)，然后执行正常的Mapper查询，插件会自动在生成的SQL后面追加LIMIT ? OFFSET ?。但有两个使用细节，我在指导项目时常强调：第一，startPage后面紧跟的必须是一条SQL查询语句，不能在中间插入其它操作，因为PageHelper基于ThreadLocal实现，一旦线程被复用且上一个页对象没有被清理，会污染下一次查询。第二，查询方剂列表时的count查询是自动生成的，如果SQL逻辑复杂（比如有多个left join），建议手动用@SelectProvider或<select id="count">提供更高效的计数SQL，否则统计可能会比数据查询本身还慢。

条件查询的动态SQL，核心写法如下：

<select id="queryPrescriptionList" resultMap="PrescriptionResultMap"> SELECT p.*, c.name AS categoryName FROM prescription p LEFT JOIN category c ON p.category_id = c.id <where> <if test="name != null and name != ''"> AND p.name LIKE CONCAT('%', #{name}, '%') </if> <if test="categoryId != null"> AND p.category_id = #{categoryId} </if> <if test="indications != null and indications != ''"> AND p.indications LIKE CONCAT('%', #{indications}, '%') </if> </where> ORDER BY p.create_time DESC </select>

这种写法的核心价值在于省去了在Java代码里拼接SQL的烦恼，MyBatis自动帮我们组装WHERE 1=1（其实是<where>标签自动处理了前缀AND）。有两点需要注意：LIKE查询建议使用CONCAT拼接百分号而不是直接写LIKE '%${name}%'，因为后者是字符串拼接而不是参数绑定，会产生SQL注入风险；分类ID如果要支持“全部”选项，页面上传空值而不是传0，否则SQL会把category_id = 0当作查询条件，一条数据都查不出来。

3.3 方剂药材配伍维护的交互与存储

这个模块是中医领域特色的集中体现，也是本系统业务上最有讲头的功能。方剂的信息结构是“主表+明细表”的典型模式：主表存方剂基本信息，子表存组方药材明细。前端交互上，页面设计通常分为左右两栏或上下区块，左侧是一个药材选择区（复选或搜索添加），右侧是已选药材列表，每行可以编辑“用量”和“单位”，支持删除已选药材，最后统一保存。

这个交互在前端调后端时的数据格式设计，是很多同学写接口时纠结的地方。经验做法是定义这样的JSON提交结构：

{ "name": "麻黄汤", "categoryId": 3, "source": "伤寒论", "functions": "发汗解表，宣肺平喘", "indications": "外感风寒表实证", "usageMethod": "水煎服", "herbs": [ { "herbId": 1, "dosage": "9", "unit": "g" }, { "herbId": 7, "dosage": "6", "unit": "g" } ] }

后端Controller接收时可以用一个自定义的DTO对象，里面用List<PrescriptionHerbDTO>接收明细数据。保存事务是核心：主表INSERT，获取自增ID，然后循环明细，每条明细的prescription_id都绑定刚生成的主表ID，再INSERT到中间表。这个操作必须放在同一个事务里，否则一旦中间某条明细插入失败，主表记录已经写入，但系统没有任何报错提醒，用户以为保存成功了，实际上数据是残缺的，这就是事务存在的意义。

对应修改方剂场景，处理方式建议“先删后插”：先执行DELETE FROM prescription_herb WHERE prescription_id = ?，再执行上面的保存流程。不要尝试逐条比对差异再更新，因为后端的逻辑复杂度会急剧上升，而且容易遗漏“用户删除了某条明细后又重新添加”的情况。“先删后插”在数据量不大的场景下性能和安全性都是完全可以接受的。

3.4 检索体验与关键词查询优化

系统最常被使用的功能就是搜索。用户搜索的方式五花八门，可能是输入方剂名称，可能是输入病症关键词，也可能是输入一味药材名想找包含它的方剂。这三种检索目标对应的SQL逻辑完全不同：

• 按名称查询：p.name LIKE CONCAT('%', #{keyword}, '%')
• 按主治查询：p.indications LIKE CONCAT('%', #{keyword}, '%')
• 按包含药材查询：需要JOIN到prescription_herb表和herb表，本质是“存在性查询”

第三种查询在MyBatis中写起来最容易犯的错误是直接JOIN查列表导致数据膨胀，因为一个方剂包含多种药材，JOIN之后主表记录会被复制成多行，而后台又需要去重。推荐写法是用IN加子查询，例如：

SELECT DISTINCT p.* FROM prescription p WHERE p.id IN ( SELECT ph.prescription_id FROM prescription_herb ph JOIN herb h ON ph.herb_id = h.id WHERE h.name LIKE CONCAT('%', #{keyword}, '%') )

这种写法的可读性和执行计划都要优于大范围JOIN。如果系统数据量进一步增加，也可以把关键词检索迁移到全文索引或加入拼音首字母索引字段，但对毕设规模来说，LIKE匹配配合合理索引已经够用。

搜索框还有一个体验细节：用户输入关键字后点击搜索，前端应该把这个关键词回填到搜索框中，并支持按回车键直接触发搜索。看起来是小功能，但演示时如果每次搜索都要重新输入一遍关键词，体验会显得很不专业。这些细节点在答辩演示时是区分“用心做了”和“应付了事”的直接证据。

4. 实操：从源码到本地跑通

4.1 环境版本搭配清单

拿到源码的第一件事，就是核对环境版本是否兼容。我基于实际经验整理一份推荐的版本组合：

提醒一个非常实际的问题：如果你本机已经装了MySQL 8.0，也不用卸载重装，直接在连接URL后面加allowPublicKeyRetrieval=true&useSSL=false即可规避大部分认证问题，但建议优先按照项目README里要求的版本去匹配，因为在毕设答辩时，环境越接近项目作者的环境，越不容易出现莫名其妙的报错。

4.2 Maven项目导入的细节

大多数SSM毕设源码的目录结构是标准的Maven Web项目：src/main/java、src/main/resources、src/main/webapp。导入IDEA时选择Import Project，然后选Maven模型导入，等依赖下载完成后再配置Tomcat。

这里最容易卡住的是依赖下载缓慢。解决方案是在Maven的settings.xml中配置阿里云镜像：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

配置完镜像后，如果项目依旧报缺少某些jar包，多半是本地仓库存在损坏的下载记录，删除C:\Users\你的用户名\.m2\repository中对应的目录并重新刷新Maven即可。

项目依赖全部解析完后，先执行一次clean package -DskipTests，确认能打出war包。这一步能提前暴露代码编译层面的错误。常见的编译错误有这么几类：缺少lombok注解处理器、JDK语言级别不匹配、泛型类型不匹配。IDEA中可以把Project Structure里的Project SDK和Language Level都设成1.8，通常能解决绝大多数编译问题。

4.3 数据库初始化与配置文件修改

数据库初始化是最容易出问题的环节，因为它不只是执行一个SQL脚本那么简单。建议按以下顺序操作：

1. 新建数据库，字符集选择utf8mb4，排序规则选择utf8mb4_general_ci。
2. 用Navicat或命令行执行项目附带的xxxx.sql脚本。
3. 脚本执行成功后，重点检查：用户表里是否已有管理员账号；方剂表和药材表是否已有演示数据；各表主键是否连续。

如果是导入别人的SQL脚本，常会遇到“Table already exists”或“Unknown database”的报错，前者是因为脚本里包含建库语句而你已经手动建了，后者是因为脚本第一行的USE dbname指向了一个不存在的库名。最简单的做法是把脚本里的CREATE DATABASE和USE dbname手动注释掉，只保留建表和INSERT语句。

配置文件一般是src/main/resources/jdbc.properties，核心内容是数据库连接四要素：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/prescription_db?useUnicode=true&characterEncoding=utf-8&useSSL=false jdbc.username=root jdbc.password=你的密码

关于连接串，characterEncoding=utf-8和useSSL=false这两个参数非常关键：前者保证中文不乱码，后者保证MySQL5.7在连接时不会因SSL握手失败报“Communications link failure”。如果数据库密码包含特殊字符（比如@、#），记得用{、}包裹或直接做转义，否则Spring读取properties文件时会解析错误。

4.4 启动与部署的完整流程

启动流程本身不复杂，但在IDEA中需要做两个前置配置：一是把项目编译输出目录设为target/classes（Maven的默认输出目录），二是添加Tomcat Server并部署项目的war exploded包。

具体操作路径：Run菜单 -> Edit Configurations -> 新增Tomcat Server -> Local -> 设置Tomcat安装目录 -> Deployment标签页添加Artifact -> 选择项目名称:war exploded -> Application Context设置为/。

一个值得注意的细节是Application Context建议设置为/，而不是/项目名_war_exploded。因为SpringMVC的URL映射通常是从根路径开始的，如果访问路径变成localhost:8080/项目名/login，会导致页面上的JS、CSS资源引用路径全部错乱，还容易出现DispatcherServlet映射不到Controller的404问题。

启动时观察Log输出，看到类似“INFO: Server startup in 12345 milliseconds”就表示成功。接着访问http://localhost:8080/，如果配置正确，会跳转到登录页。首次登录建议使用脚本里预设的管理员账号，进去后先在“系统用户管理”里创建一个自己的账号，不要在原管理员账号上直接改密码，以免忘记原始密码时无法找回。

4.5 前端页面资源的适配问题

SSM项目的页面大多数是JSP，它和Vue、React这类前后端分离项目不一样，JSP在运行时会被Tomcat解析并编译成Servlet，所以页面文件必须放在webapp目录下。如果你在源码中发现JSP文件都集中在webapp/WEB-INF/views/下，这是MVC中比较规范的放法——WEB-INF下的页面不能通过URL直接访问，必须通过Controller转发进入，从安全角度说是合理的。

前端资源路径的坑多集中在少写${pageContext.request.contextPath}。在静态资源引用里，推荐统一写成<c:url value="/static/js/main.js"/>或直接加EL表达式前缀，否则当你在Tomcat里以非根路径部署项目时，所有JS和CSS都会变成404，页面功能完全不正常但浏览器控制台报错又被很多人忽略。这个问题在答辩排错时出现过无数次，先检查静态资源引用的路径，能省大量时间。

5. 常见问题排查与优化笔记

5.1 启动与运行报错速查表

从实际带毕设项目接触到的排查问题中，我整理了一张高频问题速查表，直接对照处理即可：

5.2 数据导出与报表统计的实现思路

很多毕设会额外要求“打印方剂信息”或“导出Excel”。说实话，这个功能在代码层面没有想象中复杂，关键在于选对实现库。Java后端导出Excel的经典方案是Apache POI，用它创建一个Workbook，填充表头和数据行，最后通过HttpServletResponse把文件流写回前端。这里有一个对新手非常友好的替代方案：前端直接用Bootstrap Table或layui表格的导出功能，表格当前页数据直接被插件转成Excel或CSV下载，后端一行都不用改。

如果需求是“导出全部符合条件的数据”而不是“当前页数据”，那还是要走后端方案。后端导出时注意两点：一是大数据量下要分批查询，避免一次性加载上万条方剂导致内存溢出；二是文件名要做URL编码处理，否则下载时中文文件名在不同浏览器中会出现乱码或“filename*=UTF-8''”的兼容性问题。

对于一个管理类的信息展示页面来说，数据报表和可视化不是必需功能，但加了会非常加分。简单的方式是从方剂表中按分类统计数量，用ECharts画一个饼图或柱状图，展示系统维护了多少方剂、分布在哪些分类下。这个功能前后端只花两个小时就能做完，但答辩演示时会产生非常直观的“系统完整度”提升。

5.3 慢查询与多表关联联调优化

运行一段时间后，如果数据量变大，其中一个常见痛点就是：方剂列表页第一次打开要转圈好几秒。出现这种情况，首先要定位是SQL慢还是页面渲染慢。

定位SQL的方法是在MySQL中开启慢查询日志，或者直接在数据库客户端里EXPLAIN一下核心SQL的执行计划。对方剂列表来说，最容易出现的优化点有两个：一是LIKE%keyword%无法走索引，这在数据量过万时尤其明显，可以退而求其次只对前缀查询使用索引；二是前面提到的N+1查询问题，如果详情的<collection>没有预设fetchType="lazy"，在循环中遍历方剂列表去查询每一条的药材明细，几十条主记录就会触发几十次额外SQL，页面必然卡顿。解决办法是强制优先查询列表数据时不管药材明细，点开“详情”时再单独查询这一个方剂的完整配伍。

页面渲染慢的另一半原因往往不是因为SQL，而是因为JSP页面引入了太多未压缩的JS和CSS库。像layui的全量JS有几百KB，如果在登录页和列表页都加载一次，本地开发感觉不明显，但部署到远程服务器后网络延迟一上来就会非常卡。优化策略是页面按需引入模块，不要无脑全量加载，登录页只放核心模块，后台管理页才加载表格、表单模块。

5.4 画像外的问题：数据库备份与恢复的最小方案

很多学生的毕设SQL脚本是指导老师要求“保留原始数据”才存在的，真正代码写完之后，数据库维护工作就没人关心了。但答辩前有一个特别实际的风险：数据库文件损坏、误删表记录、或者你换了电脑演示时发现数据全没了。这种场景在每年毕业季都真实发生。

最轻量的备份方案是用mysqldump命令行：

mysqldump -u root -p prescription_db > backup.sql

恢复也非常直接：

mysql -u root -p prescription_db < backup.sql

建议至少做到两点：一是把备份文件放在非项目目录之外的另一个磁盘位置，至少有一个异地副本；二是提交毕设材料前生成一次最终的SQL脚本，并确认从空库恢复后系统用户名、密码仍然能正常登录。这一步没人看见，却能救你一命。

6. 从毕设到答辩的延伸建议

6.1 二次开发的功能扩展方向

源码跑通后的下一步，就是琢磨要“改”点什么，让这个项目看起来像是自己“重新设计”的。改的幅度不必太大，但一定要能说得清“原项目是什么、我改了什么、为什么改”。

比较推荐且难度适中的扩展方向有三个：

第一个是增加“方剂对比”功能。在方剂列表每行加一个复选框，选中两个或三个方剂后点击对比按钮，新页面用表格或左右布局展示这几个方剂的功效、主治、组成药材对比。这个功能涉及前端复选框状态管理、后端按ID批量查询、页面动态渲染三部分，但每部分技术难度都不高。它的亮点是直接利用了中医学里“方剂比较”的学习方法，业务契合度很高。

第二个是增加“常用方剂收藏夹”。登录用户可以收藏自己关注的方剂，在个人中心查看收藏列表。核心就是加一张收藏关系表，用户ID加方剂ID组合唯一，前端用一个小红心图标表示状态。这个功能能让系统从“单向查询工具”升级为“用户个性化工具”，业务完整度明显提升。

第三个是增加“方剂数据统计面板”。从方剂表、药材表、分类表中提取统计指标：各分类下的方剂数量、药材使用频次排行Top10、用户新增方剂趋势等，用ECharts输出可视化图标。这类功能所需的后端SQL说简单不简单、说难也不难，但对于评委来说，一个系统“有统计看板”和“只有增删改查”的观感差异是巨大的。

6.2 答辩演示的效果优化技巧

答辩演示时要记住一个原则：展示的是系统能做什么，而不是系统怎么做。演示前提前准备好一组连贯的操作路径，比如：

1. 用管理员账号登录，展示系统权限菜单和基础配置。
2. 新增一个方剂，完整演示选择药材、填用量、保存的流程。
3. 修改一个已有方剂，改一味药的用量，重新保存。
4. 按“主治”关键词搜索，展示命中结果。
5. 进入统计面板，展示可视化图表。

每一步操作之间要留有半秒到一秒的间隔，让页面反馈被看清楚。最忌讳的演示方式是疯狂点击按钮，浏览器尚未加载完成就切到下一页，评委根本看不清你做了什么，反而会觉得系统响应慢。

在讲技术方案时，我建议按照“为什么这么设计 -> 关键代码位置 -> 效果验证”三步法来讲。例如讲到事务时，可以说：方剂保存涉及主表和明细表两条INSERT操作，为了避免中途失败留下半截数据，业务层的保存方法上加了@Transactional注解，把整个保存流程包成事务，并指出你的Service实现类中这个方法和对应SQL的位置。

6.3 自我评估：什么情况下这个项目还能再进一步

把基线功能做完，如果你还有时间，有几项工程化改良值得做。这些改良通常不会在答辩时被直接看到，但它们能体现你在工程实践方面的成熟度。

• 给所有对外接口补充统一的返回格式，不再是ModelAndView混用JSON，所有AJAX接口统一返回{code, message, data}结构，前端按code值的约定处理成功和失败。这会让后续的前后端联调舒适很多。
• 给Controller补充参数校验，使用@Valid加上@NotNull、@Length等注解，避免系统对空参数做出不可预期的响应。即使不能立刻引入完整的校验框架，至少对关键参数做手动非空判断，并返回友好提示。
• 把日志输出从System.out.println改为log4j2或Logback，并配置按天滚动。去掉所有println打印，日志区分级别记录到文件，长期运行后排查问题时会明显感谢当初的这个决定。

这些都不是“必需”项，但如果有余力，尽量做。因为毕设交上去代表的是你三年或四年的学习结果，它不只是跑通代码那么简单，更是你工程思维的一次成体系呈现。

6.4 关于源码使用的最后一个建议

最后聊一个很多同学纠结的问题：拿到一份源码，完全不会改，只会照着跑通，答辩时说不出任何设计理由，这样能过吗？

能过，但很悬。评委会问的问题并不深，往往就是“Password为什么要加密存”“这个事务加在哪个方法上”“这个列表的分页怎么实现的”这一类基础题。如果源码是你自己一路调试跑通的，这些问题即使不能回答得很深入，也至少能说出大概的调用链路；但如果连Mapper接口和XML的关系都讲不清楚，那基本上是送人头。

所以我个人非常建议，拿到源码之后不要急着改业务功能，第一遍先把所有代码从上到下读一遍，搞清楚每个包的职责，画出请求从浏览器到Controller再到Service再到Mapper的调用链路，顺带把数据库的每张表结构弄清。这一步做完后，你会发现所谓的“修改源码”其实就是在链路上插入自己的代码块，思路完全清晰了。

结尾：实操之后的一点体会

做完一个SSM中医方剂管理系统，我自己最大的体会是：这类项目真正难的从来不是某个技术点，而是把“中医领域知识”翻译成“数据结构与交互流程”的能力。方剂包含多种药材，每种药材有剂量和单位，医生输入方剂时要能方便地挑选药材——这些业务需求在你动手建表之前就必须想清楚，否则代码写一半重新改表结构，代价远比想象中大。

另外一个经验是，所有CRUD系统到最后拼的都是细节：列表页是否支持回车搜索、搜索条件是否回显、删除前是否有二次确认、文字溢出时是否截断显示、页面刷新后是否保留当前筛选状态。这些不起眼的小细节累积起来，决定了系统演示时给人的整体专业感。

如果你也是基于这份源码在做毕业设计，先从跑通开始，再逐层读懂，最后选择一个小功能去做改造和扩展。别急着推翻重来，也别完全照抄，把源码当作一个高质量起点，在上面长出属于你自己的部分，这比从零手写一个所谓“完全原创”的系统要可靠得多。