轻松路线：
背八股文，优化简历 [吹牛] 。
这个学历和背景，大公司感觉没指望了，不是几年前了，华为 od 都卡 211 了。
中小公司不用算法，或者说是简单算法。

困难路线：
1 、考公
2 、学习英语，run 国外||找外企
3 、考研

@skyworker
时代在进步，各种业务场景的解决方案一直在摸索。

spring 是小，但使用起来不“美”，所以才有后来的 springboot
hibernate 和小应该不沾边，使用起来也不“美”。

微服务不会让系统变臃肿，乱用微服务、乱划分才是系统变臃肿的原因。

人的问题。

没人管，原开发人员用来练习简历技术栈。

请求超过 6s 都没人反馈，说明在这个公司或工作氛围中也不是问题

mq ，应该是消息队列吧，这能基于 mysql ？基于 mysql 实现的 mq 性能能看吗

无法理解服务架构。
1 、 大单体，又要部署多个实例，是否还在一台服务机器上？
2 、 多实例之间，数据库是否共享？不共享的话，使用 h2 ，sqlite 等内嵌数据库更方便
3 、 如果真的需要 mq ，离线部署一个 kafka+相关运维监控界面也不是什么费事的操作

选择使用什么技术，应该是基于需求、场景的。
但我在你的描述中，完全不知道你为什么需要 mq ，为什么要基于 mysql 的 mq 。

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. 修改验证状态

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