webflux ，使用起来挺麻烦的，各种 mono flux ，mybatis 应该也没有适配。
现在追求性能 [吞吐量] 和开发效率的话，使用 springboot3+jdk21 就好了。
性能比 webflux （基于 netty)实现的，差距在 10%左右吧。

如果是 http 协议等常用协议 的话，使用 webflux 没问题的，长连接那是基础功能

什么业务场景？
web 路由的话，知道的就 webflux

-- 有啥好的建议可以用上这个主机
这个电脑是给你用的吗？

-- 不习惯 windows 开发
这个电脑配置比你那个老古董 mac 好太多了。
你要是为了 mac 习惯，也觉得够用的话，保持就好。
想用上这个好配置的电脑，熟悉下 windows 操作习惯就好，有什么 mac 有的操作，win 下没有就搜索。

@kuanat
1 、我不推荐你说上下游，这个东西是有歧义的。
2 、我熟悉 Java ， 所以我反驳你用错误的方案（ code ）做示例，这没问题吧。
3 、我遇到的业务场景都是上游提供接口|接口依赖包的，你的上游是什么我就不知道了。

你写的挺多的，但我真不知道你想说什么。
你的案例，我是真看不懂 Java 有什么不能实现的？
我也不明白为什么 go 的话题下，你要引用 Java 干嘛。

你的意思是调用方先定义接口， 服务方根据接口去实现？
这个只是 maven 中 接口包 谁提供的权责问题。

这个话题讨论的是 goland 为什么提倡使用接口。
我个人理解：
接口设计涉及的原则，都是为了方便后续维护（可拓展、阅读性等），这些是设计模式的内容，是等你无意中使用后，体验到了其好处之后才会有深刻体验的，你才会明白什么场景中使用比较合适，写个 hello world 都用这些东西的话，就是脱裤子放屁

所有的设计模式，都是有适用场景的。
在写类库，框架之类的场景中，使用设计模式，会更方便阅读、拓展性更好，更容易维护。
在写简单 curd 业务代码的场景中， 由于这些代码基本不会拓展，复用 [可以在变复杂，需要复用时，再使用设计模式相关写法] ，使用设计模式就没啥用，写接口可能也就是方便做单元测试，切面相关的操作了。

golang 提倡使用 接口 ？ 这个是不是真的？保留疑问。

@kuanat
当你不熟悉其它语言（ Java ）时，就不要硬扯在一起了。
1 、Java 的类型是在变量前面的
2 、Java 对于接口的实现，做兼容升级或变更时，通常是修改 maven 的 pom.xml 中依赖包的版本号就好了。

下游（服务|接口调用方）不用关注接口实现的变动点，一般是上游（服务|接口提供方）通知变更，下游再在 pom.xml 中修改依赖包的版本号即可

要 ”资深技术专家“ 承认错误，很难的啦
你在公众面前打他脸啊

只听你的描述：
1 、 你没了解前辈的需求背景，业务逻辑 [看不懂代码||看不惯代码风格] ，就吐槽代码为“屎山”
2 、 你的前辈使用了 TS 和封装，你觉得繁琐，评价为“屎”

给我的感觉，你的前辈在做工程化的项目，你在“短平快”地糊屎。
你觉得你比你前辈优秀，可以贴代码||方案出来，看看别人是否赞同你

感觉 rust 才是真正的 better c .
支持大佬使用 rust 重构中间件，确实能起到节省内存效果。

dao 层的作用:
1. 方便后续做多数据源管理，读写分离等拓展操作
2. 后续切换 orm ，修改比较方便
3. 工程化，谁接手都知道查询数据库要通过 dao 对象

问题有点多。个人理解(不一定正确)
1. 业务逻辑就是需求实现逻辑，参考业务流程图。非业务逻辑，没听过，感觉是非功能需求，如要求响应时间，吞吐量，可靠性等

1.1 manager 层主要是
1. 把多个 service 循环依赖才能实现的方法下沉到 manager 对象中，避免循环依赖
2. 管理可复用资源，如 cacheManager ，transationManager 。。。

1.2 推荐在 service 层加密，dao 层主要做发送 sql 到数据库操作

1.3 支持方法重载就不推荐加 by_xx ，参数多就封装为一个查询对象

1.4 不写 python ，没懂

2. 没有 spring ，JAVA servlet 实现 filter 功能也很简单，继承 Filter ，配置类到 web.xml 就可以了

3. 数据实体？指 entity ？理解是一个数据库表对应的一个类。controller：service 是一对多，service:dao 是一对多。如 userservice 中注入 userdao, accountdao,

现在还能个人开发游戏赚钱的，只能说佩服。

我实际开发中的处理:
1. 上传文件后，在业务表中插入一条待验证记录，响应上传成功
2. 定时读取待验证记录，流式读文件，逐行检验，在单元格内用[]记录验证失败原因，输出到新文件。有异常则上传新文件。
3. 修改验证状态

整体就是加个用户上传记录，后台异步检验的思路。
如果是对接服务端的，追求实时性，还可以主动回调/推送检验结果

非法控制计算机信息系统程序罪

这个得了解下，什么时候犯了都不知道= =

ant ，maven 都深度使用过。
gradle 简单使用过。

体验最好的是 maven
单体项目就 maven + linux shell 脚本
微服务项目是 maven+docker+jenkins 。

两个推荐解决方案
1. 基于 camunda 做二次开发，表单相关业务前端维护，工作流引擎只负责流程设计和流程流转。自己封装下，提供几个核心 api 就可以了。

2. 如果要在线表单设计功能，推荐购买现成 oa 公司的服务。
表单设计，和流程绑定，表单权限，流程回退，预览审批人，多维度组合审批权限等功能，自己研发时间周期太长了，不切实际。

对一个东西不懂时，最好保持谦虚学习态度。

python 类库底层怎么处理的你不看
PBKDF 定义你不看
jdk 的类库你不研究

ai 翻译的不合你的"以为"，你又要喷。
通篇下来就凸显浮躁和无脑，没有现成类库喂饭到嘴就啥也不是。