写Builder代码这事，听起来简单，真做起来能烦死人。尤其是项目里实体类一多，字段二三十个起步，每个类都得配一个静态内部Builder，方法一个接一个写，命名稍有出入，调用方就得跟着改。后来我干脆抽了个时间，在IntelliJ IDEA里写了个插件“Builder Generator”，选中类一键生成完整Builder代码。这篇文章就把这个插件的开发全过程拆开讲清楚：入口怎么设计、代码怎么生成、哪些边界情况容易翻车，以及我自己踩过的几个坑。想自己动手写IDEA插件，或者只是好奇这种代码生成工具内部原理的，都可以接着往下看。
1. 项目概述与整体设计思路拆解
1.1 为什么是Builder模式，为什么需要自动化
先聊聊Builder模式的实际使用场景。很多开发者对Builder的印象停留在“解决构造函数参数过多”这个问题上，但真正用过之后会发现，它更大的价值在于命名清晰和调用链顺滑。比如一个订单查询对象，可能有订单号、用户ID、状态、时间范围、分页信息等十几个可选条件，用构造函数一个个传参，调用方要记住参数顺序，阅读代码的人也要来回核对；用Builder之后，QueryBuilder.orderId("xxx").status(1).page(1, 10).build()这种写法，参数和含义是一一对应的，读代码基本不用来回跳。
不过，Builder模式在Java里的实现代码非常固定，大体就是三块：静态内部类、与字段一一对应的链式方法、build()方法里调用外部类的私有构造方法。既然结构如此固定，那手工写就是纯粹的重复劳动。而且一旦实体类字段变动，Builder里的方法也得同步增删，非常容易漏改。这种场景天然适合用代码生成工具来替代手工劳动，这也是我做这个插件的直接动机。
1.2 插件功能定位与技术准入点分析
做IDE插件第一步要想清楚：用户是怎么触发这个功能的？是右键菜单、快捷键，还是写代码过程中自动弹出提示？这三种方式在IntelliJ平台里对应不同的扩展点，使用体验差异也很大。
我对比过三种常见方案的适配场景：
- Live Template（实时模板）：适合在代码编辑区里敲几个字母就展开一段模板代码，灵活性高，但要让模板感知当前类的字段，得写很复杂的Groovy脚本，可维护性比较差。
- Intention Action（意图操作）：在光标的上下文里弹出一个灯泡图标，提示“Generate Builder”，交互很优雅，但开发时调试比较复杂，意图动作的上下文检测逻辑要自己写得非常准确，否则该出现的时候不出现，不该出现的时候乱出现。
- 自定义Action + 右键菜单：在工程树或编辑器里右键点击一个类，直接触发生成，逻辑清晰、入口稳定，对代码上下文的检测压力小。
我最终选了自定义Action的方案。原因很简单：生成Builder这个操作，本质上是“对一个完整的类做批量改写”，不是“在光标处插一段代码”。右键入口意味着用户先在工程树里选中类，或者在编辑器里打开类文件，然后明确告诉插件“我要给这个类生成Builder”，整个交互是确定性的、可预期的，不容易产生误触发。对工具类插件来说，稳定和可控比交互的酷炫更重要。
1.3 插件整体架构布局
整个插件的运行时逻辑分成四层，各层职责明确：
- 入口层：负责把用户的操作意图变为一个标准的生成请求，包括从右键菜单事件里提取目标类的PsiClass对象。
- 分析层：读取类的字段信息、泛型参数、父类关系、注解数据，整理成一份结构化的字段清单。
- 生成层：根据字段清单和用户选择的配置选项，用PsiElementFactory拼接出Builder内部类的完整代码结构。
- 写入层：把生成的PSI元素插入到目标类的指定位置，并触发格式化，保证代码风格与IDEA当前配置一致。
这样分层之后，后期扩展很方便。比如以后想支持Kotlin的data class，只需要在分析层额外写一个Kotlin的字段读取器，生成层可以通过抽象接口输出不同语言的代码，写入层几乎不用改。下面的章节我就按从工程搭建到核心实现再到问题排查的顺序来详细讲。
2. 插件工程搭建与基础骨架实现
2.1 开发环境和Gradle工程配置
IntelliJ插件开发现在主流的工程组织方式是Gradle + IntelliJ Platform Plugin，手动建工程目录的时代早就过去了。插件市场里提供的脚手架模板可以直接生成完整的gradle配置，但自己新建一个也很快。
最核心的构建配置是build.gradle里的插件声明：
plugins { id 'java' id 'org.jetbrains.intellij' version '1.15.0' } group = 'com.example' version = '1.0.0' repositories { mavenCentral() } dependencies { implementation 'org.jetbrains:annotations:24.0.1' } intellij { version.set('2023.2') type.set('IC') plugins.set(['com.intellij.java']) } patchPluginXml { sinceBuild.set('232') untilBuild.set('241.*') }这里有几个容易踩的坑。intellij.version决定了你开发时用的SDK版本，但它也是运行时兼容性的一个重要参考。如果你把版本设得太新，而用户还在用旧版IDEA，插件会直接提示不兼容；设得太旧，又可能用不上新版本的PSI API。sinceBuild和untilBuild就是控制兼容窗口的，我一般会把窗口放宽到当前大版本的后两三个小版本，给用户留出升级空间。
plugins.set(['com.intellij.java'])这行很容易漏。Java语言支持的PSI解析相关类库是独立于IDEA核心的，不声明这个插件依赖，PsiClass的很多方法会直接抛异常，而且是在运行时才暴露出来。开发期编译不会报错，这点特别坑。
2.2 plugin.xml：插件的“身份证”与扩展点注册
src/main/resources/META-INF/plugin.xml是每个IntelliJ插件都必须有的描述文件。它声明了插件的基本信息，比如ID、名称、版本、供应商，更重要的是声明了插件用到了哪些扩展点和Action。
<idea-plugin> <id>com.example.builder.generator</id> <name>Builder Generator</name> <vendor>example</vendor> <description><![CDATA[ Generate Builder pattern code for Java classes with one click. ]]></description> <depends>com.intellij.modules.platform</depends> <depends>com.intellij.modules.java</depends> <extensions defaultExtensionNs="com.intellij"> <!-- 扩展点可以之后在这里注册 --> </extensions> <actions> <action id="BuilderGenerator.GenerateBuilderAction" class="com.example.buildergenerator.actions.GenerateBuilderAction" text="Generate Builder Pattern" description="Generate Builder pattern code for the selected class"> <add-to-group group-id="GenerateGroup" anchor="last"/> </action> </actions> </idea-plugin>重点说<add-to-group group-id="GenerateGroup"/>。IDEA的Alt+Insert菜单就是GenerateGroup，这是绝大多数Java开发者最熟悉的面板之一。把生成Builder的入口放在这里，用户视觉上很容易发现，而且和IDEA自带的“Generate Getter/Setter”“Generate Constructor”等操作放在同一级，语义上高度一致。用惯了IDEA默认生成功能的用户，几乎不需要学习成本就能找到这个功能。
2.3 Action入口：拿到用户选中的那个类
Action的Java/Kotlin类需要继承AnAction，核心方法是actionPerformed和update。前者是真正执行生成的入口，后者是控制菜单项是否可用的关键。
import com.intellij.openapi.actionSystem.AnAction import com.intellij.openapi.actionSystem.AnActionEvent import com.intellij.openapi.actionSystem.CommonDataKeys import com.intellij.psi.PsiClass import com.intellij.psi.util.PsiUtilBase class GenerateBuilderAction : AnAction() { override fun update(e: AnActionEvent) { val file = e.getData(CommonDataKeys.PSI_FILE) val editor = e.getData(CommonDataKeys.EDITOR) val psiClass = findTargetClass(file, editor) e.presentation.isEnabledAndVisible = psiClass != null } override fun actionPerformed(e: AnActionEvent) { val file = e.getData(CommonDataKeys.PSI_FILE) val editor = e.getData(CommonDataKeys.EDITOR) val psiClass = findTargetClass(file, editor) ?: return BuilderGeneratorService.generate(psiClass) } private fun findTargetClass(file: PsiFile?, editor: Editor?): PsiClass? { if (file == null) return null val offset = editor?.caretModel?.offset ?: 0 val element = file.findElementAt(offset) var current: PsiElement? = element while (current != null) { if (current is PsiClass) return current current = current.parent } // 在工程树中选中文件时，取文件里第一个类作为默认目标 return PsiUtilBase.getPsiFile(editor)?.classes?.firstOrNull() } }update方法里的逻辑值得细讲。这里的关键是，findTargetClass返回null时把菜单置为灰色不可用状态。这样用户在接口、枚举、抽象类上右键时，菜单虽然可见但是点不动，体验上比直接消失要好——因为用户能感知到“这个操作存在，只是当前场景不适用”。另外，从光标位置向上找父级PsiClass的逻辑，保证了用户即使把光标放在类名、方法体、字段上，都能正确识别出所属的类。
3. 核心生成逻辑：从字段清单到完整Builder代码
3.1 分析阶段：读取目标类的字段与构造方法
生成Builder的第一步，是把目标类里的有用信息提取出来。我定义了一个中间数据结构，专门承载生成所需的全部信息，避免下游代码直接依赖PSI对象，方便后续单元测试。
data class BuilderField( val name: String, val type: String, val typeParameters: List<String>, val annotations: List<String>, val isFinal: Boolean ) data class BuilderClassInfo( val className: String, val packageName: String, val fields: List<BuilderField>, val constructorParameters: List<BuilderField>, val hasDefaultConstructor: Boolean )从PsiClass里提取字段的核心逻辑：
fun analyzeClass(psiClass: PsiClass): BuilderClassInfo { val fields = psiClass.fields .filter { !it.hasModifierProperty(PsiModifier.STATIC) && !it.hasModifierProperty(PsiModifier.TRANSIENT) } .map { field -> BuilderField( name = field.name ?: "", type = field.type.canonicalText, typeParameters = extractTypeParameters(field.type), annotations = field.annotations.map { it.text }, isFinal = field.hasModifierProperty(PsiModifier.FINAL) ) } // ... }这里有一个设计取舍：静态字段要不要生成到Builder里？我的答案默认是排除。因为静态字段通常属于类本身，和对象实例的状态无关，放进Builder里会让build()方法的行为变得诡异。transient字段排除则是考虑到序列化场景——瞬态字段往往是缓存或者临时状态，不参与业务初始化。
类型参数的提取也要细心。比如字段声明为List<String>，在生成Builder方法时，不能原样用List<String>作为返回类型，而应该保留泛型信息，让IDEA在格式化时可以正确推断导入。我在extractTypeParameters里通过PsiType.getTypeParameters()拿到泛型数组，拼成完整的类型字符串。
3.2 生成阶段：用PsiElementFactory拼接代码结构
IDEA插件开发中改动代码从来不是“写字符串然后替换文件”，而是借助PsiElementFactory创建结构化的PSI元素，再插入到对应的PSI树节点中。这样做的最大好处是，IDEA能自动维护代码的语法正确性，而且后续的格式化、import补全都能正常工作。
class BuilderGeneratorService { companion object { private fun getFactory(psiClass: PsiClass): PsiElementFactory = JavaPsiFacade.getInstance(psiClass.project).elementFactory fun generate(psiClass: PsiClass) { val info = analyzeClass(psiClass) val factory = getFactory(psiClass) // 生成静态内部类的完整代码文本 val builderClassText = buildBuilderClassText(info) val builderClass = factory.createClassFromText(builderClassText, psiClass) // 在目标类的内部类列表尾部插入 val added = psiClass.add(builderClass) // 确保新插入的代码格式符合当前项目风格 CodeStyleManager.getInstance(psiClass.project) .reformat(added) } } }这里的关键方法是buildBuilderClassText，它把分析阶段得到的字段清单组合成一段合法的Java类代码字符串。举个例子，对一个包含String name和int age两个字段的类，生成的内部类文本大致如下：
public static final class Builder { private String name; private int age; public Builder() { } public Builder name(String name) { this.name = name; return this; } public Builder age(int age) { this.age = age; return this; } public TargetClass build() { return new TargetClass(name, age); } }这里有一个很重要的细节：createClassFromText创建的类是一个独立、零散的PSI节点，它还没有父节点。把它add到目标类之后，IDEA会自动建立父子关系，但此时新代码的缩进和换行风格可能和原文件不一致，所以必须调用reformat，让IDEA按照当前的代码风格规范重新排版。
3.3 选择构造策略：字段优先还是局部变量优先
生成Builder时，build()方法怎么调用目标类的构造方法，是一个需要权衡的问题。目标类的构造方法可能有三种情况：
- 有全参构造方法：直接用
new TargetClass(name, age)，Builder里的字段按顺序传入。 - 有无参构造方法，字段都有
setter：可以先new TargetClass()，再逐个set字段。 - 只有默认构造方法，字段是
private且没有setter：这在Java类里很常见，此时必须在生成Builder的同时，给目标类补一个全参构造方法，或者利用反射——但反射在生成代码里基本不可接受。
我的插件默认策略是第一种：优先尝试使用全参构造方法，如果目标类不存在全参构造方法，则在生成Builder之前询问用户是否同时生成一个全参构造方法。这个操作的PSI实现是检查psiClass.constructors列表，如果没有和一个字段列表匹配的构造方法，就用generateConstructor生成一个新的构造方法并插入到类中。
3.4 生成过程中的格式化与导入处理
代码生成完成之后，还有一个容易被忽略的问题：类型导入。如果一个字段类型是java.time.LocalDateTime，但目标类文件里没有import这个包，生成后的代码会直接写出全限定名，可读性很差。
CodeStyleManager.reformat能解决格式化问题，但不会自动补全import。要处理import，得用JavaCodeStyleManager的shortenClassReferences方法：
JavaCodeStyleManager.getInstance(project) .shortenClassReferences(added)这个方法会把全限定名替换为目标类中已有的import或自动补全的短类名。实测下来，它对常见泛型类型、嵌套类、内部类的处理都比较稳定，但偶尔会有一些奇怪的边界情况，后面我在问题排查章节会细讲。
4. 进阶功能与边界情况处理
4.1 支持继承关系：子类生成Builder时父类字段怎么办
Java继承体系下，生成Builder会遇到一个经典问题：子类的Builder应该包含父类的字段吗？
直觉上，子类Builder未来是要build()出子类对象的，如果父类有必填字段，不传就构建不出来。但直接把父类字段复制到子类Builder里，又会造成字段重复定义的问题——父类Builder里还有一套同名字段，两个Builder如果都能设置同一个字段，调用方反而会困惑。
我采用的策略是：默认不复制父类字段，而是在子类Builder的build()方法中，优先调用父类的全参构造方法，让父类字段由父类的Builder去设置。也就是说，子类生成的是childBuilder，父类生成的是parentBuilder，调用方可以串联使用：
new Child.Builder() .parentField("父类字段") .childField("子类字段") .build();具体实现上，在分析阶段检测到psiClass.superClass不为null时，我会额外记录父类字段清单，并把它们合并到Builder类的字段中——但标记为“fromParent=true”。生成build()方法时，优先调用父类构造方法，把父类字段传入父类构造器，子类字段则通过子类构造器传入。这个逻辑在绝大多数项目里是合理的，因为Java的单继承决定了父类构造函数链非常清晰。
如果用户明确不希望继承父类字段，我也提供了一个选项“忽略父类字段”。此时生成的Builder只包含子类自己声明的字段，build()方法也只调用子类的无参构造方法，父类字段由调用方在后续自己设置，或者IDE的代码检查会给出提示。这个选项的优先级，我做得比较高，只要用户勾选了，分析阶段就会直接跳过父类字段扫描。
4.2 泛型类型与嵌套类的正确生成姿势
泛型是生成代码时最容易翻车的点。下面这个场景很常见：
public class PageResult<T> { private List<T> data; private int total; }如果直接按T去生成Builder方法，public Builder data(List<T> data)这种代码在Java里其实是合法的，因为T在类的泛型上下文里是可解析的。但问题出在内部类：静态内部类不继承外部类的泛型上下文，所以data(List<T> data)写在静态内部类里会直接编译失败。这提醒我必须把泛型变量绑定到内部类本身上。
我的生成策略是：检测目标类的泛型参数列表，如果非空，则将泛型声明也复制到Builder内部类上，并在Builder方法签名里保留泛型参数：
public static final class Builder<T> { private List<T> data; private int total; public Builder<T> data(List<T> data) { this.data = data; return this; } }实际操作中，这个改动的难点在于从PsiClass.getTypeParameters()取出泛型声明后，如何正确拼接到Builder类的声明字符串里。我的经验是不要手写泛型声明字符串，而是直接用typeParameter.getText()，把原始文本原样复制到Builder类的声明处。这样能保证泛型边界（比如<T extends Comparable<T>>）不丢失。
嵌套类的处理也有一个反直觉的坑：如果目标类是一个内部类（非静态），它的构造函数天然持有外部类实例的引用。此时生成的Builder如果直接调用new InnerClass(...)，在静态上下文中是无法编译的。解决办法是：检测到这种嵌套关系时，自动把Builder类变成非静态内部类，并在Builder的成员变量里持有外部类实例的引用。这样build()方法生成new InnerClass(outerInstance, field1, field2)。这块逻辑我在实现时花了最多时间去验证，各种组合情况太容易漏。
4.3 注解与字段默认值的兼容处理
实际项目里，实体类字段上往往会带一些注解，比如@NotNull、@JsonProperty("user_name")、@TableField("user_name")。这些注解应该在Builder内部类的对应字段上保留吗？
我的经验是：对于运行时需要的注解，比如@NotNull这种校验类注解，保留到Builder字段上能帮助调用方在构建阶段就收到IDE警告，价值很大；但对于序列化注解，比如@JsonProperty，放到Builder字段上没有任何意义，因为Builder不是序列化目标，留着反而让生成的代码信息熵太高。
处理策略：只复制运行时可见的注解，剔除标记为SOURCE保留策略的注解。PSI层面，可以通过annotationQualifiedName匹配注解类名，再通过PsiAnnotationOwner的属性判断保留策略。实测中这个过滤规则能覆盖大多数场景，但如果是混合注解，比如既有@JsonProperty又有@NotNull，还是会有取舍的讨论空间。
默认值的处理就简单多了。字段声明里有显式初始值，比如private int pageSize = 20;，那么Builder内部类的字段也应该带上这个初始值，这样用户在显式设置之前，字段就已经有了业务默认值，不会因为构建时漏传某个参数而出现空值。
4.4 对已有Builder的处理策略与重复生成防护
这个场景我最初没想到，直到一个用户反馈说“我只想加一个新字段，结果重复生成了一个Builder类，之前的代码都没法看”。确实，如果用户在已有Builder的类上再次触发生成，插件必须判断是“覆盖更新”还是“新增”。
我的策略是：生成前先扫描类中是否已经存在名为Builder的内部类。如果存在，直接抛出一个确认对话框，让用户选择“替换现有Builder”还是“重命名为Builder2”。默认选中“替换现有Builder”，并强制要求用户在替换前自己处理好代码中已有的Builder调用点——插件不会主动去重构这些调用，因为那涉及整个项目的引用分析，复杂度会指数级上升。
替换的实现，我选择先删除旧的Builder内部类，再插入新的PSI元素。注意这里必须捕获删除操作，以便支持Ctrl+Z撤销。DeletePsiElementHandler可以直接操作，但直接用psiClass.delete()也可以，IDEA会自动记录undo信息。
5. 实测效果与使用场景验证
5.1 用一个模拟业务对象做全流程演示
为了验证插件的实际效果，我模拟了一个电商项目里的订单查询对象，有十一个字段，其中包含一个泛型字段和一个带初始值的字段：
public class OrderQuery { private String orderId; private Long userId; private Integer status; private LocalDateTime startTime; private LocalDateTime endTime; private List<String> tagList; private int pageSize = 20; private int pageNum = 1; private String sortField; private boolean asc; private String remark; }在IDEA里打开这个类，光标放在类名上，按Alt+Insert，选择“Generate Builder Pattern”，插件生成的代码效果如下（节选）：
public class OrderQuery { // ...原字段... public static final class Builder { private String orderId; private Long userId; private Integer status; private LocalDateTime startTime; private LocalDateTime endTime; private List<String> tagList; private int pageSize = 20; private int pageNum = 1; private String sortField; private boolean asc; private String remark; public Builder() { } public Builder orderId(String orderId) { this.orderId = orderId; return this; } // ...其余链式方法... public Builder pageSize(int pageSize) { this.pageSize = pageSize; return this; } public Builder pageNum(int pageNum) { this.pageNum = pageNum; return this; } public OrderQuery build() { return new OrderQuery(orderId, userId, status, startTime, endTime, tagList, pageSize, pageNum, sortField, asc, remark); } } }同时，插件检测到OrderQuery没有全参构造方法，弹窗询问后自动补了一个全参构造方法。整个流程从触发到结束不到三秒，生成的代码格式和项目里其他代码保持一致，import也补全了LocalDateTime和List。
这个案例基本验证了插件的核心价值：手动写这样一段Builder代码，正常速度至少需要两三分钟，而且容易在方法名上出错；现在一键完成，且逻辑一致性有保障。
5.2 在泛型类与继承场景下的实测记录
接着我用一个泛型分页类做测试：
public class PageResponse<T> { private List<T> records; private long total; private int pageNum; private int pageSize; }生成的Builder类声明为public static final class Builder<T>，链式方法返回值都是Builder<T>，build()方法生成new PageResponse<T>(records, total, pageNum, pageSize)。编译通过，类型推断也正常。
继承场景我用了一个ChildEntity extends BaseEntity的模拟对象，父类有id和creator字段，子类有name和age字段。生成后，子类的Builder包含四个字段，build()方法调用父类全参构造方法：
public ChildEntity build() { return new ChildEntity(id, creator, name, age); }这里有个细节：父类的构造方法参数顺序如果和我生成的字段顺序不一致，会导致编译错误。所以在实现里，我不是简单地按字段声明顺序传参，而是从目标的构造方法参数列表里反查出字段名，再按构造参数的真实顺序拼接。这个坑不踩一次是想不到的。
5.3 插件在无参构造类上的行为验证
还有一种常见的类结构是：只有无参构造方法，字段都是private且没有setter，典型的是某些配置类或者DTO。我测试时发现，如果直接生成Builder，build()方法会变成return new TargetClass();，字段根本没有赋值路径，Builder形同虚设。
解决方式是前面提到的：插件检测到类里没有全参构造方法时，会主动在确认窗口中询问“是否同时生成一个全参构造方法”。确认后，插件会在目标类中新增一个包含所有字段的构造方法，然后Builder的build()方法调用它。这等于生成的是“构造方法 + Builder”的组合拳，对很多老代码来说反而是意外的惊喜——补上了一个一直缺失的构造方法。
6. 常见问题与排查技巧实录
6.1 生成的代码报“类已存在”或“变量重复定义”错误
问题现象：用户在一个已经有Builder内部类的类上再次生成，IDEA直接报编译错误，原有的Builder类和新建的Builder类声明重复。
排查过程：第一反应是插件没有处理重复生成防护，果然如此。后来在生成流程的最前面加了检查逻辑，发现已有同名内部类时弹窗确认。这个修改解决后，基本不会再出现重复声明。
经验总结：代码生成类插件，一定要把“幂等性”作为设计目标之一。同一个操作重复执行，要么不产生副作用，要么给出清晰提示。否则用户在操作习惯上稍微手滑，后果就是大面积编译错误。
6.2 类型import没有被自动补全
问题现象：生成代码后，Builder内部类使用了LocalDateTime，但文件顶部没有新增import，编译报找不到符号。
排查过程：仔细观察发现，CodeStyleManager.reformat并不会自动补全import，它只负责格式化空格和换行。补全import需要JavaCodeStyleManager.shortenClassReferences，这个方法会分析psiClass的引用并尝试简化。但它的一个隐蔽缺点是，如果当前文件中import了不少冲突类，它会犹豫不决，有时会把该补的import漏掉。
解决方案：在调用shortenClassReferences之前，显式地调用ImportHelper或手动计算需要的import，并把它们添加到文件的import列表里。这个逻辑虽然繁琐，但在生成代码场景下是必须的。具体做法是遍历生成代码中出现的使用到的外部类，通过PsiElementFactory.createClassFromText创建为一个临时引用，再委托JavaCodeStyleManager计算并添加import。
6.3 在Kotlin文件上点了生成按钮没反应
问题现象：用户在Kotlin文件上使用插件，右键菜单直接灰掉。
排查过程：最初版本的update方法只检查了PsiClass类型，而Kotlin类在IDEA里的PSI实现不是PsiClass，而是KtClass，因此findTargetClass返回null。
解决方案：在update方法里增加对Kotlin文件的检测逻辑，判断当前文件是否由Kotlin插件支持。如果检测到Kotlin类，可以暂时禁用菜单，并在action的提示文本里追加“仅支持Java类”。Kotlin的data class本身可以通过copy()方法实现类似Builder的链式赋值，但语义不完全一致，所以我没有强行支持Kotlin，而是在菜单上加了个说明。这个处理减少了用户的困惑：以前是“点了没反应”，现在是“看得到但明确知道不支持”。
6.4 PSI操作导致文档锁异常（Read/Write Action问题）
问题现象：生成代码时偶尔抛出ReadAccessAllowedException，提示必须在写动作（Write Action）里修改PSI。
排查过程：这个坑在IntelliJ插件开发里非常经典。IDEA的PSI树有严格的读写线程模型——读取操作可以并发执行，但修改PSI结构必须在写动作上下文中。把所有psiClass.add()、psiClass.delete()等修改操作包在WriteCommandAction.runWriteCommandAction()里，问题解决。
WriteCommandAction.runWriteCommandAction(project) { val added = psiClass.add(builderClass) CodeStyleManager.getInstance(project).reformat(added) }经验总结：写插件时凡是修改PSI的代码，第一反应就应该是把它包进Write Command，不要等到报错再修。另外，写入操作还尽量要包裹在ApplicationManager.getApplication().invokeLater中，避免在事件分发线程之外直接修改UI状态。
6.5 生成结果被IDEA自动格式化打乱，缩进全乱了
问题现象：生成出来的代码缩进不稳定，从4空格到2空格随机切换。
排查过程：这是因为reformat用的是项目级代码风格设置，而用户IDEA全局设置和项目级设置不一致时，reformat会优先选项目级的。如果项目没有明确定义code style，IDEA会退回到最近的默认值，导致缩进不一致。
解决方案：方案分两步。第一步，插入新PSI元素时，明确指定CodeStyleManager.createLocalCodeStyleManager并传入项目级风格。第二步，在插件设置里加一个“生成后是否自动格式化”的开关，默认打开，但允许用户关闭。关闭后插件不会触发reformat，生成的代码就保持原样，用户自己用Ctrl+Alt+L统一格式化。
7. 插件后续升级方向与扩展建议
目前插件已经能满足日常开发中90%的Builder生成需求，但依然有不少可以扩展的方向。第一个是支持为Builder方法生成Javadoc注释，团队规范要求所有方法必须有文档时，这一步可以省去大量手写时间。第二个是支持生成toBuilder()实例方法，让已有对象可以基于当前状态派生出新对象。第三个是考虑提供“Builder转构造器”的反向功能——把链式调用改写成普通构造函数调用，这在一些静态分析工具要求减少对象创建的场景里会很有用。
技术上，这些扩展大多只需要在分析层和生成层增加对应的逻辑，骨架完全可以复用现有的分层设计。比如toBuilder()方法，本质上就是读取目标类的所有Getter方法，生成一份把字段值传回新Builder的代码，这个逻辑在分析层的字段清单基础上加一个Getter提取就能完成。
如果有人想基于这个插件学习IDEA插件开发，我建议先从Alt+Insert菜单的Action入口开始，再研究PSI的读写模型，最后再碰代码生成这种有状态的操作。看懂了PsiClass、PsiElementFactory、WriteCommandAction这三样，大部分插件需求都能做了。
我个人在实际操作中的体会是，这类代码生成工具最忌讳贪多求全。与其支持一百种场景但每种都半吊子，不如先把Java里最常见、结构最固定的场景做稳，再逐步扩展边界情况。Builder模式刚好是一个非常典型的“结构固定、适合机器生成”的目标，这也是这个插件能保持稳定、上线后一直有人用的根本原因。
