看招聘信息的话，springboot 无处不在，你喜欢它吗？还是有其他的选项？有什么原因/理由？

Spring Boot 行业标准了，也没有其他更好的替代，姑且用着吧

没错，它已经是事实标准了。不过先抛开标准不谈，它的理念符合你的个人审美吗？或者有更喜欢的但工作中又无法实施的框架。

没得选

工作中没得选，个人项目还是可以选的，就是聊聊个人喜好

个人项目可以试试 solon

可以试试 quarkus

个人项目建议 go Java 已死

＃2 写多了，其实发现还是 spring boot webmvc 这套实用性是最强的。像类似 reactive/或者 router handler 那种事件驱动的，初时觉得写起来很爽，但是项目规模上去一点以后你会发现路由注册的很难管理。还不如注解声明的，更不要提各种 Validation 了。

个人经历，用过 spring webmvc ，虽然没写过 webflux 但是用过 node 那边的 koa/express ，代码逻辑上是差不多的。

bean 验证底层是 hibernate-validator 库，这个整合到任何框架里也不是难事。简单验证可能十行代码以内，还可以任意实现自己想要的验证形式。

路由的话，JAVA 或 js 都可以通过方法引用（ ctrl::action ）做集中式的路由管理，这个会不会比 springboot 分散的注解式的更一目了然？

粗看之下是 springboot 的形状，之后细看一下。

您选择它的原因是什么？

个人项目可以 node ，golang 。要不是发钱我肯定不捏鼻子写 java 。

一年前我用 Vert.x 写过一个博客后台的服务，感觉速度很快，占用内存也小

两位大佬都推荐 go ，和 JAVA 相比是为啥呢？我用过两年 go ，不过时间过去比较久了，它的鸭子类型，默认 0 值，interface{}等等个人不太喜欢。。。不知道现在如何了

go 比较轻量

我也喜欢它的天然分布式和消息总线机制。不过这却是把双刃剑，耍不好容易伤到自己。写代码时的心智代价也有点大，希望它能在虚拟线程发展成熟后，转为同步形式。

轻量是指资源消耗还是框架规模？框架规模大了资源占用也就大了。不上大框架都很轻。

springboot 不符审美，因此我早早放弃 java

哈哈，兄弟这么决绝，JAVA 也一同放弃。说说理由呗

谈不上喜欢不喜欢，反正用着挺方便

公司用 Spring 就是需要它大而全的生态，否则也不必用 Java 了。

能给我带来工资的都是好框架，自己喜不喜欢不重要，上班就是卖时间的。

nutz ，当时作者在论坛里回复问题可热情了

只是换了个略正规的公司后，大家都用 Spring 那一套了……

quarkus+vert.x

相信红帽

说一些客观的理由

• 首先，我做过 springboot 的项目，也做过 gin(go)、nextjs(js)、aspx(C＃)、asp 、等主流 web 框架的项目。
• 没有对比就没有伤害。我的衡量标准是开发效率和学习成本，衡量方式是：开发同样功能，是不是需要更少代码，是不是需要掌握更少的概念，那 springboot 完败。
• 如果你只用过 springboot ，而它恰巧成为你吃饭的家伙，你自然会认为他非常优秀，毕竟你的标准是能赚钱，至于效率啥的不需要关心，反正老板不开你就 ok
• 有的人会说其它框架的文档我也看过，但总有 XXX 毛病让我不能接受。那其实你已经先入为主了。你所谓的毛病其实都是“给自己一个不想学其它东西的借口”，要是那些毛病真的是毛病，为啥全球还有上百万的人学习那个框架？

