企业官网建设流程全解析

1. 毕业设计选s2sh的真实理由：不是最时髦，但最稳

每年八九月份，总有几个毕业生拿着类似的选题来找我：基于s2sh的大学生创新创业管理系统，源码加LW文档，问我这个方向还能不能做。说实话，单纯从技术角度看，Struts2加Spring加Hibernate这套组合确实算不上新潮，Spring Boot都迭代到多少版了，很多人听到"SSH整合"第一反应是"怎么还在用这个"。但放在计算机毕业设计的语境里，这个结论恰恰要反过来看。

s2sh之所以在高校毕业设计里长盛不衰，原因很实在：第一，它是教科书级的三层架构范本，Struts2负责表现层和请求分发，Spring负责对象管理和事务，Hibernate负责持久化，每一层都有明确且独立的职责，很适合拿来向答辩老师展示"我懂分层"；第二，资料沉淀极其丰富，几乎每个报错都能在社区里找到答案，对第一次做完整项目的学生来说，这是实打实的保障；第三，管理信息系统本身就是s2sh的主场——表单提交、列表查询、状态流转、权限控制、简单统计，这些功能用SSH做起来思路非常顺畅，不像高并发、分布式那类场景，硬套这组合才是灾难。

那"大学生创新创业管理系统"这个业务方向又有什么说法？简单说，现在高校普遍有大学生创新创业训练计划，每年有大量项目需要走申报、评审、立项、中期检查、结题验收的流程。传统做法是发通知、收Word文档、Excel汇总、邮件反馈，数据一多就乱，评审批次、经费记录、成果统计全靠人工核对，效率低还容易漏。这套系统的目标就是把整条流程搬到线上：学生在网页上填报项目信息，指导老师在线确认，学院管理员先初审，评审专家在线打分和写意见，校级管理员最终立项，后续推进展报告、经费记录和结题材料，最后还能按学院、项目类型、年份做统计。

对准备拿它做毕业设计的人来说，这套业务最大的好处是"需求看得见摸得着"。你不会出现那种"需求文档写了几十页但完全不知道该建什么表"的情况，因为它的每一个模块都能对应到实际场景。也不用担心复杂度失控，核心就是围绕"项目"这个主对象做增删改查加状态流转，工作量适中，既能撑起论文篇幅，又不至于做到一半放弃。

这篇文章我就按我自己带这类项目的实际过程来讲，从业务建模、数据库设计、SSH整合、核心功能实现到LW文档写作，把关键思路和踩过的坑一次说清楚。

1.1 为什么是s2sh，而不是直接上Spring Boot

这个问题高频出现。我的回答是：如果纯粹为了"能用"，Spring Boot确实更省事，约定大于配置，内置容器，跑起来很快。但毕业设计考察的往往不是"你能不能快速起一个服务"，而是"你能不能讲清楚一个Web系统是怎么工作的"。s2sh强制你手动配置数据源、事务管理器、拦截器、ORM映射，这一套配下来，你对请求生命周期、容器管理和对象关系映射的理解，是Spring Boot那种"拿来即用"给不了的。

另外从实际答辩效果看，结构越清晰的东西越好讲。s2sh的Action、Service、Dao三层，每一层职责明确，老师问"你这个业务逻辑放在哪一层"你张口就来；如果逻辑全堆在Controller里，虽然也能做，但讲起来就容易显得工程意识不足。所以这个选题不是技术落后，而是"用合适的复杂度展示基本功"。

1.2 管理类系统最容易出彩的几个能力点

对于管理信息系统，答辩加分项一般集中在几个地方。一是权限设计，不同角色看到不同菜单、执行不同操作，这背后是拦截器和角色判断的配合；二是状态流转，一个项目从草稿到结题中间要经历多次状态变化，谁能改、什么时候能改，这是业务逻辑的核心；三是数据统计，如何从多张表里聚合出学院申报数、立项率、平均分这类指标。这三点恰好都是s2sh能很好承载的，也是后文我会重点展开的部分。

明白了"为什么做"和"做成什么"，下一步就必须把业务流程掰开揉碎，因为数据库设计和功能开发全部取决于你对业务的理解深度。

2. 业务模型拆解：画清流程再建表，后面能少改一半代码

我带过的毕设项目里，返工最严重的往往不是代码写错，而是业务规则没想清楚就开始建表。创新创业管理系统也不例外，看起来只有几个菜单，但角色、流程、状态之间的约束关系很容易被忽略。

2.1 五类参与者和三条核心流程

