Question

TLDR：golang中是否存在一种方法（即使它有点不标准），可以“毒害”某个功能或完全导入某个包。

更长的版本：我正在编写一个thrift服务，所有面向公共的函数返回结果，或者在thrift文件中声明的某种类型的错误。代码生成器为接口生成代码，如下所示：

publicFacingFunc(...) (returnType, error)

这将是很棒的，直到我与之合作的人决定检查另一个条件，并且当不满足该条件时，会发生类似这样的事情：

if conditionIsNotMet {
    return nil, errors.New(...)
}

代码编译，但是当出现错误时，收到的消息是未记录的随机字符串。所以在这些文件中，我想阻止使用“errors”和“fmt”包。

是的，我试过了，但仍然在文件的顶部发出一个明显的警告，但似乎没有人阅读。

顺便说一下，公共错误都有一个相应的“构造函数”，它们在这些文件的外部，在我的情况下只应该使用那些文件。

Answer 1

如果您只关心文件中的包使用，您可以使用愚蠢的名称进行导入，例如“永远不会......”人们可以使用它，但他们可以使用＃39 ; d得到我认为的想法。

 import (
      NEVER "fmt"
 )

或者，如果你想减少愚蠢，可以使用_下划线，https://golang.org/doc/effective_go.html#blank_import

import (
    _ "fmt"
)

将加载导入，但仅加载它的副作用（即，不是为了明确使用。

要停止输入非某种类型的所有错误，您可以使用reflect来停止类型断言的不良类型https://golang.org/ref/spec#Type_assertions

v, ok = x.(T)

因此，如果err出现在面向公众的功能中，您不想通过，请检查它是什么类型的错误，

 specialError, ok := err.(mypackage.ErrorType)
    if !ok {
        // don't send this error on
    }

Answer 2

如果您真的想要强制执行，可以执行构建步骤，检查所有包的go list输出，并确保fmt和errors不在直接进口清单。但是，有了这样的通用包，可能很难完全避免。你可以做更详细的解析来检测fmt.Errorf或其他什么，但可能会很棘手。

更具侵入性的解决方案是修改这些软件包的软件包源，并强制开发人员使用您的自定义分发。对于std lib中字面上使用的fmt和errors包来说可能太难了，但它可能适用于其他包。我永远不会推荐它。绝对将它添加为在签入和PR以及事物上运行的构建时验证。