今天刷到 IntelliJ IDEA 2026.1 的更新页，第一反应不是兴奋，是松一口气。
更新日志年年都很长，真正能把人从重复劳动里捞出来的东西不多。对做 Java 和 Spring 的人来说，最折磨的无非三件事。分支切来切去把现场搞乱。配置不生效还得靠猜。查数据要在 IDE 和别的工具之间来回跳。
这次我只写三件事。Git worktrees。Spring Debugger。AI 帮忙查库但只读。剩下那些新特性，放在文末当参考就行。
先说 Git worktrees。
最常见的现场是这样。功能写到一半，线上突然报错要救火。以前的习惯是先把手头没提交的改动先收起来，用 git stash。再切到专门修线上问题的分支，大家一般叫 hotfix。修完合并回主线。再切回原分支，把改动放出来继续写。步骤不复杂。麻烦在反复切来切去，注意力一直被打断。越急越容易把现场弄乱。
worktrees 的思路更像给 hotfix 开一个独立工位。主线窗口不动，hotfix 在另一个目录里开工。修完合并，目录删掉，回到原来的现场继续写。这个变化不炫，但它把那种反复切分支带来的心智负担直接砍掉一大截。只要平时会遇到 hotfix，这个就值得先练熟。
Spring Debugger 先留一句提醒：配置不生效或注入不对，先在运行态确认当前 profile、最终配置值、以及实际注入的 Bean；细节后面单开一篇写。
最后说 AI 加数据库。
很多后端排查其实就两步。看日志。查数据。真正浪费时间的是工具切换。IDEA 看代码，另一个工具查库，再回 IDEA 验证，再去浏览器确认接口。来回跳久了，人会烦。
这块我只建议一个用法。让 AI 帮忙把 SQL 写出来，再由人执行，只读优先。它省的是手敲 SQL 和查字段含义的时间，不该拿来替人做数据修改。只要涉及更新语句，先停一下。生产库更别碰自动化修改。
为什么这三件事排在前面。
worktrees 解决的是开发里最高频的分支管理摩擦。收益直接，风险低，学完就能用。Spring Debugger 解决的是 Spring 项目里最难受的那类定位成本，它不帮你写代码，但帮你少走弯路。AI 查库属于锦上添花，做得好能省时间，做不好会带来边界问题，所以只读起步最稳。
信息来源放这里，免得正文像说明书。
IntelliJ IDEA 2026.1 更新页
IntelliJ IDEA 2026.1.1 发布说明
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/282569.html