原来不止我一个人。。。我还以为是 M5 芯片的问题，我发现删除缓存可以解决这个问题，大家遇到的可以一试将~/Library/Caches/下面的 idea 目录删除即可

确实该淘汰了，但是现在人脸识别因为有 AI 可信度都不够了很难找到一个更好的方案。

@chenjloveslife1 https://github.com/Aresxue/bean-copy-helper 提个 issue 给我，我周末有时间就支持掉。

1 、2 那几个项目你要是看完就够用了，如果你想更深入一点就需要了解 asm 和 jvm 指令了，感兴趣的话可以看下我这篇文章 https://blog.csdn.net/Ares_xb/article/details/145612950

云原生基本抹平了这个优势，非云环境下还有点用，不过现在也不知道非互联网的传统 IT 行业现在有多少非云环境，互联网云原生基本上是全覆盖了。但字节码依旧是非常优秀的一个设计，最重要的一个场景是性能优化，包括编译时做内联、逃逸分析、死代码消除、尾递归优化等等，还可以在运行时将热点字节码编译成本地机器码，以 HotSpot 为例，它是当前最成熟、最全面的生产级编译器之一，20 多年的工程积累是非常恐怖。除此之外，反射和元编程也是以字节码为基石的，是 Java 现在生态这么繁荣的一个重要原因，还有各种 Java agent 体现了零入侵的代码美学。

方法名叫 copyProperties 也可以，其它的话就是要精准匹配 org.springframework.beans.BeanUtils 、org.springframework.cglib.beans.BeanCopier 、org.apache.commons.beanutils.BeanUtils 、cn.hutool.core.bean.BeanUtil 这几个了。

@AceCandy 这种会对原有的引用关系有污染，所以考虑了一下暂时没有做，后续有时间会实现掉同时会新增一个开关来控制这个行为，你如果感兴趣的话可以 https://github.com/Aresxue/bean-copy-helper fork 一下贡献个 PR 或者自己按照自己的喜好随意修改。

@PeiXyJ 是指哪个？我看之前的插件基本上没有可以支持 Fing Usages 的所以才自己撸了一个

2025 年了还有这种讨论，当真是印证了历史发展总是螺旋式上升的这句话。

微服务在大公司是必需品，至于中小公司用不用微服务的标准是能否玩的明白，然后实际中大部分人和公司确实玩不明白，确实难绷。

@CodeCaster 瞄了一眼貌似你们的框架主要还是面向 AI 的，你们这个方案在传统工程领域可能没那么适用，因为你们解决的只是运行时问题，微服务还有很多其它的问题，比如代码仓库，除了 google 喜欢且有能力玩好 monorepo ，其它的主流公司还是 Multirepo 模式。如果只是为了解决运行时问题，SofaBoot 的模块化开发和 SOFAArk 等方案也都相对成熟了，甚至更极端些直接用 Faas 好了。

感谢 DeepSeek-R1 和 GPT 4o ，以下为当前页面的总结
### **中划线（-）**

**优点**