这套系统里至少有五类角色：学生（项目负责人）、指导老师、学院管理员、校级管理员、评审专家。如果你把"超级管理员"也单独列出来，就是六类。很多学生设计时只想到"管理员"一个角色，这是最大的误区，因为评审权限和项目管理权限根本不是一回事。

我把三条核心流程整理成下面这张表，建表和写代码前先对着它过一遍：

这三条流程看起来独立，实际共用同一个项目主记录，只是状态字段在变化。所以系统设计的关键不在于为每个流程建一堆表，而在于把"项目"这张主表的状态设计好。

2.2 项目状态机：用一张表管住全生命周期

我在设计阶段会先画状态转换表，这个比画E-R图更早。项目状态我一般分成这些：草稿、已提交、学院初审中、学院初审通过、学院初审退回、专家评审中、专家评审通过、专家评审退回、已立项、中期检查中、中期检查通过、延期、已结题、已终止。

这里要注意，"退回"不是终止，而是需要学生修改后重新提交，所以状态要有办法回到"已提交"；"已终止"则是不可逆的终态，一般是因违规或主动放弃。用数据库字段表达的话，我会在project表设计一个status字段，再配一个project_status_log表记录每一次状态变化的时间、操作人和备注。状态历史表非常推荐加，论文的时序图、功能测试表都靠它提供素材。

状态允许的迁移关系，在service层用一个switch判断或者一组常量来约束，不要在前端到处改，否则后面审查状态会乱套。

2.3 功能清单落到模块，论文目录也跟着出来

功能清单在做完流程拆解后应该自然浮现。我习惯用一张表把模块、角色权限、核心操作对应起来：

• 学生端：项目申报、成员管理、修改申请、上传附件、查看评审结果、中期报告提交、结题申请
• 指导老师端：确认或退回指导项目、查看项目进展、填写指导意见
• 学院管理员端：初审通过或退回、导出本学院项目列表、统计本学院数据
• 评审专家端：查看分配到的项目、在线打分、填写评审意见
• 校级管理员端：用户管理、项目分配评审、终审立项、经费管理、全院统计、系统公告

这套清单整理完之后，你会发现论文里的功能结构图、系统模块图、页面原型都可以直接照这个画，不用再临时凑内容。到这一步，业务流程已经清楚，接下来就是数据模型。

3. 数据库设计：核心表结构和几个容易踩坑的字段

数据库设计是这类毕设的重点也是难点。创新创业管理系统的表不会特别多，但表之间的关联、状态字段和评审数据的存法需要讲究一下。下面是我认为最核心的几张表，字段以能讲清楚业务为原则，不需要刻意堆列。

3.1 用户与角色：普通用户表和扩展信息表分开

用户表我建议不塞太多业务字段，登录名、密码、姓名、邮箱、手机号、状态就够，角色单独用user_role表关联。学生扩展信息（学号、班级、专业、年级）、老师扩展信息（工号、职称、研究方向）分别建表，用外键关联到user表的user_id。这样做的理由是：角色不同，字段差异大，硬塞在一张表里会出现大量空字段，写查询和论文时候都不好处理。

CREATE TABLE sys_user ( user_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50) NOT NULL, email VARCHAR(100), phone VARCHAR(20), status INT DEFAULT 1, create_time DATETIME ); CREATE TABLE student_info ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, student_no VARCHAR(20) NOT NULL, class_name VARCHAR(50), major VARCHAR(50), grade VARCHAR(20), FOREIGN KEY (user_id) REFERENCES sys_user(user_id) );

密码字段不要明文存储，哪怕是毕设，在论文里写"采用加密存储"也是一个加分点。另外，不要在主键上用无意义的自增ID当外键就算了，业务表里最好都带上create_time这类审计字段，后面查问题、写测试都方便。

3.2 项目主表：状态、类型、金额一个都不能少

project表是整个系统的中心，字段应该围绕申报书核心信息来设计：项目名称、项目类型（创新训练、创业训练、创业实践）、所属学院、指导老师、负责人、预算金额、项目简介、状态、申报时间等。有一类字段经常被忽略，就是"当前学期或批次"。创新创业计划每年按批次申报，有了批次字段才能做"本年度申报了几个""今年立项率多少"这类统计。

CREATE TABLE project ( project_id INT PRIMARY KEY AUTO_INCREMENT, project_name VARCHAR(200) NOT NULL, project_type VARCHAR(20), college VARCHAR(50), leader_user_id INT NOT NULL, teacher_user_id INT, budget DECIMAL(10,2), summary TEXT, status VARCHAR(20) DEFAULT 'DRAFT', apply_year VARCHAR(10), apply_time DATETIME, FOREIGN KEY (leader_user_id) REFERENCES sys_user(user_id), FOREIGN KEY (teacher_user_id) REFERENCES sys_user(user_id) );