• 我是 web 框架的设计者，我认为未来 springboot 的占有率一定会逐步下滑。

  工作上都是牛马的马靴和抗架，谈什么个人喜好，在工具的选择上牛马和资本家是高度一致的：怎么样综合成本最低那就选择什么工具

  我们现在的技术栈更多的是 Jdk 自带的，没有用到框架，有印象的第三方库就是 disruptor ，还有就是 aeron ，chronicle map 这种

  混口饭吃，还管什么审美。 能吃到饭的，就是好框架。。。

  我的考虑和期待和你的结论一样, springboot 一定会跌下神坛.
  你说的这些没毛病, 只是"为啥全球还有上百万的人学习那个框架？"这句话又给 springboot 做了注脚. 我个人认为, 人的选择除了不得不选也受限于能力/视野/审美/理念等等, 所以千奇百怪的解决方案层出不穷, 在此之上又带来无穷的问题, 在基于创造的问题再创造解决方案, 螺旋屎山由此拔地而起.
  可惜没有说放下 java 的理由, 我想看看你选择的语言和设计的框架~

  这个是最好的, 高端的食材不需要复杂的烹饪技巧. 按照自己的业务发展出一套编码标准是最牛逼的

  Springboot

  我简单说下我在做的框架的一些理念：

• 未来程序员一定是结合 AI 工作的，新的框架必须是 AI 友好（意思是，能确保 AI 生成 100% 对的代码）
• 大部分传统框架帮忙做的事情，都不再要手写代码（比如，更新路由表，接口参数校验，CRUD ）

• 各大厂的基建，一定是框架集成好的功能（比如，服务端热启动、服务器监控、错误跟踪、SQL 优化和漏洞扫描），而且用法、规范统一。
  如果有兴趣可以私我邮件细聊。

  当然是 vert.x ，没魔法够简单，搭配 springboot 做 di ，开发效率和性能兼顾

  ＃9 倒不是说集成的难度，而是说如果 validation 这个不在路由里感觉会比较怪，如果是在路由里，会把集中式的 router 搞得很难看，如果 router 拆分，那最终结果还不如直接 annotation 注册。

另外还有就是因为我们是比较强要求做 restful 的，所以会用到很多 path params 的，这个在 router 里写起来也会把 router 那块搞得很大，同时也包括验证的问题。

micronaut + spring

别说，nutz 我还真拿来干过小项目，用起来还真不错。

java 优势是适合军团作战，规模化开发

只要不是 ruoyi 这个毕业设计框架就行

＃38 ruoyi 不是 web 框架，偏应用了，后台管理系统的工程模板

＃4
个人项目还用 java 吗？

我用的
www.mjga.cc
这个框架

springboot 还好把，我觉得 spring boot 主要是文档写的不太行，很多东西都不写清楚。

那是因为 Java 博大精深

springboot 用的最多，其次用过 javalin ，ktor

先不说功能问题， 论文档， 请教一下哪一家比 spring 系列好的？

在需要 java 各种生态的条件下， 除非你的后台比 spring 还硬， 否则你写一个 web 框架屁用没有。
国内模仿 springboot 的框架不少吧？ 有人用吗？
个人写项目和企业写项目完全是两个东西， 不是神话 apache, spring , 他们拥有一个完全的项目规范， 从代码质量，测试用例，漏洞跟踪， 你个人开发的有吗？连测试用例都没有，你自己写一个框架有个屁用。

再说个人开发现在用 python, node,go 来实现 web server, 甚至用 cloudflare worker 都已经能够完全替代 spring boot 了，spring boot 占有率落后是必然。 不过企业开发还得是大厂背书。

竟然没看到 jfinal

曾经在不少项目里用过 jfinal 其实也挺好的

最近在用 solon

ktor ， 特轻量，可以在安卓平台跑

个人项目 JVM 生态也非常舒适，我用 Kotlin 写后端，少封装几层，开发效率不低于 Python/PHP 。如果用 Go ，倒是能节省一半左右内存，但是要损失一些开发效率，把 map/filter/fold/reduce 写成 for 总是要啰嗦一些。

从 SDK 支持度看，nodejs 和 Go 就首先被排除在外了，很多时候要么用第三方要么自己轮。
微信支付，SDK 官方只支持 Java 、PHP 、Go ，
支付宝，SDK 官方只支持 Java 、PHP 、C＃、Python 、Node.js ，Easy 版支持 Java 、C＃、PHP 。

