SSH和SSM是Java Web开发中两个里程碑式的框架组合。
核心区别：SSH vs SSM
| 特性 | SSH | SSM |
|---|---|---|
| 代表组合 | S truts2 + S pring + H ib ernate | S pring + S pring M VC + M yB atis |
| MVC框架 | Struts2： 通过拦截器处理请求，配置复杂，安全性漏洞较多。 | Spring MVC ： 通过注解@Controller处理请求，与Spring容器无缝集成，灵活简洁。 |
| 持久层框架 | Hibernate ： 全自动ORM，强大但笨重，SQL由框架生成，开发者控制力弱。 | MyBatis ： 半自动ORM，轻量灵活，SQL由开发者编写，控制力强，易于优化。 |
| 设计理念 | "重量级" 、声明式 、自动化。希望开发者尽量不写SQL，由框架管理。 | "轻量级" 、可控 、透明。将控制权交还给开发者，框架提供集成和便利。 |
| 流行年代 | 2006 - 2015年左右，是传统企业级开发的经典选择。 | 2013年 - 至今，是互联网时代的主流选择，并逐步演进为Spring Boot。 |
使用场景
选择 SSH 的场景（现已非常少见）：
- 遗留系统维护 ：主要工作是在维护一个十多年前开发的、基于SSH的老旧系统。
- 高度标准化的传统企业应用：在特定时期，SSH因其标准化的开发模式，在一些大型、稳定、业务逻辑复杂但对极致性能要求不高的传统行业（如某些政府、金融项目）中被广泛使用。
- 团队技术栈历史包袱：开发团队对SSH技术栈非常熟悉，且系统稳定，没有动力和必要进行技术栈重构。
总结 ：SSH可以看作是上一个时代的经典架构，但现在已基本被淘汰。 Struts2的安全问题和Hibernate在复杂SQL下的性能瓶颈是其没落的主因。
选择 SSM 的场景（当前主流）：
- 互联网Web应用 ：绝大多数需要高性能、高并发的互联网项目，如电商平台、社交网络、SaaS服务等。
- 需要对SQL进行精细化控制的系统 ：系统涉及大量复杂查询、关联查询、存储过程调用，或需要对SQL进行极致优化以提升数据库性能。
- 使用非标准或复杂设计的数据库：操作的是一个预先存在的、设计复杂且不便修改的数据库Schema。
- 追求开发灵活性和可控性的项目：团队希望既能享受Spring的便利，又能完全掌控SQL的执行。
总结 ：SSM是当今Java Web开发领域事实上的标准技术栈 ，因为它更轻量、更灵活、性能更可控，完美契合了互联网开发的需求。
演进与现状
无论是SSH还是SSM，现在都在向 "Spring Boot + Spring Cloud" 的生态演进。
- Spring Boot ：极大地简化了SSM的配置，实现了开箱即用 ，是目前创建新一代SSM应用的首选方式。
- Spring Cloud ：基于Spring Boot，提供了构建分布式系统/微服务的一整套工具。
最终结论 ：
对于新项目，应毫不犹豫地选择基于Spring Boot的SSM架构（即：Spring Boot + Spring MVC + MyBatis）。SSH已成为历史，仅在维护旧系统时需要了解。