项目成员单独建project_member表，一个项目对应多条成员记录，字段包括学生用户ID、姓名、学号、专业、分工。注意负责人也在成员里，但这个信息通过project表的leader_user_id表达，查询的时候需要处理去重。

3.3 评审表：分数和意见分离，汇总结果单独算

评审这块设计得好不好，直接影响专家端体验和答辩时的讲解效果。我建议评审打分表这样设计：每条记录对应该项目、该评审人、一个分数、一段意见、评审时间和结论（通过或不通过）。这样能保留每个专家的原始意见，后期如果有争议，可以回溯查证。

CREATE TABLE project_review ( review_id INT PRIMARY KEY AUTO_INCREMENT, project_id INT NOT NULL, reviewer_id INT NOT NULL, score DECIMAL(5,2), opinion TEXT, result VARCHAR(10), review_time DATETIME, FOREIGN KEY (project_id) REFERENCES project(project_id), FOREIGN KEY (reviewer_id) REFERENCES sys_user(user_id) );

至于"这个项目的平均分多少、是否立项"，我建议不存到评审表里，而是在汇总时动态计算，或者单独建一张project_review_result表，记录最终平均分、评审结论、立项金额。原因是：平均分是各位专家打分之和除以人数，属于派生数据，动态算更符合逻辑；如果非要冗余存储，记得在每次新增评审记录后更新，否则数据会不一致。

3.4 附件表和进度表：给中期和结题留好位置

申报书、中期报告、结题材料都以附件形式提交。我习惯建一张通用附件表，字段为附件ID、关联业务类型、关联业务ID、原文件名、存储路径、上传人、上传时间。这样申报、中期、结题可以共用一套上传接口，不用为每种材料各建一张文件表。

进展表和经费表属于锦上添花，但如果论文里写了"全生命周期管理"，这两张表就该有。progress表记录提交时间、阶段（中期或结题）、说明、附件ID；fund表记录支出项、金额、时间、经费用途。经费记录不必太过复杂，能说明余额变化即可。

到这里数据库已经能支撑全部功能了。接下来最让人头疼的就是把那三个框架整合起来，这一步是无数人卡壳的地方。

4. Struts2、Spring、Hibernate整合：配置和事务的坑都在这里

s2sh项目90%的启动失败都发生在整合阶段。这部分我必须强调一句：不要在没有任何思路的时候直接复制网上的配置，尤其注意版本配套。我用过比较稳的一套组合是Struts2 2.3.x系列加上Spring 4.x加上Hibernate 4.x，配合Maven管理依赖。版本一旦乱配，各种ClassNotFoundException会把人折磨到怀疑人生。

4.1 依赖和web.xml的基本骨架

用Maven的话，核心依赖大概包括struts2-core、struts2-spring-plugin、spring-context、spring-orm、hibernate-core、数据库驱动和连接池。注意Struts2一定要加struts2-spring-plugin，并且要让Struts2在Spring容器里创建Action，否则Action对象由Struts2自己托管，Spring的注解注入在Action里就失效了。

web.xml里需要配置三样东西：ContextLoaderListener（加载Spring容器）、Struts2的StrutsPrepareAndExecuteFilter、编码过滤器。顺序上监听器在前，过滤器在后。这里有个容易被忽略的点：如果你的项目里有前端静态资源（CSS、JS、图片），要确保Struts2过滤器把它们放行，不然页面样式全部丢失。解决方式是调整struts.xml的常量，或者在配置里指定排除路径，实际操作中很多模板里会直接配一个不做拦截的静态资源目录。

4.2 事务失效的三大原因

Spring声明式事务在s2sh里失效，是我见过频率最高的报错。原因通常有三个。第一，service类没有被Spring管理，这好查，加@Component或者@Service就能解决。第二，事务注解放在private方法上，Spring的代理机制对private方法不生效，注解一定要加在public方法上。第三，同一个service类内部一个方法调用另一个方法，比如save方法内部直接调this.updateStatus，这种情况下第二个方法的事务注解不会生效，因为调用发生在代理对象内部，绕过了Spring的事务拦截。解决办法是把跨方法的操作拆到不同service，或者通过注入自身的代理来完成。

还有一类问题类似但更隐蔽：事务配置了，但数据库表用的是MyISAM引擎，这种引擎不支持事务，回滚自然无效。建表时统一用InnoDB，在论文里也可以顺带提一句存储引擎的选择理由。