写的代码好不好，不是根据代码越少、掌握的概念越少来衡量的。这就是为什么要设计模式的原因。如果你用这样的衡量标准，那么你需要一起否定一下设计模式。因为设计模型才是真正的，增加 10 倍代码量和 10 倍概念的原因。

你可以有你的衡量标准。但请不要试图去证明哪个标准是对的，哪个标准是错的。世上没有绝对的对和绝对的错。
聪明的人，在不同的情况，可能也有不同的标准，而不是认准一套。

作为语言、框架的设计者，只要用户认为我的产品能帮他解决问题、提升效率，那就是硬道理

反正别碰异步框架

关于设计模式，我确实是非常反感的。我认为那是把简单的解决问题的方法用哲学的方式去表达。

举个例子：什么是观察者模式
观察者模式是定义了一种一对多的依赖关系，当一个对象的状态发生改变时，其所有依赖者都会收到通知并自动更新。
你需要先创建一个 Subject，然后创建一个 Observer，然后 订阅 Observer ，当 Subject 被修改时，需要通知 Observer，Observer 随后可以做出反应。
如果你是 Java 用户，会觉得上面这段话“小儿科”，
如果你没学过 Java ，很可能觉得这段话莫名其妙。

同样的需求，在我的框架下如何实现？
如果你希望一个对象被修改时执行一个函数，但这个函数不想固定写死。那你可以创建一个变量，变量的值是一个函数，因此它可以和函数一样被调用。

var callback
callback += (obj) => log('传入 1 obj = ', obj) // 串联已有的 callback
callback += (obj) => log('传入 2 obj = ', obj) // 串联已有的 callback
callback(1) // 打印 传入 1 obj =1 传入 2 obj =1

Helidon

与其说是 spring 的生态, 我更倾向于说 java 的生态比较丰富, 围绕注解和配置文件的封装到底是不是好事这值得商榷, 双份文档和打断调试逻辑也是各有见解吧.

带来工资的当然是好框架, 却不能证明不带来工资的是坏框架,哈哈

我倒是觉得这个未来还比较远, 事实上 AI 对准确性的把握在目前正是弱点吧, 更不要说对业务的准确理解. 有句话说的好, "复杂度不会消失, 只会转移", 虽然这话需要一定的前提, 但你总要有输入才会有输出, 路由/验证/crud, 你总要通过某种途径告知"框架", 自然语言是不保险的, dsl 是另一种复杂度. 关于基建, 我对框架集成, 大多数时候是持否定态度, 暂时说到这, 有兴趣一起交流 [email&＃160;protected]

说说个人看法, 和你相反, 参数验证在路由里才比较奇怪(仅数字那种不算), 参数在直观上应该属于业务的一部分(不完全准确), springboot 在请求处理方法的参数上加验证, 看起来有点强上注解的感觉. 当然了, 个人看法, 不必深究.

＃56 日常工作是 spring cloud 和 go 双修，所以我仍然坚持我的观点，更倾向于说 Java 语言中的 spring 生态完善。

没事每个人都可以有独立思维，倒是也不用强行认知统一😂

vertx+jax-rs 绑定+kt coroutine 随便写写

大厂有大厂的规范, 作坊有作坊的打法, 个人更是各有喜好, 既然被代替是必然性, 那么考虑一下被什么样子的东西替代也是好的. 论文档的话, spring 的文档实在不值得恭维, 我说它赶不上 php 的文档都不算羞辱, 另外铺天盖地的博客文章来讲解 spring 的某些问题的解决, 某些实现的方法, 也能在一定程度上证明它的文档的缺失. 话说回来, 它的文档描述的更多的是自己创造的问题/概念, 这很难说它的文档很好.

个人项目用自己熟悉的挺好的

yes, 做技术最重要的是舒心~
不过并不是为了统一认知, 这在计算机的巴别塔中, 始终不曾存在.

