必须用 go mod init 且早于首次提交，因其生成的 go.mod 是可复现构建核心；模块路径须与 GitHub 地址一致；go.mod 和 go.sum 需一并提交；CI 中需禁用 GOPATH 并启用 module 模式。
初始化 Go 项目时该不该用 go mod init？
必须用，且要早于第一次提交。GitHub 本身不管理依赖，go mod init 生成的 go.mod 文件才是 Go 项目可复现构建的核心依据。
常见错误是先建空仓库、推代码、再补 go.mod，结果 CI 失败或他人 go build 报 no required module provides package。
-
go mod init github.com/username/repo—— 模块路径必须与 GitHub 仓库地址一致，否则go get无法正确解析 - 如果项目将来要发布为公共库，模块名不能以本地路径（如
./）或未注册域名开头 -
go mod tidy后记得提交go.mod和go.sum，二者缺一不可
GitHub Actions 中跑 Go 测试为什么总卡在 go test？
多数是因为没设 GOPATH 或没启用 module mode，尤其在旧版 Ubuntu runner 上默认仍走 GOPATH 模式。
正确做法是在 workflow YAML 中显式声明环境变量并指定 Go 版本：
立即学习“go语言免费学习笔记（深入）”；
env:
GOPATH: ""
GOCACHE: /tmp/.cache/go-build
steps:
- uses: actions/setup-go@v4
with:
go-version: '1.22'
- run: go test -v ./...- 删掉
GOPATH环境变量（设为空字符串），强制 Go 使用 module 模式 - 避免用
go test ./...扫描所有子目录——如果有cmd/下多个 main 包，会报multiple main packages；改用go test ./... -exclude=cmd/或按包显式列出 - 测试超时常见于网络请求未 mock，建议加
-timeout 30s防止 CI 无限挂起
如何让别人用 go install 一键安装你的 CLI 工具？
关键不是 GitHub 设置，而是模块路径 + main 包位置 + tag 版本三者对齐。
本文档主要讲述的是maven使用方法；Maven是基于项目对象模型的（pom），可以通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具。Maven将你的注意力从昨夜基层转移到项目管理层。Maven项目已经能够知道 如何构建和捆绑代码，运行测试，生成文档并宿主项目网页。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
例如你想让用户运行 go install github.com/username/mytool@v1.2.0 成功，需满足：
- 项目根目录下有
cmd/mytool/main.go（或任意cmd/），且其中/main.go package main -
go.mod的 module 名必须是github.com/username/mytool，不能是github.com/username/mytool/v2（除非你加了/v2后缀并适配） - GitHub 上打了带
v前缀的 tag（如v1.2.0），且该 commit 包含可构建的main包 - Go 1.21+ 默认启用
GOBIN，安装后二进制默认落在$HOME/go/bin/，需确保该路径在$PATH中
发布新版本时 go list -m -u all 提示有更新，但 go get -u 不升级？
这是 Go module 的语义版本控制机制在起作用：它只升到满足当前 require 约束的最新兼容版本，不是无脑拉最新 tag。
比如 go.mod 写着 github.com/some/lib v1.3.0，而对方发布了 v1.4.0，go get -u 会升级；但若发了 v2.0.0，则不会——因为 major 版本变更需手动修改 require 行并加 /v2 后缀。
- 检查是否真有符合 semver 规则的新版本：
go list -m -versions github.com/xxx/yyy - 强制升级到某 tag：
go get github.com/xxx/yyy@v1.5.0 - 若想跳 major 版本（如从 v1 到 v2），必须同时改
go.mod中的 import 路径和 require 行，不能只改后者
很多人卡在这里，是因为误以为 go get -u 是“升级全部”，其实它尊重模块约束，这点和 npm/yarn 行为逻辑不同。
