Go gopls 0.23 为什么删掉 fix 子命令：codeaction 迁移与 CLI 兼容边界

升级 gopls 0.23 后，如果脚本还在调用 gopls fix，问题不在 Go 源码，而在命令行职责已经调整。这个版本移除了 fix、inspect 和 bug 子命令，官方建议分别转向 codeaction 和 remote；serve 仍然可用。迁移时还要顺手清掉旧的 importsSource 配置。

最稳妥的处理是：先确认 gopls 版本，再把修复动作迁移到 gopls codeaction，把远程检查迁移到 gopls remote，最后删除 importsSource 并在编辑器中复查诊断。

gopls 0.23 为什么删掉 fix 子命令

先看版本，而不是先改项目里的 Go 文件：

gopls version
gopls help

在 0.23 的帮助信息中，fix 已不再是可用子命令。官方给出的背景是持续重做 gopls CLI，使它更适合人和工具调用；这也意味着 CLI 不是承诺长期稳定的接口，图中的“CLI 不稳定接口”应被视为升级检查边界。编辑器通过 Language Server Protocol 请求 Code Action，与命令行里一个名为 fix 的旧入口不是同一层协议。

因此，升级后看到“unknown command fix”时，先把它归类为工具链兼容问题。只有当 Code Action 本身仍报错时，才继续检查项目代码、模块版本和 analyzer 配置。

把旧命令迁移到新的职责入口

官方迁移关系可以压缩成下面这张表。它描述的是职责边界，不是把每个命令都机械替换成同一组参数。

在本机确认新入口：

gopls help codeaction
gopls help remote
gopls help serve

如果团队脚本只是为了让编辑器应用修复，优先改成编辑器里的 Code Action 流程；如果脚本确实要调用 CLI，就把版本和帮助输出作为升级时的显式检查项。

清理配置文件里的旧 importsSource

命令迁移完成后，检查工作区和用户配置中的 importsSource。gopls 0.23 已移除这个设置，现在只使用内置 imports 引擎；残留旧键会产生 warning diagnostic，但这不等于 Go 包导入本身坏了。

rg -n "importsSource|errorsastype|errorsastypeshadow" .

处理顺序很简单：删除 importsSource，重启编辑器，再打开一个含未使用导入或缺失导入的 Go 文件观察补全和诊断。若项目还写着旧的 errorsastype analyzer 名称，也要改为 errorsastypeshadow，不要把重命名误判成 analyzer 消失。

这里别一次性修改所有 gopls 设置。先保留一份可回滚的配置 diff，只处理已被官方版本明确移除或重命名的键，剩余警告再逐条定位。

把 CLI 迁移和编辑器 Code Action 分开验证

一个常见误区是：看到命令行入口变化，就把所有修复都搬到脚本里。更可靠的验证分两条线。

第一条线检查 CLI：gopls help codeaction、gopls help remote 能返回当前版本的帮助，脚本不再调用已删除的 fix。第二条线检查编辑器：在可回滚分支中对一个明确的诊断触发 Code Action，确认预览、应用和撤销都正常。两条线都通过，才说明迁移完成。

如果 CI 直接执行 gopls，建议记录 gopls version，并在升级评审中核对 CLI 子命令和配置键。若只是编辑器插件随开发环境更新，则重点检查工作区的 gopls 设置和诊断面板，不要因为 CLI 文档变化而改动业务代码。

常见问题：升级后还要不要固定 gopls CLI

gopls codeaction 能不能当成永久稳定 API？

不能这样假设。官方页面明确说明 gopls CLI 不是稳定接口；团队可以固定版本使用，但每次升级仍应重新看帮助和变更说明。

importsSource 删除后导入功能会消失吗？

不会。0.23 改为使用内置 imports 引擎，残留旧配置才会带来警告。删除配置后重新打开文件，检查补全和诊断即可。

编辑器里还能继续用修复功能吗？

可以。编辑器使用 Code Action 请求具体修复，CLI 的 fix 子命令移除不等于语言服务器的修复能力整体消失。

脚本应该怎么防止下次升级再次中断？

固定 gopls 版本、记录版本输出，并在 CI 中先执行帮助检查；不要依赖未文档化参数，也不要把 CLI 子命令当作 Go 语言本身的稳定语法。