个人感觉，spring 的文档非常好，“铺天盖地的博客文章来讲解 spring 的某些问题的解决”基本上在官方文档里都有答案。当然，spring 的文档不是给你哪有问题查哪儿的，它需要先系统性的过一遍，把该学的概念都了解个七七八八，然后你才有思路，知道往什么方向查。

其实在上一个回复里最后那句才是真的值得考虑的, 延展开来就是, 一个框架提出了很多的概念, 在这些自创的概念上来补充使用文档, 而这些概念甚至实现到底是在解决问题还是制造问题? 我个人的看法是在 spring 身上, 已经完全超出了解决问题的范畴, 对自动装载或注解的执着, 造成最终考验使用者的不是 java 或编程技巧, 而是在其之上的专门经验, 这可能也是它的任何一个点都会被 blogger 一遍一遍的重复记录.

不是很理解，这种框架收费是什么鬼？

我倒是不反对设计模式, 一个程序员哪怕没有看过设计模式, 经过很多业务的折磨, 最终也会写出那些业务模式总结出来的形状. 不如说, 设计模式是一种业务表达的结果, 照搬设计模式去套业务才是该反省的地方.

Spring 独创了什么概念？ IoC 是 1980 年代就广泛使用的技术，AOP 的使用也比 Spring 更早，MVC 是 1970 年代的古董。框架只不过是已有概念的实现，每个概念都用于解决一些问题，熟练掌握之后能提高效率。如果一个框架的学习成本极低，那大概这个框架做不了稍微有点复杂度的项目。

话说，Java 语言的哪一个知识点不被 blogger 一遍一遍的重复记录？如果这都能成为“考验”，没必要死磕，换个别的方向就是了。

之前 Django 被吐槽大而全，于是小而美的 Flask 得到青睐，后来大家因为项目需求变复杂了，就不得不引入各种配套的框架/库，最后再自己组装黏合在一起，重新发明了一个 Django 。Spring 依赖注入那套东西，不知道被多少人在自己的项目中重新发明了一遍，每个人都要做一遍拓扑排序。

我所在的商业化团队 主用 go gin 但公司上百号的人都是 java ，所以我们在奔向 java 的 springboot 我工作 6 年，一直写 java ，但是工作其实 python java go 没那么有所谓 能快速解决问题就行。代码的健壮和优美只和写的人有关系，框架有一些明面的缺陷，团队领导者能因地制宜解决业务问题就是好语言好框架。

对于个人而言，中间 vert.x 给人的感觉很不一样，尤其是我这种只接触过 springboot 的人，生产中有段时间公司有个 slg 的游戏，后端就是 vert.x 框架，但那个游戏后端主程表示 java 就是一坨屎，远不如 c++,他很想用 c++但是业务好像没给他太多时间，公司的所用中间件都是基于 java 设计的，从监控、链路追踪、日志、健康检查、熔断、限流、服务网格这些 都是盯着 java 设计的。

ps:现在我觉得语言什么都行，能帮老板达到业务目的、你能保障这个语言下的 SLA 就行，java 也可以做成本、无非是换一套向上管理的说辞罢了，你省下来的内存会在招聘的时候原封不动花在招聘上，对于业务团队计算 roi ，机器成本、开发成本、人力成本都是在指标内的。

ioc ，aop 我也每日使用，并且一样是通过注解的形式去使用。你说的很好，框架来实现概念，那就应该想清楚这个实现的边界。spring 对此的把握如何？他对注解是否在滥用？对 di+自动装配带来的影响是否有过反思？

是的，每一种技术都会被很多人学习记录，但总是要权衡一个值得的界限，在我这 JAVA 比 spring 更值得学习，所以我不死磕，也一样在 JAVA 的方向上。

我大概说清楚了吧。

最后，我相信在 java 里他们会加入 di ，因为 di 是真的解决问题的一个理念。但 flask 到 django 你真的认可吗？思考与不思考后选择 django 都截然不同，更不用说，在实践中组装出适合自己业务的框架。轮子是一定要造的，把所有轮子叫轮子没错，但都叫重新发明了“spring”，“django”就是傲慢。

