从夯到拉，重新盘点 28 个后端技术：哪些值得学，哪些没必要跟风？

学后端开发，最容易陷入的一个误区，就是不停地追新技术。

刚学完 Spring Boot，又听说微服务是必备技能；刚把 MySQL 学明白，又开始研究 PostgreSQL；项目明明只有几个接口，却急着引入 Kafka、Kubernetes 和一整套分布式架构。

结果技术名词记住了一大堆，真正独立开发一个项目时，却依然不知道该怎么选择技术栈。

今天，我们就来盘点 28 个常见的后端技术，从实用性、生态成熟度、学习成本、性能表现和维护成本等角度，聊聊它们究竟值不值得学。

先说明一点：技术没有绝对的好坏，只有是否适合当前的业务场景。 本文的分级主要针对常见 Web 开发、个人项目和一般企业应用，并不代表所有行业、所有规模下的最佳选择。

一、先说评价标准

为了避免单纯凭个人喜好排名，我会从五个维度进行评价。

• 实用性： 在日常开发中是否经常用到，能够解决哪些问题。
• 生态成熟度： 社区、文档、第三方库及实际项目案例是否丰富。
• 学习成本： 从入门到能够在项目中正确使用，需要投入多少时间。
• 性能表现： 在合理配置和典型负载下，能否满足业务需求。
• 维护成本： 引入后是否容易部署、排查问题和持续迭代。

其中，对大多数开发者而言，实用性、生态成熟度和维护成本尤其重要。

毕竟，技术不是用来炫耀的。能够稳定解决业务问题、让团队长期维护得下去，才是好技术。

本文采用以下分级：

• 顶级： 在特定领域具有重要地位，值得深入研究。
• 夯： 实用性强，建议重点掌握。
• 人上人： 有明确价值，适合根据项目需求学习。
• NPC： 有适用场景，但不是大多数新项目的优先选择。
• 拉： 在特定的现代开发场景下竞争力有限，通常不建议作为新项目的首选。

注意，最后一级并不意味着这项技术完全没有价值。

二、应用开发框架：Spring 和 Spring Boot

1. Spring：顶级

如果你走的是 Java 后端路线，Spring 基本绕不开。

Spring 的核心价值在于依赖注入、面向切面编程以及丰富的基础设施支持。随着项目规模增长，它能够帮助开发者更好地组织业务逻辑、管理对象依赖和处理横切关注点。

优势：

• 企业级应用生态成熟。
• 依赖注入和 AOP 能够改善代码组织方式。
• 与数据库访问、事务管理、安全认证等技术集成完善。

需要注意：

Spring 的能力覆盖面很广，但这也意味着需要理解不少概念。初学者如果一开始就深入复杂的底层机制，容易把精力花在暂时用不到的内容上。

适合谁： Java 后端开发者，以及需要构建长期维护的企业级应用的团队。

综合评价：顶级。它不仅是一个框架，更是理解 Java 企业级开发的重要基础。

2. Spring Boot：夯

如果说 Spring 提供了基础能力，那么 Spring Boot 的价值就是让开发者更容易把这些能力组合起来。

自动配置、Starter 依赖、外部化配置和内嵌 Web 服务器等机制，可以减少大量重复的项目初始化工作。

开发者不需要从零手动配置每一项基础设施，就能快速搭建 REST API、管理系统和业务服务。

当然，Spring Boot 并不是没有代价。依赖管理、启动时间、内存占用和自动配置排查，仍然需要一定的经验。

适合谁： 几乎所有以 Java 为主要技术栈、需要快速交付业务应用的开发者。

综合评价：夯。对于准备开发管理系统、在线考试系统、内容平台等项目的人来说，优先学习 Spring Boot，通常比从底层研究传统 Spring 配置更有效率。

3. EJB：拉（针对新项目）

EJB 是 Java 企业级开发历史上具有代表性的组件技术，曾经承担过企业业务组件、事务和分布式调用等职责。

随着 Spring 生态的发展，以及现代 Java 企业开发方式的演进，EJB 已经不再是大多数新建普通 Web 项目的首选。

不过，不能因此认为它毫无价值。一些传统企业系统仍可能依赖相关技术，维护这些系统时依然需要了解 EJB。

适合谁： 维护传统 Java EE 系统、进行遗留系统迁移的开发者。

综合评价：对于普通新项目，通常没有必要优先学习；如果工作涉及存量系统，则需要根据实际情况决定。

三、容器与部署：Docker 和 Kubernetes

4. Docker：夯

开发环境能够运行，换到服务器却启动失败，是很多项目都会遇到的问题。

