企业官网建设流程全解析

我记得第一次看到“基于SSM的乡村健康咨询系统”这个题目时，第一反应是：这不就是一个典型的管理信息系统毕业设计吗？但随着需求越理越深，才发现乡村健康咨询的场景其实有它自己的一套逻辑：用户是村民和基层医生，健康档案要能跨村共享，咨询记录要留痕，预约/随访状态要能流转。这些事情用Servlet裸写能行，但会写成噩梦；直接用Spring Boot又显得没“技术深度”，毕竟论文答辩时老师盯着的是你对SSM三条主线（Spring容器、SpringMVC请求分发、MyBatis持久化）的理解是否扎实。

所以这篇就围绕“Java + SSM 乡村健康咨询系统”从选题拆解、架构设计、核心实现到论文撰写踩坑，完整复盘一遍。无论你是正在做这个毕设题目，还是想拿一个“偏业务、但又不缺技术点”的Java Web项目练手，这篇文章的很多细节都能直接抄作业。

1. 项目整体设计与方案选型

1.1 为什么是SSM而不是Spring Boot

这几年Spring Boot已经把SSM“挤压”得只剩教学意义了，但毕设不一样：SSM能清晰展示三层架构和手动装配的过程，这恰恰是答辩时最容易被提问的地方。用Spring Boot一键起步，很多内容被自动配置吞掉了，老师问“Spring怎么管理Mapper的？”你可能半天答不上来。SSM则是自己写applicationContext.xml、spring-mvc.xml、mybatis-config.xml，每一根线头都摸过，论文里“系统实现”章节自然有东西可写。

但要注意，SSM不意味着什么都手动配。我的做法是：核心框架保持SSM，但引入了Maven管理依赖、MyBatis Generator生成基础CRUD代码、Bootstrap + jQuery做前端，让项目既有“手工感”又有“工程感”。答辩时老师问“用了什么前端库”也能说出个所以然。

1.2 系统角色与功能模块拆解

乡村健康咨询系统的核心用户有三类：

这里有一个设计细节容易被忽略：乡村健康咨询不是“全科医生在线问诊”那种大平台，而是“签约家庭医生”模式。所以数据库里必须有一张sign_contract（签约关系表），村民只能咨询/预约自己签约的医生，医生只能看到自己管辖范围内的村民档案。这个设计比“所有医生回答所有患者问题”更贴近真实场景，论文里写“系统解决了乡村医疗资源下沉和分级咨询问题”也更有底气。

1.3 功能设计的“边界感”——不要贪多

毕设最大的坑是功能爆炸。我在定方案时给自己划了三条线：

• 主业务线：注册登录 → 签约/分配医生 → 发起咨询 → 医生回复 → 村民评价。这条线必须闭环。
• 数据线：健康档案（基础信息、既往病史、过敏史、血压血糖等指标）→ 随访记录 → 咨询记录，形成一张“一人一档一历史”的表。
• 管理线：管理员对医生资质、公告、系统字典（疾病类型、科室）进行维护，不做复杂的权限粒度细分。

这样模块数量控制在8~10个左右，数据库表控制在12张以内，开发周期大约6~8周（含论文撰写）就能完成。如果硬加“在线支付”“视频问诊”，不仅开发量翻倍，答辩时容易被抓着问“支付安全怎么做”“视频流用什么方案”，答不好反而拉分。

2. 核心技术：SSM整合的关键配置与实现思路

2.1 配置文件分工——三条生命线

SSM整合最核心的是三件事：Spring管Bean、SpringMVC管请求、MyBatis管SQL。三者通过配置“拧”在一起，我的配置方案如下：

2.1.1applicationContext.xml——Spring容器主配置

<context:component-scan base-package="com.health"> <!-- 排除Controller，Controller交给SpringMVC容器扫描 --> <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> <!-- 读取数据库配置 --> <context:property-placeholder location="classpath:db.properties"/> <!-- 数据源：使用Druid连接池 --> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean> <!-- 配置SqlSessionFactory --> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="typeAliasesPackage" value="com.health.entity"/> <!-- 下划线转驼峰 --> <property name="configuration"> <bean class="org.apache.ibatis.session.Configuration"> <property name="mapUnderscoreToCamelCase" value="true"/> </bean> </property> </bean> <!-- Mapper接口扫描 --> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.health.dao"/> </bean> <!-- 事务管理器 --> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager"/>

