大多数用于与go run一起使用的单个文件应标记为// +build ignore或类似，并且它们必须各自声明一个func main。也许您可以使用不寻常的构建约束加上func main作为使用哪种模式的启发式？

之前的讨论：#33595

针对这一观点的反驳是，如果有人能为包含 build-ignore main 软件包的文件找到一个足够好的名字，他们可以使用这个名字作为子目录 ./internal/$NAME ,从而避免在 gopls 中使用任何单文件支持。

对此的反驳观点是，那里有很多遵循单文件方法的现有代码。

或许您可以尝试使用不寻常的构建约束条件，再加上 func main 作为启发式来选择要使用的模式？我认为这会相当有效。我认为它几乎涵盖了我遇到的所有 gopls 错误的方式。
他们可以使用 ./internal/$NAME 作为子目录的名称，从而省去了在 gopls 中进行任何单文件支持的需求。
虽然我明白这个观点，但我不同意。将忽略构建标签的不经意间出现的程序作为现有包的一部分并没有什么问题。一个只有单个文件的额外目录会更加冗长，而且在 Go 之前从未需要过这种奇怪的东西。告诉所有这些用户，为了取悦 gopls,他们需要改变他们的工作流程，而且客观上没有任何其他好的理由，似乎不会有一个好的结局 :)

我认为这个习惯用法并不常见，但除了 build ignore 标签之外，还有一个模式是将 "scripts" 放在一个以 "_" 为前缀的文件夹下，例如 _scripts。
这会像 per-file ignore 一样排除 Go 文件，但仍然可以使用 go run ./_scripts/gendocs.go 使它们可用。
我没有用较新版本的 gopls 进行检查，但 ignore 标签之前关闭了大多数 gopls 功能。或许这是一个 VSCode 集成(插件)问题。