Docker 通过镜像和容器，将应用运行所需的环境及依赖进行相对一致的封装，从而降低环境差异带来的部署问题。

它常用于：

• 统一开发、测试和生产环境。
• 部署数据库、缓存和消息队列。
• 构建自动化发布流程。
• 简化应用交付与环境迁移。

需要注意的是，容器并不意味着应用完全不受宿主机、网络、存储和权限配置影响。生产环境仍然需要正确管理日志、数据持久化和安全配置。

适合谁： 几乎所有需要部署服务端应用的开发者。

综合评价：夯。即使暂时不做微服务，也值得尽早掌握。

5. Kubernetes：顶级

Docker 解决了应用如何容器化的问题，而 Kubernetes 主要解决大规模容器应用如何编排和管理的问题。

它可以提供服务发现、调度、滚动更新、故障恢复和自动扩缩容等能力，适合需要管理大量服务和容器的场景。

但 Kubernetes 也有明显的复杂度：集群维护、网络配置、资源调度、权限管理和监控体系，都需要投入成本。

对于只有一个后端服务的个人项目，直接使用虚拟机或 Docker Compose，往往更简单。

适合谁： 云原生工程师、平台工程师，以及需要管理复杂服务集群的团队。

综合评价：顶级，但不是所有开发者都需要立即学习。先解决部署问题，再考虑是否需要容器编排。

四、数据库与缓存：MySQL、PostgreSQL 等

6. Redis：夯

Redis 是常见的内存数据存储系统，在 Web 开发中用途非常广泛。

它可以用来实现缓存、计数器、排行榜、会话数据以及部分分布式协调场景。

它的优势不仅是速度快，还在于支持字符串、哈希、列表、集合和有序集合等数据结构。

但 Redis 也不是万能的。内存成本、缓存失效、数据一致性、持久化策略以及分布式锁的正确使用，都需要认真考虑。

适合谁： 需要改善响应速度、降低数据库压力，或处理高频读写数据的开发者。

综合评价：夯。先学会基本数据结构、缓存策略和常见故障处理，再研究更复杂的高可用方案。

7. Memcached：NPC

Memcached 是一款经典的分布式内存缓存系统，设计相对简单，主要用于存储键值形式的缓存数据。

它的优势在于专注、轻量，适合某些对缓存功能要求不复杂的场景。

不过，它的功能范围比 Redis 窄，缺少 Redis 那样丰富的数据结构和内置数据处理能力。因此，在很多新项目中，Redis 会成为更常见的选择。

这不代表 Memcached 一定性能更差。实际效果还要结合数据模型、访问模式、部署方式和压测结果判断。

适合谁： 维护现有 Memcached 系统，或有明确需求的缓存场景。

综合评价：NPC。了解其定位即可，不必把它作为大多数新手的第一款缓存技术。

8. MySQL：夯

MySQL 是关系型数据库中的常用选择，适用于用户管理、订单系统、内容平台、管理后台等大量业务场景。

它支持事务、索引、约束和多表关联，能够为结构化业务数据提供可靠的存储基础。

对于绝大多数 Web 项目，正确设计表结构、索引和事务，比盲目追求更复杂的数据库架构重要得多。

需要注意的是，MySQL 也有自己的使用边界。复杂查询、特定数据类型和高级扩展能力等方面，可能需要与其他数据库进行比较。

适合谁： 几乎所有需要存储结构化业务数据的开发者。

综合评价：夯。学习后端时，数据库设计、SQL、索引、事务和慢查询分析都应该成为重点。

9. PostgreSQL：顶级

PostgreSQL 是功能丰富的开源关系型数据库，具有强大的 SQL 能力、扩展机制和丰富的数据类型支持。

它适用于复杂查询、分析型业务、地理空间数据处理等场景，也可以通过相关扩展支持向量数据检索。

与 MySQL 相比，PostgreSQL 并不是在所有情况下都更快，也不能简单地说 MySQL 的生态一定更好。两者都拥有成熟的使用场景，具体选择取决于业务需求、团队经验和运维能力。

适合谁： 需要复杂 SQL、丰富的数据类型、扩展能力，或希望深入研究关系型数据库的开发者。

综合评价：顶级。值得认真学习，但没必要因为它功能强大，就认为所有项目都必须从 MySQL 迁移过去。

10. MongoDB：人上人

MongoDB 是文档型数据库，适合以文档为主要组织形式、字段结构存在变化的业务数据。

它的灵活性有利于某些快速迭代场景，但灵活的结构不代表不需要数据建模。

事务、索引、关联查询、数据一致性以及容量规划，仍然需要根据实际业务设计。

