足足踩了两次坑
第一次：
可以看到fixedincome引的三个包被干掉两个
提交方式为IDEA的"推送并提交"
第二次
也就是说如果是通配符导入，大于5个的导入会被合并，小于5个的导入会被拆分为多个单导入
看下主要变更部分：
:::info 首先怀疑是通配符退化，但是根据idea的auto import配置（前图）
根据退化逻辑，假设是退化通配没有生成对应的子类导入
那么看到architecture4FR.*不应该发生退化（大于5），实际上按假设会退化，所以这种推断不成立
:::
:::info 再回顾第一次踩坑，发现毫无头绪，第一次未发生任何退化现象
再次猜测：由于第二次是刚拉的分支，有一些包没有引入
由于在cherry-pick代码的时候也进行了Optimizing Imports
所以可能是编译器没认识到哪些是被引入不该移除掉的，（虽然爆红了但是只是因为没打包）
所以会把部分爆红带*的直接移除掉（大于5的），小于5的进行退化，mgobjects.*的正常退化也能印证
mapper.*没去除是因为其所在包打了，所以打包和index就是息息相关的，包都引不到，索引更是有问题
:::
上面一种猜测最适合第二次踩坑
那么第一次呢，也是因为basis等枚举存在爆红吗？而且第一次提交也不是cp的，而是直接通过下图优化提交的
而且看basis枚举几年都未动过且就在本工程，所以只能猜测是index索引或缓存出现了问题
只能推测第一次：
（文件代码行过多/电脑性能低，文件没有索引完全（高亮都很慢），认为其无引用·）让其自动删除了
而且由于文件过大，去掉import不滚动到具体的引用位置，编译器也很难做出爆红反应
总结，不建议在提交时同时优化导入，每次提交后都打包比较麻烦（主要是因为可能其他人有各种dev未打包情况，只改动一小部分代码却要打全，全包打不出来）
一旦大文件，提交时显示优化导入ing几秒以上，一般就是存在错误导入了
建议：
在提交之前手动优化-打包，并且此时如果存在部分爆红代码，一定检查是否对import做出了不该做的优化，避免改到别人的代码
提交时不选择任何–格式化—优化导入 工具方法
deepseek总结最可能的情况
有时候，如果使用了静态导入或者通配符（如import package.*;），IDE可能无法正确识别其中某些类的使用，导致误删。例如，如果使用了通配符导入多个类，但实际代码中只显式使用了部分，IDE可能会建议移除整个通配符导入，而用户可能依赖其他未明确引用的类，比如通过反射或动态加载的情况。
注解处理器或框架特定的导入：某些框架（如Lombok的@Slf4j）会在编译时生成代码，这些导入可能在源代码中没有直接使用，但在编译后会变得必要。IDE在静态分析时可能无法检测到这些情况，从而错误地移除相关导入
IDE配置问题：可能用户的IDE配置中，“Optimizing Imports”设置过于激进，比如设置为总是移除未使用的导入，而没有排除某些特定的包或模式。例如，某些测试框架的注解可能在测试代码中是必要的，但如果没有正确配置作用域，可能会被误删。
IDE缓存或索引问题：有时候IDE的缓存可能出现问题，导致其未能正确索引到某些类的使用，从而错误地移除导入。这种情况下，清理缓存或重新构建索引可能会解决问题。
做个小实验：删掉仓库jar后刷mvn
代码没去import
通配符退化（按不确定规则）
如果别的包没有不同路径同名类，估计通配符的直接去掉了，idea认为其没有引用，只有非通配符形式的才会爆红保留
什么archit相关的jar都去掉，点进代码让其index一下
可以看到由于通配类型没有具体的引用类，显示灰色未引用的（其实是引用的地方都红了，编译器当然认为其未被引用）
不像CurrenyLogic一样即使没有但是代码中有引用，此时是智能保留的，此时优化导入：
发现确实都没了，回滚，从cherry-pick复现：
发现其实对于*的，如果编译器发现没引用，即使没有勾选import，commit也会将通配符未使用进行去除
而提交之后缺少包才爆红的*引用，cherry-pick分为检查+commit，检查会将其看作无冲突，然后commit会去除,所以导致import问题*
SO
禁止在大量红时提交代码，尤其是大文件不确定原有import的情况
硬提交必须检查import变更，尤其是带的，因为不带也要提防index错误情况
如果您喜欢此博客或发现它对您有用，则欢迎对此发表评论。 也欢迎您共享此博客，以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权，请与作者联系以将其删除。 谢谢 ！