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 还更好些。

属于滥用拦截器了，这个场景写个 Adapter 就解决了，addToken 方法里面肯定还有 json 序列化和反序列化的开销，Adapter 设计合理点还能把这部分开销优化掉。

你这个就适合 go ，确实不适合 java ，但和 java 也确实没啥关系了

这还告诉我们写代码的不要无脑 copy ，应该要按需引入相应的功能。“若无必要，勿增实体”，做到这一点会少踩很多坑。

@liubsyy 我的意思是你的发布物是什么样的，原先不依赖的新三方库我理解就是导出一个新的 jar 包就叫它 newbiz.jar 好了，把这个 jar 包在容器里面替换掉原有的 biz.jar 然后重启 java 进程就生效了，新依赖三方包的话新的三方包你是会直接打到 newbiz.jar 中还是说是分开的，除了替换原有的 biz.jar 以外还需要再上传一个 third.jar ，值得注意的是这个 third.jar 可能以前已经有低版本的了这里再引入一个会面临业务里面会遇到的钻石依赖问题。

蛮不错的插件，就是编译可以再扩充一些，一个是可以指定电脑本地的其它 jdk ，甚至一些三方的反编译和编译库像 cfr 、Procyon;另一个是我没看到对三方库的处理，指原不在我当前应用中的三方包但我本次修改需要使用的三方库，这块处理也确实会比较麻烦但在这个魔改 jar 的场景里面出现的概率却并不低。

好好坏坏总归是自己的选择，但妈妈要更可怜一些，如果就这一个孩子以后只能一个人孤零零地走向生命的终点。

1.xml 可读性主要是不够简洁，版本管理和子模块管理这俩本来就没有分开的必要，gav 一共就三个维度；
2.使用姿势有问题，把 revision 和 relativePath 玩明白就好了；
3.还是姿势问题；
4.了解下阿里的 amaven 还有开源的 maven daemon ；

@Dongxiaohao 代码不多的话加个注解也是个蛮简单的方式，要是想作为一个可以面向几十个应用的功能就可以像我说的做个二方包在里面写一些路由逻辑，这个东西的好处就是对 sql 语法没有任何要求，需要注意的是潜在的事务问题（跨数据源），你使用时注意点。