例如，内容元数据、部分日志类数据和结构变化较大的文档，可能适合 MongoDB；订单、账户等强关系业务，则需要仔细评估数据关系和事务要求。

适合谁： 有文档数据建模需求的开发者。

综合评价：人上人。先理解关系型数据库，再根据实际业务需要学习文档数据库，通常是更合理的顺序。

五、Web 服务与反向代理：Nginx

11. Nginx：夯

Nginx 常用于静态资源服务、反向代理、TLS 终止和负载均衡。

例如，一个典型的前后端分离项目，可以让 Nginx 对外提供统一入口，再将 API 请求转发给后端服务。

它的价值不只是性能，还在于能够帮助开发者清晰地组织应用入口、路由和部署结构。

但 Nginx 也需要正确配置访问控制、超时、请求大小限制和代理头等参数，否则可能带来安全或运维问题。

适合谁： 需要将 Web 项目部署到服务器上的开发者。

综合评价：夯。即使是小型项目，了解基本的反向代理和 HTTPS 配置也很有帮助。

六、消息队列与搜索：RabbitMQ、Kafka、Elasticsearch

12. RabbitMQ：人上人

RabbitMQ 是成熟的消息代理系统，支持多种消息路由模式、确认机制和消息可靠性处理。

它适合订单通知、异步任务、业务事件传递等场景，可以帮助系统解耦，并避免部分耗时操作阻塞主请求。

需要注意的是，引入消息队列后，开发者还必须处理消息重复、失败重试、死信、积压和幂等性等问题。

适合谁： 需要异步处理和可靠消息传递的业务系统。

综合评价：人上人。它并不一定适合所有项目，但在业务异步化方面非常实用。

13. Kafka：顶级

Kafka 是面向事件流和高吞吐消息处理的重要平台，广泛应用于日志采集、数据管道和实时数据处理。

它通过分区、持久化日志和消费者机制，支持大规模数据流的处理。

但 Kafka 的价值不应只用吞吐量衡量。分区设计、消费位点、重复处理、顺序保证和集群运维，都会影响实际使用效果。

对于简单的后台通知或少量异步任务，Kafka 可能带来不必要的复杂度。

适合谁： 大规模事件流、实时数据管道和需要高吞吐消息处理的团队。

综合评价：顶级。值得了解其架构，但应当在业务确实需要时再引入。

14. Elasticsearch：夯

Elasticsearch 是基于 Lucene 的分布式搜索与分析引擎，适用于全文检索、日志检索和多条件搜索等场景。

如果项目需要对大量文本进行相关性搜索、分词和复杂检索，它可以提供比普通数据库查询更合适的能力。

但 Elasticsearch 不是所有数据的默认存储位置。索引同步、数据一致性、磁盘占用、集群资源和查询调优，都需要额外管理。

适合谁： 需要全文搜索、日志检索或复杂搜索分析的开发者。

综合评价：夯。先确认数据库查询无法经济地满足需求，再决定是否引入搜索引擎。

七、版本管理与协作：Git、SVN

15. Git：夯

Git 是现代软件开发中最重要的基础工具之一。

它支持分支管理、提交历史、代码合并和版本回退，能够帮助个人与团队更可靠地管理代码变化。

掌握 Git 不只是记住几个命令，还包括理解提交、分支、合并冲突、远程仓库以及代码审查的协作流程。

适合谁： 所有开发者。

综合评价：夯。优先级甚至高于很多高级后端中间件。

16. SVN：NPC

SVN 是集中式版本控制系统，在部分传统企业和存量项目中仍然发挥作用。

与 Git 相比，它的协作模型和分支工作流有所不同。对于现代分布式协作开发，Git 通常是更常见的选择。

但如果公司现有项目依赖 SVN，掌握其基本使用方法仍然很重要。

适合谁： 需要维护 SVN 项目，或在使用 SVN 的团队中工作的开发者。

综合评价：NPC。新项目通常优先考虑 Git，但不必为了追求新技术而强行迁移成熟的存量系统。

八、微服务与分布式协调：gRPC、Dubbo、Nacos 等

17. gRPC：顶级

gRPC 是支持多语言的远程过程调用框架，通常使用 Protocol Buffers 定义服务和序列化消息，并利用 HTTP/2 提供通信能力。

它适合服务之间需要明确接口定义、高效数据传输和流式通信的场景。

不过，gRPC 并不是普通 Web API 的必然升级方案。浏览器直接访问、调试便利性、网关支持和团队熟悉程度，也会影响技术选择。

适合谁： 跨语言服务通信、内部 RPC 和需要流式通信的团队。

