这在IntelliJ插件开发里是个很常见的坑，核心问题基本都和PSI节点遍历的触发逻辑有关。下面给你拆解排查和解决步骤：

1. 必须在visitKtFile中调用父类方法 #

KtVisitorVoid的默认实现不会自动遍历文件的子节点，如果你重写了visitKtFile但没调用super.visitKtFile(file)，整个遍历流程会直接停在文件节点，根本不会往下处理类、属性这些子元素。修改后的代码应该是这样：

@Override
public void visitKtFile(@NotNull KtFile file) {
    // 先执行你自己的文件级逻辑（如果需要）
    // ...
    // 关键：调用父类方法，触发子节点的遍历
    super.visitKtFile(file);
}

2. 所有重写的visit方法都要保留父类调用 #

同理，如果你重写了visitClass但没调用super.visitClass(klass)，这个类内部的属性、函数等子节点也不会被遍历到。比如你的visitClass方法应该补全：

@Override
public void visitClass(@NotNull KtClass klass) {
    // 执行你自己的类节点处理逻辑
    // ...
    // 调用父类方法，遍历类内部的子元素
    super.visitClass(klass);
}

visitProperty里的super.visitProperty(property)也要保留，确保属性的子节点（比如初始化表达式）能被正常处理。

3. 确认Visitor的启动方式正确 #

要通过PSI节点的accept方法启动遍历，而不是直接调用某个visit方法。正确的调用姿势是：

// 假设你已经获取到目标KtFile实例
KtFile ktFile = ...;
TestVisitor visitor = new TestVisitor();
ktFile.accept(visitor);

虽然直接调用visitor.visitKtFile(ktFile)也会触发该方法，但accept是PSI遍历的规范入口，能确保整个遍历流程按预期执行。

4. 验证目标节点的实际类型 #

有时候你以为是KtProperty/KtClass的节点，实际可能是其他类型（比如KtParameter、KtVariableDeclaration）。可以在visitKtFile里加一段调试代码，打印所有子节点的类型：

@Override
public void visitKtFile(@NotNull KtFile file) {
    for (PsiElement child : file.getChildren()) {
        System.out.println("子节点类型：" + child.getClass().getSimpleName());
    }
    super.visitKtFile(file);
}

这样能快速确认你要处理的节点是不是真的对应你重写的visit方法类型。

按这几个步骤调整后，各个visit方法的断点应该就能正常触发了。

内容的提问来源于stack exchange，提问作者Vadim Salajan