一个因地制宜道尽所有。有所思考的选择，和追随潮流的选择一定有所不同。哪怕结果一样。这时受制的是个人见识了，我亦在此列。结贴，睡觉。

在有注解之前，Spring 都是通过 XML 装配，有了注解之后，大家用脚投票投的注解，没几个人想回到动辄手写上千行 XML 的年代。注解的“滥用”是多年下来自然选择的结果，事实上 Spring 除了注解和 XML ，也支持手写代码的方式装配。注解和 DI 是好东西，比较新的框架 quarkus 也选择了这个姿势，注解和 DI 带来的问题大家都知道，Spring 的解题思路是 AOT ，quarkus 的接替思路是 build-time oriented dependency injection ，殊途同归，都把本来运行阶段才做的工作前置到 build 阶段。

每个人习惯不同，我在使用一个框架前，会把文档完整的过一遍，我不觉得看个小几百页文档能影响我学习其它东西。比如我使用 Vert.x 前，官网文档过了一遍，顺便把 netty 也过了一遍，实际也花不了多少时间。这些也都不会白看，后续学习 quarkus 时就流畅的多，甚至第一次学习 php laravel 时有似曾相识的感觉。

各个框架都是现有技术的应用和组合，也许有一些地方做的选择不同，但大体上也就那么几种，用户会用脚投票，经过长时间的检验，淘汰掉那些不那么适合项目的选项。对大部分开发来说，历史包袱不太大的项目，你不能选的那几个选项，可能在项目初期被人权衡利弊之后删掉了。

我经历过几个从小而美轮子演化成大而全的项目，有些甚至在发展了几年后整个丢弃掉，来个大版本升级，直接基于开源方案二次开发了。

现在我对大而全框架没工作头几年那么排斥了，我只有两个要求，我用不到的功能不要消耗我的 CPU 和内存，我要扩展时要有足够的弹性。

对 SpringBoot ，说不上喜欢。但是其几乎是行业标准，大而全，文档多，对新人友好等等，在 Java 领域且对于公司级别的项目，没有对手。

正常 spring boot ，但相信没几个人会喜欢吧。

小项目有用过 ktor ，挺不错的。但，确实，现在细想起来，用 ktor 的项目，其实完全可以用 golang / rust 等其它语言来替代。

这是我做的产品，具体有什么法律规定这种软件不可以收费吗？

大部分项目都是 springboot ，毕竟公司的人员结构就是这样，大家都熟悉这一套，去年，不对，前年在一个小项目中用过 vert.x ，主要是我自己搞，不需要关注别人怎么用，用下来，感觉同步转异步的学习成本还是挺高的，而且遇到问题没有现成的解决方案，一个小问题也要折腾挺久的

所以从公司或者管理者角度看，肯定是用 springboot 这一套风险小，对于技术 leader 来说，不同的人有不同的风格，有些人偏保守，不喜欢引入新的东西，有些人喜欢尝试新的事物，但是前提应该都是自己能控制，别最后没人能解决问题。

哈哈，博大精深确实不能够作为文档写的不好借口。
Spring boot 的文档是真的被人诟病，很多地方该写的不写，不该写的写一大堆。说实话这方面相比 js 那边是真的不太行。

就用 springboot 啊，难道 springboot 不好用吗

主业是 java 。做过好几个个人项目，刚开始用的 node ，后面尝试 go ，java 的 webflux 和 vertx ，然后是 rust ，被 rust 的理念和效率折服，后面项目中，主要是用 rust ，结果是各种东西都要自己整合，加上有些 rust 自身的机制要探索，开发效率下降，然后后面迭代维护，常用的中间件工具摸索，经常在这个上面花费时间。现在最新做的项目，还是老老实实用 springboot ，一切都是那么丝滑，缺点就是内存占用。或许是自己精力太分散了，导致另外几个技术栈，没达到丝滑的程度。