综合评价：顶级。先掌握 HTTP API，再根据服务间通信需求学习 gRPC。

18. Dubbo：人上人

Dubbo 是 Java 微服务生态中具有代表性的 RPC 框架，提供服务调用、负载均衡和相关治理能力。

对于需要服务间高效通信、并且已经使用相关 Java 微服务体系的团队，它有明确的价值。

但如果项目只有一个后端应用，单独引入 RPC 框架未必能带来收益。

适合谁： Java 微服务开发者，以及需要维护 Dubbo 系统的团队。

综合评价：人上人。是否值得学习，取决于你的项目架构和工作环境。

19. Nacos：人上人

Nacos 常用于服务发现和配置管理，是 Spring Cloud Alibaba 生态中的重要组件。

在微服务环境中，它可以帮助服务注册、发现和管理配置，减少服务之间的静态地址依赖。

但配置中心并不意味着可以忽略权限、配置变更审计和敏感信息管理。服务数量少时，也未必需要引入完整的微服务治理体系。

适合谁： 使用 Spring Cloud Alibaba 或需要集中管理服务配置的开发者。

综合评价：人上人。学习前应先理解服务发现、配置管理和微服务的基本概念。

20. ZooKeeper：NPC

ZooKeeper 是经典的分布式协调服务，能够提供协调、状态管理和相关一致性能力。

它在一些传统分布式系统中仍然重要，但现代系统也会根据具体需求选择其他方案。

例如，Kafka 已经支持通过 KRaft 模式进行元数据管理，不再必须依赖 ZooKeeper。这并不意味着 ZooKeeper 已经失去所有用途。

适合谁： 维护依赖 ZooKeeper 的系统，或需要理解传统分布式协调机制的开发者。

综合评价：NPC。新手不必优先深入，但应该了解它在分布式系统中的作用。

21. etcd：顶级

etcd 是基于 Raft 共识算法的分布式键值存储系统，常用于 Kubernetes 的集群状态和元数据管理。

它的核心价值是为分布式系统提供可靠的一致性存储，而不是替代日常业务数据库。

如果只是开发普通 CRUD 应用，通常没有必要直接操作 etcd；如果研究云原生平台或分布式系统，它就很值得学习。

适合谁： 云原生、基础设施和分布式系统开发者。

综合评价：顶级。专业价值很高，但学习优先级取决于发展方向。

九、监控、自动化与接口文档：Prometheus、Jenkins 等

22. Prometheus：人上人

Prometheus 是常见的指标监控系统，支持指标采集、PromQL 查询和告警规则。

它能够帮助团队发现服务延迟升高、错误率异常和资源使用过高等问题。

不过，监控体系不只是安装一个 Prometheus。指标设计、告警阈值、仪表盘、数据保留和告警降噪，同样重要。

适合谁： 需要建立服务监控与告警体系的开发者和运维工程师。

综合评价：人上人。项目进入持续运行阶段后，监控的重要性会明显提升。

23. Jenkins：人上人

Jenkins 是成熟的持续集成与持续交付工具，具有丰富的插件生态和灵活的流水线能力。

它可以帮助团队自动执行构建、测试、打包和部署任务，减少人工操作。

它的不足主要体现在维护复杂度、插件治理和运行环境管理上。对于简单的代码托管项目，平台自带的 CI/CD 功能可能更省事。

适合谁： 需要自建自动化流水线，或维护现有 Jenkins 环境的团队。

综合评价：人上人。重点不是追求某款工具，而是理解自动化构建、测试和部署的基本流程。

24. GraphQL：NPC

GraphQL 是一种 API 查询语言及运行时，允许客户端声明需要哪些字段。

当不同客户端对同一批数据有不同的获取需求时，它可以减少部分接口设计上的重复，并提供统一的数据查询方式。

但 GraphQL 也会带来查询复杂度控制、权限校验、缓存、监控和潜在的 N+1 查询等问题。

REST API 依然适合大量常见业务，并没有因为 GraphQL 的出现而过时。

适合谁： 客户端数据需求复杂、接口组合成本较高的团队。

综合评价：NPC。了解其设计理念即可，是否采用应根据真实 API 需求决定。

25. Swagger / OpenAPI：人上人

Swagger 常被用来描述、展示和调试 API；OpenAPI 则是广泛使用的 API 描述规范。

它们可以帮助前后端共享接口定义、生成文档和客户端代码，并改善接口协作流程。

在实际项目中，接口文档的价值并没有因为 AI 编程工具出现而消失。相反，清晰的接口规范有助于开发者、测试工具和 AI 编码助手理解系统边界。