1. **视觉友好**
- 无驼峰大小写混淆（如 **`i`** 和 **`l`** 视觉近似问题）
- 空格替代感强，单词分隔清晰（**`get-list`** vs **`get_list`**）
2. **技术兼容性**
- 与域名规范一致（域名不支持下划线）
- 避免 HTTP 协议中路径大小写敏感问题（全小写统一）
- 符合 Google SEO 推荐（[**官方文档**]( https://developers.google.com/search/docs/crawling-indexing/url-structure)），传统网站和 SEO 实践中，多推荐使用中划线
3. **输入便捷性**
- 无需切换大小写，打字效率更高
- 符合传统网站习惯（如 **`about-us`**、**`contact-info`**

**缺点**

1. **前端工具兼容性**
- 使用 **`-`** 分割路径可能导致 TS 模型生成工具解析困难（需额外配置）
- 某些自动生成的 API 工具不便生成含中划线的路径
2. **复制粘贴体验**
- 在某些编辑器中，双击选中时，中划线可能被切断（依赖编辑器配置修正），导致不易选中整个字符串。

### **下划线（`_`）**

**优点**

1. **开发工具友好**
- 双击复制时，下划线会被整体选中（无需配置编辑器）
- 与部分编程风格（如 Python 的 **`snake_case`**）一致
2. **规避大小写问题**
- 全小写下划线无大小写敏感风险

**缺点**

1. **视觉与功能性争议**
- 下划线在长 URL 中与空格区分度低（如 **`get_list`** vs **`getlist`**），可能与空格混淆
- 域名不支持下划线，路径中混用可能引发混淆
2. **服务器配置风险**
- Nginx 等服务器默认不支持 URL 中的下划线（需手动启用）

### **驼峰**

**优点**

1. **开发友好性**
- 与后端代码风格（如 Java 的驼峰命名）高度一致
- 节省字符长度（如 **`getList`** vs **`get-list`**）

**缺点**

1. **用户体验风险**
- 手动输入易混淆（如 **`i`** vs **`L`**）
- 部分客户端可能自动转全小写导致 404
- **输入不便**：需要在输入时切换大小写，使用上稍显麻烦
2. **协议兼容性问题**
- HTTP 路径大小写敏感，需严格匹配（前端/运维易出错）

总的来说，选择哪种格式需考虑具体应用场景的约束和需求，如 SEO 友好性、开发工具兼容性、团队编码规范等。中划线在较多场合被优选，尤其是在 SEO 和 URL 命名中。

java 的 orm 是个月经贴了，但说实话现存的 orm 都不好用，在当前的 JVM 设计下也很难看到曙光，这才是 mybatis 还能苟延残喘的原因， 作为第四代编程语言的 sql 在数据处理这个领域语法的简洁性超过 java 这个三代语言太多了，甚至可以说 sql 语法的易用性、简洁性超出了绝大多数编程语言，在这个背景下用编程语言代替 sql 只会带来更多的工作量，而 orm 的优势（数据库适配性、可维护性）等等很难打动用户。

@4ra1n 这里其实还有个更安全的方式，把 arthas 源码搞下来，然后自己开发一个新的 command ，可以直接复用 arthas 的 sc 指令( sc *)，然后自己做 class->jar 文件的计数处理即可，这样可以使用 attach 模式而不是 premain ，对业务更安全影响也更小。

这个诉求没这么复杂，java agent 把 instrumentation 的引用保存起来就行了，然后放线上去接受真实流量，跑个一天或者手动触发业务操作，再把某台容器从注册中心剔除掉，到这台容器上调用 http 接口，接口里面用 java.lang.instrument.Instrumentation#getAllLoadedClasses 获取所有的 class ，然后对 class 所在 jar 包去重就行了

分本地还是线上，本地环境 3 楼的策略你能搞完绝对够用了，线上环境就要复杂的多了，maven 本身就有一些调优参数。

不用就行了，说实话对开源来说这个算是屁大点事，Linus 以前还天天 fuck NVIDIA 呢。
不过这框架我还真用过，语法思路问题不大（抄的 mybatis-plus ），但是明显作者技术功力不到家，对底层序列化还有很多地方的处理都有 bug ，另外和 spring-data-elasticsearch 的互兼容性做的比较差，导致最后还是弃用了，我想要的其实更多的还是一个基于 spring-data-elasticsearch 的语法糖框架，毕竟 spring-data-elasticsearch 的扩展和细节处理已经有很多年的积累了。

Controller -> Mapper -> Service ，外部定义越早越好，对接的前端和其它三方可以直接查看 Controller 申成的接口文档，Mapper 其实主要指的是底层模型，这块是需要和老板/产品达成一致的，Service 指的是内部服务一般来说调整更自由，不管是改名字还是职责还是拆分都好说一些。

Copilot 体感最好，但我日常办公是天然和外网联通的，而且网速非常流畅，而且使用的公司购买的 Copilot 付费版本。

1.一般是对外的接口层（ http 、rpc 、mq ）是需要一定避免 Map 的，内部方法合理即可不需要一定避免；
2.针对你这个 case 非要搞可以搞个 List<xxxCount>对象，意义聊胜于无，从性能来说 Map 还更好些。