公司的没有选择只能 spring ，个人我都不用 java 了

其实算不上喜欢 spring ，但是 spring 真的很强大，极其的灵活可自定义的方式极多，也是行业最通用的框架，人才多，资料全。但是极其灵活和完善带来的副作用就是，这个框架也极其笨重庞大，要学透他是一件很麻烦的事情

好久没见过这么热闹讨论 Spring 系列的了。

作为 Java 开发工作后用过 Structs ，SpringMVC ，SpringBoot ，没有对比所以感觉也不知道好坏。

＃75 没有规定,你很棒

这话没问题，虽然没看过 php 的文档，但是比 js 那边差太多了。spring 最大的问题就是文档不行（不包含社区的那些文档记录哈，只说官方的）

还是看市场需求，脱离市场一切都只能由个人兴趣爱好来驱动。但是个人兴趣爱好又得有一个能让你持续保持热度的目标，比如做一个牛逼的项目，这个项目你可能还是想用来创造收益，兜兜转转还是到了市场需求这一步，只是看你在不在乎收益是否即时罢了。

还是写 Java 的时候，尝试过 Vertx Spark 还有一些其他的，大多数只能算是 toolkits ，在写稍微复杂点的项目的时候，完全做不到开箱即用，Spring 在 MVC 时代，除了性能不太行，我觉得没啥毛病，在业务迭代的过程中总是能够找到比较好的解决方案。 用 Webflux 也写了一些中大型项目，Reactive 还是太麻烦了，尤其是处理组合数据的时候，非常的繁琐，等到 VirtualThread 感觉会好点。

确实，springboot 主打的就是一个省心

VertX 太底层！不过，如果你正在寻找一个能够快速开发高性能 Web 应用的框架，那 Play Framework 是一个极佳的选择。它支持 Java 和 Scala ，好像是从 3.0 开始用 scala 重写底层的，采用异步模型处理请求，非常适合构建高并发的应用。内置热部署功能让你在开发时可以即时看到代码改动的效果，极大地提高了开发效率。同时，简洁的路由配置、强大的表单处理机制和内置模板引擎都使得开发变得更加直观和高效。对于想要构建 RESTful API 的开发者来说，Play 提供了流畅的支持和工具。

sbt new playframework/play-java-seed.g8

javalin 感觉也不错，小，没有太多的依赖

要论效率和舒适度的话, c＃(.net core)绝对要比任何语言都好

java 下还有得选?不都是 springboot

不喜欢，但如果我自己选我不会选 Java 。非要用的话可能会考虑 Javalin 、vertx 或者 Ktor 吧。

play!

www.playframework.com/

哈, 这个 scala 的框架吧, 很久以前用过

我们之前很多小项目或者比较轻量的项目用的 magicapi 。大概就是 js 语法但是能引入和使用 java 的类，函数的东西，语法也很简单，脚本语言，代码存在数据库或者存本地 resource 里都行

＃94 现在的 3.x 版本能用 Java 的，十分推荐。整体体验像 Rails

工作 springboot ，个人 go ，无它，服务器的钱不够上不起好机器

一个 springboot 项目运行吃 260m （-xms128m -xmx128m ，springboot 最新版，jdk21 ）
一个 springboot+jsp 项目运行吃 414m （ sb 最新版，jdk21 ，pod limits 512M ，还没来得及对它做 jvm 参数调优呢）
一个 go 项目运行吃 60m （ gin ，无内存限制，请求量远远大于上面两个 java 项目）

根据上面的结果，是你你选什么

单说 java 的话，springboot 几乎是无可替代的，也用过 ktor （自己写，感觉写起来怪怪的，更别说还有一些坑）和 Quarks （ keycloak 拉下来改过代码自己编译过，这东西感觉很强不输 sb ，就是国内不咋样，出问题要搜英文才能找到一些说明）

＃98 说白了，我感觉 springboot 适合公司不适合个人（不过你要是一个人全干，那实际上你相当于一个公司）

工作，哪里有选择？