这段配置里最容易出错的是mapperLocations路径写错或MapperScannerConfigurer扫不到接口。建议统一约定：Mapper接口放dao包，XML放resources/mapper目录，并用classpath:mapper/*.xml通配符，不要写具体文件名。

2.1.2spring-mvc.xml——请求分发层配置

核心两点：开启注解驱动、配置视图解析器。我给的是前后端轻度分离方案，页面用Thymeleaf成本略高，直接用JSP + JSTL更贴SSM教学惯例。

<mvc:annotation-driven> <mvc:message-converters> <bean class="org.springframework.http.converter.StringHttpMessageConverter"> <property name="supportedMediaTypes"> <list> <value>text/html;charset=UTF-8</value> <value>application/json;charset=UTF-8</value> </list> </property> </bean> </mvc:message-converters> </mvc:annotation-driven> <context:component-scan base-package="com.health.controller" use-default-filters="false"> <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/"/> <property name="suffix" value=".jsp"/> </bean> <mvc:resources location="/static/" mapping="/static/**"/>

这里要提醒一个高频坑：SpringMVC默认会覆盖容器扫描，如果use-default-filters不设置，service层也会被MVC容器加载一份，导致事务失效或代理冲突。我写的是use-default-filters="false"+ include filter，确保MVC只管理Controller。

2.1.3web.xml配置要点

<context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <!-- 乱码过滤器：必须放最前面 --> <filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param><param-name>encoding</param-name><param-value>UTF-8</param-value></init-param> <init-param><param-name>forceEncoding</param-name><param-value>true</param-value></init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <servlet> <servlet-name>dispatcher</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcher</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

url-pattern到底用/还是*.do？我做的是前者（REST风格更现代）。但要注意，用/会把静态资源也拦截进来，所以必须有<mvc:resources>配置。否则CSS、JS全404，页面裸奔，论文里截图会非常难看。

2.2 数据建模思路：围绕“健康档案+咨询”双主线

数据库是整个系统的地基，我按“人—档—互动”三个层次设计。

2.2.1 核心表清单

我特意把health_profile和user分表，而不是合并。原因有两个：一是档案字段（血压、血糖等）往往需要扩展，分表后加字段不影响登录认证逻辑；二是论文里可以写“用户基础信息与业务档案的垂直拆分，降低表的耦合度”，这是加分项。

2.2.2 状态字段枚举约定

咨询和预约都涉及状态流转，我在后端用常量类管理，不散写在业务代码里：

public class ConsultationStatus { public static final int UNREPLIED = 0; // 待回复 public static final int REPLIED = 1; // 已回复 public static final int CLOSED = 2; // 已关闭 }

这里的经验是：状态机设计比你想的更影响代码量。比如村民发起咨询时status=0，医生列表页显示“待回复”，点击回复后设置reply_content、reply_time、status=1。如果村民7天没收到回复，系统自动把咨询标记为“医生超时未回复”，并允许管理员介入重新分配医生——这个逻辑在论文“系统异常情况处理”里是很好的亮点，代码量却只增加了一个@Scheduled定时任务。

2.3 三层架构代码组织方式

包名建议统一用com.health（或其他项目前缀），我在项目里按controller/service/dao/entity/util分好了：

com.health ├── controller # Web层 │ ├── UserController.java │ ├── ConsultationController.java │ ├── HealthProfileController.java │ └── AdminController.java ├── service │ ├── UserService.java │ ├── ConsultationService.java │ └── impl（业务实现放这里） ├── dao │ ├── UserDao.java │ ├── ConsultationDao.java │ └── ... ├── entity │ ├── User.java │ ├── Consultation.java │ └── ... ├── util │ ├── MD5Util.java │ └── PageResult.java └── interceptor └── LoginInterceptor.java

这个结构被老师问过无数遍“为什么Controller不写SQL”——我的回答是：业务复杂时，Controller只负责参数接收和视图/JSON返回，具体逻辑下沉到Service，MyBatis XML里只写SQL，这样每一层职责单一，测试也好写。这其实也直接呼应了论文的“系统设计遵循分层架构模式”一小节。

3. 实操过程：从空项目到跑通核心功能

3.1 开发环境与版本组合

我的环境组合：

• JDK 1.8（务必是1.8，不要用17/21，SSM老项目对高版本JDK兼容性差）
• Maven 3.6.3
• Tomcat 9.0（Tomcat 10的包名改成了jakarta.*，SSM老项目会直接编译失败）
• MySQL 8.0（或5.7，二选一别纠结）
• IDEA 2023.1

具体依赖版本在pom.xml里锁住，避免莫名升级后出现问题：

<properties> <spring.version>5.3.9</spring.version> <mybatis.version>3.5.9</mybatis.version> <mybatis-spring.version>2.0.7</mybatis-spring.version> <druid.version>1.2.8</druid.version> </properties>

依赖里除Spring、MyBatis、Druid外，一定要配jstl和jackson-databind。前者管JSP页面轮回，后者管@ResponseBody返回JSON。漏配任何一个，页面都会出现诡异问题——JSP里${}不解析，Ajax请求handler直接报406。

3.2 数据库初始化与必填测试数据

建库时字符集统一用utf8mb4，排序规则utf8mb4_general_ci，这样村民填的“𠈌”之类生僻字不会变问号。初始化SQL里至少要预置：

• 1个管理员账号（admin/admin123）；
• 2个医生账号（密码用MD5加密存储）；
• 20个村民账号（方便演示分页效果）；
• 若干条健康档案和咨询记录（让首页统计不至于空荡荡）。

这里有个惨痛教训：我第一次做演示时，因为数据库里一条历史咨询也没有，答辩老师问了句“这个图表能跑出数据吗？”结果页面是空的，非常尴尬。所以init.sql里一定要造数据，而且造得越像真实越好，比如“张大爷 血压偏高 正在服用降压药”这种带叙事感的记录。

3.3 核心功能实现：注册登录与登录拦截

3.3.1 登录Controller

@Controller @RequestMapping("/user") public class UserController { @Autowired private UserService userService; @PostMapping("/login") public String login(String username, String password, HttpSession session, Model model) { String pwdMd5 = MD5Util.md5(password); User user = userService.login(username, pwdMd5); if (user == null) { model.addAttribute("error", "用户名或密码错误"); return "login"; } session.setAttribute("loginUser", user); // 根据角色跳转不同主页 if (user.getRole() == 2) { return "redirect:/doctor/index"; } else if (user.getRole() == 1) { return "redirect:/villager/index"; } return "redirect:/admin/index"; } }

3.3.2 登录拦截器

这里有一个很容易翻车的细节：只靠JSP页面里的Session判断做权限校验是不行的。比如村民直接输入/doctor/consultationList地址，后台就裸奔了。所以一定要在spring-mvc.xml里注册拦截器：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/user/loginPage"/> <mvc:exclude-mapping path="/user/login"/> <mvc:exclude-mapping path="/static/**"/> <mvc:interceptor class="com.health.interceptor.LoginInterceptor"> <property name="role" value="-1"/> </mvc:interceptor> </mvc:interceptor> ...（不同角色对应的非法访问可再细化） </mvc:interceptors>

拦截器内先判断Session里有没有用户，其次比对requiredRole与当前用户角色。登录后Session里存的是User对象，存的是整个对象，不存分散的userId和role字符串，这样取时不用再造DTO。

3.4 核心业务：咨询流程的Service实现

咨询是系统的“心脏”，别看它只是“村民发一条、医生回一条”，涉及的事务点可不少：

@Service public class ConsultationServiceImpl implements ConsultationService { @Override @Transactional(rollbackFor = Exception.class) public int publishConsultation(Consultation consultation) { // 1. 校验是否合法签约关系 SignContract contract = signContractDao.findActiveByVillager(consultation.getVillagerId()); if (contract == null) { throw new BusinessException("您尚未签约家庭医生，无法发起咨询"); } consultation.setDoctorId(contract.getDoctorId()); consultation.setStatus(ConsultationStatus.UNREPLIED); consultation.setCreateTime(new Date()); // 2. 插入咨询 consultationDao.insertSelective(consultation); // 3. 同时更新健康档案的最近交互时间（模拟健康干预，增强联动感） healthProfileDao.updateLastConsultTime(consultation.getVillagerId()); return 1; } }

画一下重点：

• @Transactional只写在Service实现类的方法上，不写Controller上；
• 抛出的是自定义异常BusinessException，并在全局异常处理器里转成model.addAttribute("error", e.getMessage())，页面友好提示；
• 更新“健康档案最近交互时间”这一步看似多余，但它是论文里“咨询与档案联动”的落地证明。

3.5 列表分页与搜索——必考送分题

分页是老生常谈，但很多同学栽在“手写分页”还是“用PageHelper”的取舍上。我的方案是统一引入PageHelper，理由很直接：代码量小，且能在论文里交代“使用PageHelper实现物理分页，避免一次性加载大量记录导致内存溢出”。

PageHelper.startPage(pageNum, pageSize); List<ConsultationVO> list = consultationDao.selectByCondition(villagerId, status, keyword); PageInfo<ConsultationVO> pageInfo = new PageInfo<>(list);

Controller里把PageInfo塞进Model，页面用JSTL循环渲染。搜索建议用<if>动态SQL，不拼接字符串，防SQL注入：

<select id="selectByCondition" resultMap="ConsultationResultMap"> select * from consultation <where> <if test="villagerId != null"> and villager_id = #{villagerId} </if> <if test="status != null and status != -1"> and status = #{status} </if> <if test="keyword != null and keyword != ''"> and content like concat('%', #{keyword}, '%') </if> </where> order by create_time desc </select>

注意：PageHelper的startPage必须紧跟查询语句，中间不能插入其他查询，否则分页参数会被“吃掉”。这是我调了一下午才发现的坑。

4. 常见问题与排查技巧实录

4.1 “页面报404，但Controller明明写了映射”

这个坑90%是因为SpringMVC的扫描没生效或者配置文件没加载。排查顺序：

1. 看Tomcat启动日志有没有报BeanCreationException，如果有，直接看原因；
2. 确认web.xml里DispatcherServlet的contextConfigLocation指向的是spring-mvc.xml而非applicationContext.xml；
3. 确认Controller类上有@Controller注解，且包名在扫描范围内；
4. 最后再用浏览器的Network面板看请求路径，有时是前端URL拼错或大小写问题。

提示：新老项目最容易在IDEA里出现“资源未同步”问题，target目录里的mvc.xml是旧的。执行mvn clean后重启Tomcat，能解决大半“我看配置没问题啊”的疑难杂症。

4.2 “注入的Mapper一直报空指针”

空指针基本等于Spring没有把Mapper代理对象装进Service。最常见的三种原因：

• MapperScannerConfigurer的basePackage写错，扫不到dao包；
• Service实现类忘了加@Service，于是没有任何Bean可注入；
• 用了两个component-scan互相覆盖，Controller和Service被容器重复加载产生代理混乱。

我在第一次整合时就是第二种低级的错：在applicationContext.xml里扫了service包，又在spring-mvc.xml里扫了全包，导致Service实例被创建了两份，@Transactional根本没生效。改成“容器只扫除Controller以外的类，MVC只扫Controller”后，一切正常。

4.3 “JSON返回406”或“Ajax拿到一串字符串”

@ResponseBody返回JSON时，前端一直报解析错误，往往是因为pom.xml里少了jackson-databind。如果没有它，SpringMVC只能用StringHttpMessageConverter返回字符串，前端拿到的是JSON格式的文本却不是JSON对象。把依赖加上、mvn clean重启即可。

另外，如果同时用StringHttpMessageConverter和MappingJackson2HttpMessageConverter，注意supportedMediaTypes不要一律设成text/html;charset=UTF-8，否则JSON请求也会被转成文本响应。建议把JSON MessageConverter放在前面，让它优先处理application/json请求。

4.4 “数据库中文乱码”

这是老生常谈的乱码三板斧：

1. 数据库连接URL加useUnicode=true&characterEncoding=utf8；
2. Druid连接池的driverClassName用com.mysql.cj.jdbc.Driver（MySQL 8）而不是旧版com.mysql.jdbc.Driver；
3. CharacterEncodingFilter放在所有Filter最前面，且设置forceEncoding=true。

如果这三步都做了还有个别页面乱码，多半是JSP头里的pageEncoding没写，或者<%@ page contentType="text/html;charset=UTF-8" %>漏了。逐个检查，必能解决。

4.5 “筛选状态后搜索条件丢失”

这是一个很常见的前端联调Bug。点击分页第2页时，URL变成/consultation/list?pageNum=2，但之前的status和keyword参数丢了。解决方法是在分页组件里显式拼接所有已有查询条件，或者用一个隐藏表单保存查询条件，翻页时一并提交。我后来采用最简单直观的方式：用JS修改分页链接：

function buildPageHref(pageNum) { var status = $('#statusFilter').val(); var keyword = $('#keywordInput').val(); window.location.href = "/consultation/list?pageNum=" + pageNum + "&status=" + status + "&keyword=" + encodeURIComponent(keyword); }

当然，如果你用PageHelper，后台可以拿到原始页面的查询参数拼接成PageInfo的prePage和nextPage，但前台的代码依旧要带上参数，否则后端再努力也没用。

4.6 “同一村民重复发起咨询，医生列表出现两笔”

这是因为村民在有未完结咨询时还能继续发。从业务上讲这不算Bug，但录屏演示时非常乱。我在Service里加了“同一签约医生下存在未回复咨询时，提示先等待医生回复或由管理员关闭旧咨询”的校验。这属于业务规则的补充，也是答辩时老师喜欢问的“你哪些地方考虑到了实际业务约束”的典型例子。

4.7 连表查询字段名冲突

consultation表、user表、doctor_info表里可能都有name字段，用select *连表查询时，MyBatis的Autowired映射会把后一个同名字段覆盖前一个。所以务必要在SQL里起别名，并且resultMap里显式映射：

<resultMap id="ConsultationVOMap" type="com.health.vo.ConsultationVO"> <result column="villagerName" property="villagerName"/> <result column="doctorName" property="doctorName"/> </resultMap>

别名要见名知意，别偷懒用a.name, b.name，否则一定踩坑。

5. 论文撰写的加分技巧与模块组织

5.1 “技术介绍”章节别写成API文档

论文的第二章通常叫“相关技术介绍”，很多同学喜欢把Spring、SpringMVC、MyBatis的官方介绍背一遍，老师一看就知道是复制的。我的做法是：每个技术写“是什么—解决什么问题—在系统中如何被使用”三段式。比如Spring不是简单介绍IoC/DI概念，而是写“本系统中的Service层对象均由Spring容器统一管理，依赖通过构造器或@Autowired注入，降低了各层之间的耦合。”这就让技术介绍和项目绑在了一起。

5.2 “系统设计”要画准图

论文里一般需要：用例图、功能结构图、E-R图、数据库表结构图、系统架构图。画图工具用ProcessOn或Draw.io，风格统一，不要一张彩色一张黑白。特别提醒：数据库表结构图不要贴SQL建表语句截图，要用PowerDesigner或手绘风格的表格一一对应字段、类型、约束，这样显得专业。

5.3 “系统测试”章节必须有数据

测试章节是凑字数的好地方，但不要只写“功能验证通过”。我建议做一张测试用例表，包含：测试编号、测试功能、测试步骤、预期结果、实际结果、判定（通过/不通过）。例如：

这种表又正式又能凑字数，而且答辩时老师问“你系统做过测试吗？”直接把表格甩出去，非常直观。

5.4 日志级别的选择

做这个项目时，记得给log4j（或log4j2）配好不同级别的输出。我实际开发中遇到一个“并发修改健康档案导致Session里old值覆盖new值”的问题，当时就是靠debug日志看到更新SQL的前置条件没生效才知道是脏检查问题，把update语句改成带版本的乐观锁才解决。这个经验结论也可以顺带写进论文的“系统优化与改进”里。

6. 结语：一点务实的经验

这个项目让我最有成就感的地方不是“跑了多少功能”，而是把SSM从“背面试八股”变成了真正能在手里运转的框架体系。你会在改配置的过程中真正理解DispatcherServlet的作用，会在排查空指针时真正搞懂@Autowired的注入时机，会在写分页SQL时真正明白数据库连接和性能调优的边界。这些知识，都是后续学Spring Boot、微服务时可以迁移的基础。

最后分享一个小技巧：做一个“数据预演脚本”，在开发时写一个demo.sql，里面包含一组完整的用户故事数据（比如“村民张三签约了医生李四，张三发了一条高血压咨询，李四回复了，管理员看到了这条记录”），然后用这套数据去测每一条业务流程，比随机造数据高效得多。答辩前的演示，也千万别用空库——那不是Demo，那是事故现场。

这个项目后续如果想加深，可以往“消息推送提醒村民查看医生回复”或“健康档案异常指标自动预警”两个方向扩展。一个增加WebSocket，一个增加规则引擎，都是好拓展点，但先把当前版本稳定下来，再考虑“添砖加瓦”。毕竟对毕设而言，能完整跑通、能自圆其说、能经得起追问，就是最大的成功。