带+compatible的Go依赖为何go build可行但go list -m all失败？

这是个挺典型的Go模块版本规则问题，我来帮你拆解清楚：

为什么会出现+incompatible相关的错误？ #

首先得明确+incompatible后缀的设计初衷：在Go模块刚推出的时候，很多老项目已经发布了v2及以上的版本，但还没有添加go.mod文件。为了兼容这些项目，Go允许用+incompatible后缀来标识这是一个非模块模式下的兼容版本引用。

但一旦项目添加了go.mod文件，它就必须严格遵循语义化版本（semver）的模块规则：v2及以上的版本必须在模块路径末尾加上版本后缀（比如github.com/pingcap/tidb/v3），这时候+incompatible后缀就不再被允许了——这就是你看到invalid version: +incompatible suffix not allowed错误的核心原因：你引用的github.com/pingcap/tidb@v3.0.4+incompatible版本其实已经包含go.mod，但引用方式不符合模块规则。

为什么make lightning编译成功，但go list -m失败？ #

这两种行为的差异，本质是Go工具链在模块模式和非模块模式下的规则严格度不同：

• make lightning能成功，大概率是因为Makefile里的编译命令做了特殊处理：要么强制关闭了模块模式（比如设置了GO111MODULE=off），要么项目依赖是通过vendor目录管理的（你可以检查下项目根目录有没有vendor文件夹），或者用了TiDB生态自己的依赖管理工具。在非模块模式下，Go不会严格校验版本的语义化规则，会像Go 1.11之前那样直接根据代码路径查找依赖，所以编译能正常完成。
• 而GoLand的索引逻辑是基于模块模式的，它会调用go list -m这类模块相关命令来解析依赖树，这时候Go会严格执行模块版本规则，所以直接触发了错误。

你更新到v1版本后索引正常的原因 #

v1版本的模块不需要在路径末尾添加版本后缀，而且如果该版本的github.com/pingcap/tidb已经有go.mod，它的版本标识是完全符合模块规则的，所以GoLand能正常解析并完成索引。

这个依赖是否有效？ #

分场景来看：

• 对于非模块模式：v3.0.4+incompatible是有效的，因为非模块模式不强制语义化版本规则。
• 对于模块模式：这个版本引用是无效的，正确的引用方式应该是带路径后缀的版本，比如github.com/pingcap/tidb/v3@v3.0.4（前提是该版本的模块路径确实包含/v3后缀）。

如果想让GoLand和编译命令的行为统一，你可以尝试：

1. 检查项目的go.mod，将github.com/pingcap/tidb的依赖改成符合模块规则的版本（比如github.com/pingcap/tidb/v3 v3.0.4）。
2. 如果项目依赖是通过vendor管理的，确保GoLand开启了“Use vendor directory”的选项（在GoLand的Go Modules设置里）。

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