你正在使用哪个版本的Go( go version )?
$ go version
go version go1.15.6 linux/amd64这个问题在最新版本中是否会重现？
是的，在gopls的当前提示符下也会重现。
你正在使用什么操作系统和处理器架构( go env )?
linux/amd64
你做了什么？
我基本上可以用任何代码复现这个问题。
但是具体来说，我使用了这个单文件包：
package main
func f(int) {}
func x() {
n := 3
m := 4
f(|)
}当我调用自动补全时，光标停在这个位置( | )。
你期望看到什么？
我期望看到根据涉及的类型给出合理的补全建议。无论我看到的补全列表是什么，我都希望如果我再次调用自动补全而没有任何更改，我应该再次看到相同的建议列表。
你看到了什么？
我看到了一个很长的列表，其中包含许多不相关的建议。此外，每次我调用自动补全时，列表都是不同的。
我在通常的环境(vim + govim)中注意到了这一点，但我也可以在vscode中复现。这里是一些截图(我连续按了三次 ctrl-space 并得到了这三个结果):
5条答案
按热度按时间00jrzges1#
驾驶猜测：候选者得分相等，且它们之间没有定义顺序，因此表现出看似“随机”的行为。
顺便说一下，我也在努力应对深度补全的冗长性质(这就是为什么你看到上面的
crypto.BLAKE*候选者，我相信)。不幸的是，在某些情况下它们会非常有用——但在90%的情况下，噪音使得它们对我来说无法使用。这感觉就像是这个东西的本质——也就是说，没有办法降低噪音并保持有用的情况。但我可能完全错了。zmeyuzjn2#
我相信随着后台处理更多未导入的包，它们会发生变化。它们最终不会稳定下来吗？
来自未导入包的基本对象(如ints、strings)可能很少被选为补全候选项，因此我们可以完全忽略它们。或者在它们出现之前设置一个最低前缀要求。
甚至更好的是，也许我们可以显示一个单一的深度补全候选项(而不是三个),并且只在它是最高得分候选项时才显示它。
2vuwiymt3#
https://golang.org/cl/311069提到了这个问题：
lsp/completion: omit deep completions into unimported packageshmtdttj44#
如果感兴趣，请尝试使用 https://go-review.googlesource.com/c/tools/+/311070/1 。我将使用它一段时间，看看是否有任何地方它不提供我期望的完整功能。
cygmwpex5#
如果结构体字面量内的完成优先考虑字段名而不是表达式，那也将是有用的，因为大多数结构体字面量都有名称。