需要注意的是，Swagger UI、OpenAPI 规范和相关工具并不是完全相同的概念。

适合谁： 所有需要进行 API 设计和前后端协作的团队。

综合评价：人上人。相比纠结使用哪一种文档界面，更重要的是保证接口定义准确、及时更新。

十、传统 Java Web 技术：Tomcat、Struts、JSP

26. Tomcat：人上人

Tomcat 是经典的 Java Servlet 容器，也是 Java Web 技术体系的重要组成部分。

在 Spring Boot 项目中，Tomcat 经常以嵌入式服务器的形式出现。开发者可以直接启动应用，而不必每次都手动部署到独立的 Tomcat 实例。

因此，“使用 Spring Boot 就不需要 Tomcat”并不准确。更准确的说法是：很多项目不再需要单独管理一个外置的 Tomcat，但仍可能使用它提供的容器能力。

适合谁： Java Web 开发者，以及需要维护传统部署环境的团队。

综合评价：人上人。普通开发者不必一开始深入容器底层，但应该了解 Web 请求如何进入应用并被处理。

27. Struts：拉（针对新项目）

Struts 是 Java Web 开发历史上的经典 MVC 框架，曾经被广泛用于企业应用。

随着现代开发框架和工程实践的发展，Struts 已经不是大多数新建 Java Web 项目的优先选择。

对于存量系统，是否迁移仍然要评估安全风险、业务复杂度、升级成本和维护周期，而不是简单推倒重写。

适合谁： 维护传统 Struts 应用或参与遗留系统升级的开发者。

综合评价：对于普通新项目，不建议优先采用；历史价值和存量维护价值仍然存在。

28. JSP：NPC

JSP 是传统 Java 服务端页面技术，可以在服务器端生成动态 HTML。

在早期 Java Web 应用中，JSP 承担过重要角色。现代前后端分离项目则通常采用独立的前端框架和后端 API。

但这不意味着 JSP 完全失去用途。在某些传统系统和服务端模板场景中，它仍可能出现。

适合谁： 维护传统 Java Web 项目，或需要理解经典服务端页面渲染方式的开发者。

综合评价：NPC。新项目通常优先考虑现代前端架构或更符合当前技术栈的服务端模板方案。

十一、如果从零学习后端，应该怎么安排顺序？

看完 28 项技术，最重要的问题不是谁排第一，而是应该先学什么。

如果你的目标是独立开发一个完整的 Web 项目，我更建议按以下顺序推进。

第一阶段：打好基础

优先学习：

• 一门后端语言及其基本语法。
• HTTP、REST API 和常见网络概念。
• MySQL、SQL、索引和事务。
• Git 的基本操作。
• Spring Boot 或所选语言对应的主流 Web 框架。

这一阶段的目标是能够独立完成用户管理、数据增删改查、登录认证和基本业务流程。

第二阶段：具备完整项目交付能力

重点学习：

• Redis 与缓存策略。
• Docker 和应用部署。
• Nginx 与 HTTPS。
• 接口文档和自动化测试。
• 日志、异常处理和基础监控。

这一阶段应该尝试把项目真正部署起来，而不是只在本地运行。

第三阶段：根据业务需求扩展

在有明确需求时，再学习：

• RabbitMQ 或 Kafka：异步任务和事件处理。
• Elasticsearch：全文搜索。
• gRPC 或 Dubbo：服务间通信。
• Nacos：微服务注册与配置管理。
• Kubernetes：容器编排。
• Prometheus：更完善的指标监控。

这些技术并不是越早学越好。先理解业务问题，再选择能够解决问题的工具，学习效率通常更高。

十二、最后总结：真正值得掌握的，不是技术排行榜

如果只能给刚入门的后端开发者一些建议，我会把重点放在三个方面。

第一，先掌握基础设施。 编程语言、数据库、Git、Web 框架和部署能力，是构建完整项目的基础。

第二，不要过早追求架构复杂度。 单体应用并不低级，微服务也不天然先进。架构应该服务于业务规模、团队协作和运维能力。

第三，学会解释技术选择。 你应该能够说明为什么选择 MySQL 而不是 PostgreSQL，为什么使用 Redis，为什么需要消息队列，以及引入这些技术后需要承担哪些成本。

技术能力的真正体现，不是能说出多少框架和中间件，而是面对一个实际问题时，能够做出合理的取舍，并把系统稳定地交付出去。

最后也想问问大家：这 28 项技术中，你觉得哪一项被高估了？又有哪些技术值得更高的评价？欢迎分享你的实际使用经验。