Go gopls 重构没有弹出交互窗口时怎么判断客户端能力

先看实际 LSP 会话的初始化能力，再看客户端是否处理交互解析请求。编辑器能补全、能显示普通 code action，并不能证明它支持 gopls 的交互表单。没有弹窗还可能是动作不适用于当前选区、返回的是无需输入的普通编辑，或请求被取消；应按记录区分。

gopls 官方地址：https://go.dev/gopls/

数据来源：从会话记录开始

把“点击重构却没有窗口”当作一个待解释的现象，而不是直接认定 gopls 未安装。收集编辑器、Go 扩展和实际启动的 gopls 版本，以及一次动作对应的协议记录。终端里找到的 gopls 不一定是扩展启动的那个二进制。

# 此命令只查看当前 PATH 上的版本；还要对照编辑器实际启动路径
gopls version

Go 官方于 2026 年 10 月介绍了交互重构，并列出 gopls v0.24.0 与 VS Code Go 扩展 v0.56.0 的工作支持组合。这是可参考的组合，不代表任意客户端更新 gopls 后就自动具备表单 UI。本文没有操作编辑器或制造运行日志。

能力核对：客户端声明的输入类型是什么

官方集成设计的原型使用 experimental 扩展字段。客户端通过 interactiveInputTypes 声明可呈现的输入类型；服务端通过 interactiveResolveProvider 声明是否支持 command 解析。下面仅展示 initialize 参数中 capabilities 的一个片段，不是可直接粘进任意编辑器设置的配置。

{
  "experimental": {
    "interactiveInputTypes": ["string", "enum", "bool"]
  }
}

这里 string、enum、bool 分别表示文本、静态选项和布尔输入。声明必须与客户端真实实现一致；不能添加字段却不实现表单处理，再把后续失败归给服务器。具体字段属于该版本的交互扩展，不应把提案与所有 LSP 实现视为同一契约。

会话模型：保存的是声明与命令上下文

排查记录可分成三组：初始化声明、选中动作的命令参数、后续交互响应。不要只保存最后一条错误而丢失其所属会话。更新扩展或调整能力后，需要让客户端建立新会话，旧 initialize 记录不能证明新进程采用了新能力。

同样，不要把日志中的局部 JSON 片段当作完整请求手工重放到正在使用的服务。文档 URI、文档版本和命令参数与当前工作区有关，过期上下文会引入另一类故障。

查询路径：动作存在不等于会弹窗

针对集成设计中的交互命令，客户端要处理 command/resolve。若响应带有非空 formFields，才有待呈现的问题；答案通过 formAnswers 回传。输入错误与动作执行失败应分别记录，不应把表单取消解释成重构算法失败。

确认初始化记录中服务端的交互解析目标包含 command，再观察选择动作后是否出现相应解析请求。不要用 window/showDocument 的支持情况替代这个判断：打开文档或网页与呈现交互表单承担不同职责。

异常处理：按观察到的记录选择动作

不支持交互时，不保证所有动作都有相同降级。有的动作可能保留默认行为，有的依赖额外参数而不提供。以具体动作与版本说明为准，不应编造一个通用“开启弹窗”设置。

清理策略：最小记录足以复现问题

反馈问题时保留版本、初始化相关字段、动作名称、请求方法和错误类别。协议日志可能包含源码、路径和用户输入，分享前删去无关内容。排查结束后恢复正常日志级别，避免长期保存整个工作区会话。

只升级 gopls 为什么仍没有交互窗口？

窗口由客户端提供，服务端升级不能补齐客户端缺少的表单实现。

代码补全正常能证明能力协商没问题吗？

只能证明对应功能可用，不能证明交互扩展也已声明和实现。

重启后仍失败，下一步看哪里？

对照新会话初始化和这次动作的请求记录，先判断缺动作、缺解析请求还是缺 UI，不重复盲目重启。

参考：官方介绍 https://go.dev/blog/interactive-refactoring；集成协议设计 https://go.googlesource.com/tools.git/+/e4c23f539d7520ab784ba02e12cfffa2801494fc/gopls/doc/design/integrating-interactive-refactoring.md。协议字段按所引版本说明解读。