依赖规范

• go1.11 以上必须使用 go modules 模式。

  go mod init git.code.oa.com/group/myrepo
  

• 使用 go modules 作为依赖管理的项目不要提交 vendor 目录。
• 使用 go modules 管理依赖的项目， go.sum文件必须提交，不要添加到.gitignore规则中。

import 规范

• 使用 goimports 工具自动格式化引入的包名，import 规范原则上以 goimports 规则为准。

goimports 会自动添加依赖的包，并移除未引用的包。把依赖包按字母序升序排列，并对包进行分组管理。通过空行隔开，默认分为标准库包和非标准库包（第三方包和内部包）。

• 导入的包按照先后顺序应该分为三组：
  • 标准包
  • 外部包
  • 内部包

带域名的包名都属于外部包，如 github.com/xxx/xxx。内部包是指不能被外部 import 的包。

// Bad
import (
    "fmt"
    "os"
    "go.uber.org/atomic"
    "golang.org/x/sync/errgroup"
    "myproject/models"
    "myproject/controller"
)

// Good
import (
    "encoding/json"
    "strings"

    "go.uber.org/atomic"
    "golang.org/x/sync/errgroup"

    "myproject/models"
    "myproject/controller"
)

• 不要使用相对路径导入内部包，应该使用完整的路径引入包。

// Bad
import (
    "../net"
)

// Good
import (
    "xxxx.com/proj/net"
)

• 必要时给包起个别名

包名和 git 路径名不一致时，或者多个相同包名冲突时，使用别名代替会有更好的可读性。

// Bad
import (
    elastic "github.com/olivere/elastic/v7"
)

// Good
import (
    elastic "github.com/olivere/elastic/v7"
)

• 通用的功能包，应该放在 public 目录下，而不是具体业务目录下。

// Bad
import "github.com/xxxxxxxx/XXXServer/pkg/formatlog"

// Good
import "github.com/xxxxxxxx/utils/formatlog"

• import . 只能用于测试文件，且必须是为了解决循环依赖，才能使用。

package foo_test

import (
    "bar/testutil" // also imports "foo"
    . "foo"
)

在这种情况下，测试文件不能在包 foo 中，因为它使用 bar/testutil，后者导入 foo。所以我们使用import .形式导入包 foo，让测试文件假装是包 foo 的一部分，尽管它不是。除了这一种情况，不要使用import .，因为它使程序难以阅读，比如使用 Baz 这样的标识符，不知道其是顶级标识符还是导入包中的顶级标识符。

• 引入第三方包要慎重。

如引入 Github 上的包要确认活跃度，不知名的包可能会被下架或出现不兼容的版本升级情况，必要情况下可 fork 一份。

// 该包已经 404 了。
github.com/astaxie/beego/orm