4.3 Hibernate懒加载和Action层面的序列化冲突

用Hibernate做一对多、多对一关联时，默认懒加载会带来一个经典异常：session关闭后再访问关联对象，抛出LazyInitializationException。常见发生位置是查询项目列表后，在JSP页面里读取project.getTeacher().getRealName()，此时session已经关闭，关联对象没有初始化。

解决办法有几种。简单粗暴的是用OpenSessionInViewFilter，让session在整个请求周期内保持打开，但Session在视图层还开着，等于把事务边界拉长了，对毕设项目没什么影响，但对理解事务边界有影响，答辩时容易被追问。我通常推荐在service层把需要用的关联数据都查好，用DTO或者Map返回给Action，JSP不直接触碰懒加载关联。这样代码更可控，论文里也好写"Service层负责组装视图所需数据"。

4.4 Struts2拦截器的权限控制写法

登录和权限控制用Struts2的拦截器非常自然。自定义一个AuthInterceptor，在拦截方法里从Session取当前登录用户，取不到就跳转到登录页。在struts.xml里配置一个带认证逻辑的拦截器栈，给需要权限的Action应用。注意登录Action本身、用户注册Action、以及静态资源必须在拦截器方法中放行，否则会出现"明明可以登录却一直跳回登录页"的诡异现象。

权限差异可以用更细的拦截器或者直接在Action方法里判断当前用户的角色类型。比如"申报"只允许学生角色，"评审打分"只允许评审专家。用注解或枚举常量管理角色值，不要用魔法字符串散落在代码里。

整合一旦跑通，项目就完成了一半以上。剩下的核心功能实现，只要按模块逐个填充就行。下面我挑三个最有代表性的功能讲具体的实现思路。

5. 核心功能实现：申报、评审、统计三个模块的思路

这部分我挑申报、评审、统计来展开，原因是它们恰好覆盖了表单处理、状态流转、聚合查询三类典型问题，做完这三个，剩下的模块基本都是同类操作。

5.1 学生申报：事务边界放在service方法上

申报功能的流程是：学生填写项目基本信息、添加成员、上传申报书附件、点提交。前端表单提交到Action后，Action只做参数接收和调用service，不写业务逻辑。service层的保存方法需要加事务注解，因为要同时写入project主记录、project_member成员表、attachment附件表三处数据，任何一个失败都应该整体回滚，避免出现"项目有了但成员丢了"的不一致状态。

文件上传在Struts2里用的是FileUpload拦截器，Action中声明三个字段：File uploadFile、String uploadFileFileName、String uploadFileContentType，在execute方法里就可以拿到上传文件。保存时注意文件名要重命名，避免不同用户上传了相同文件名互相覆盖，我一般用"时间戳加随机数加原后缀名"的规则，然后按日期建子目录存储。

学生提交后状态从"草稿"变成"已提交"，这时候页面要进入只读模式，不能再修改。这个"可编辑或只读"的切换就是状态机在页面层的体现。所以在service层的submitProject方法里，我建议第一步先判断当前状态是否为"草稿"，不是就直接抛出业务异常，由Action层捕获并提示，而不是默默放行——这个习惯能省掉大量脏数据。

5.2 专家评审：新增一条评审记录后同步更新汇总

评审模块的典型需求是：校级管理员把项目批量分配给评审专家，专家在"待评审列表"打开项目详情，打一个分数、填一段意见、选择通过或不通过。

实现上，评审结果保存后要完成两件事：写入project_review记录，并重新计算该项目所有评审记录的平均分。平均分我放在一个单独的方法里算，比如computeAverageScore(projectId)，用Hibernate的聚合查询就可以完成：

public Double computeAverageScore(Integer projectId) { String hql = "select avg(r.score) from ProjectReview r where r.project.id = :pid"; Object result = getHibernateTemplate().getSessionFactory() .getCurrentSession() .createQuery(hql) .setParameter("pid", projectId) .uniqueResult(); return result == null ? 0.0 : (Double) result; }

评审模块还有个细节：每个专家只能评一次，不能重复打分。这个约束不能只靠前端隐藏按钮，必须在service层校验，查询是否已存在当前评审人和该项目的评审记录，存在就抛异常。同样，评审专家不能评审自己指导的项目，这类业务规则也要在分配评审人时就校验一次。

5.3 统计报表：HQL聚合和SQL查询的取舍

立项率、各学院申报数、项目类型分布这类统计，是论文里"系统测试结果分析"的重要配图来源。我用HQL做简单的聚合，比如按学院统计申报数：

String hql = "select p.college, count(p) from Project p group by p.college";

返回结果是List<Object[]>，第一列是学院名，第二列是计数。这种查询简单直观，适合统计项目类型这类单表聚合。如果遇到多表关联加复杂条件，比如"某个学院立项的项目中，平均预算是多少"，我建议直接用原生SQL，用session.createSQLQuery()执行，再用Spring对结果做封装，不必死磕HQL。

统计接口建议单独建一个StatisticsService，Action根据前端传入的统计维度参数调用不同方法。这样模块边界清晰，论文画系统架构图的时候也能说"统计模块独立于业务模块"。

到这里，代码层面的核心内容其实已经接近完成。但对毕业设计来说，代码写完只是第一步，LW文档（论文）才是决定能否通过的重要部分，而且它需要与编码同步进行，不能等代码写完再开写。

6. LW文档写作和答辩准备：论文结构怎么体现出真实工作量

很多学生的论文是在代码完成后花一周凑出来的，结果被导师批得千疮百孔。我的经验是，论文写作应该和编码同步开展，先搭框架，边写代码边填内容，最后两周只做统一润色和查重。

6.1 论文结构怎么和实际代码对应

毕业设计论文的标准骨架大致是：绪论（背景、意义、国内外现状）、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。这个骨架本身没问题，问题在于很多学生把"相关技术介绍"写成教材复述，把"系统设计"写成截图堆砌。

我的建议是：相关技术这一章不要罗列Struts2是什么、Spring是什么、Hibernate是什么，而是讲"这套项目里这三个框架各自承担什么职责、它们之间通过什么机制协作"，配合一张自己画的整合架构图。需求分析章节直接使用第2节的功能清单和流程表，配用例图说明角色关系。系统设计章节重点放数据库表设计和状态机设计，把第3节的表结构、字段解释、外键关系讲清楚，并说明为什么这样设计。系统实现章节选3到4个核心功能详细讲，每个功能从"业务规则"到"实现流程"再到"关键代码片段"三层结构展开，代码不要全部贴，贴最核心的十几行即可。

6.2 测试章节怎么写才有说服力

测试章节是工作量最容易被看穿的章节。光写"系统运行正常，功能全部通过"等于什么都没写。正确的做法是一张功能测试表，每行一条测试用例，字段包括测试编号、测试名称、测试步骤、预期结果、实际结果、结论。比如"申报模块-01：学生登录后提交完整申报书，预期状态变为已提交，实际状态已提交，结论通过"，这样的表格能非常直观地展示你做过验证。

如果时间允许，我建议加一个小节写"异常场景测试"，比如重复提交是否被拦截、未登录直接访问评审页面是否跳回登录页、删除已立项项目是否被禁止。这部分的测试用例最能体现系统的健壮性，答辩时讲起来也很加分。不要编造性能测试数据，管理类系统没有并发压力测试的结果很正常，如实写"本系统面向校内用户，并发量有限，未进行大规模压力测试"反而更可信。

6.3 答辩被追问时怎么接得住

答辩的常见提问我大致预测一下：为什么选择s2sh框架组合？系统有哪些角色，权限是怎么控制的？项目状态如何流转，退回之后数据是保留还是删除？项目平均分是怎么算出来的，如果一个专家打分手抖写低了怎么办？文件上传后存在哪里，服务器重启文件还在吗？

这几个问题如果平时没有想过，现场很容易卡住。我给你的思路是：框架选择就从分层清晰、技术资料丰富、适合管理类系统来答，千万别贬低框架说"因为老师指定用这个"。权限控制直接讲拦截器加角色判断的流程。状态流回答清楚状态表和历史记录表的设计即可。平均分问题可以说"支持管理员手动调整或重新分配评审人重新评审"的补救机制。文件上传要说明存储路径和命名规则，如果只存在临时目录，就要如实说生产环境应该配置独立存储。

这类选题我每年都见，学生的水平差异很大，但最后拿高分的往往是同一个特征：能把自己系统里的业务流程讲明白。代码量本身不是决定因素，哪怕功能只是中规中矩的增删改查，只要状态机设计严谨、权限边界清晰、测试记录完整，论文的含金量就会明显不一样。

另外，做完这套s2sh毕业设计之后，我强烈建议用同样的业务需求自己动手迁移一版Spring Boot实现。你会发现，当你知道一个请求从Filter到Action到Service到Dao到数据库之间发生了什么，再用Spring Boot时就不是"照着文档配置"，而是"理解之后的选择"。这份理解，才是这个选题真正留给你的东西。