Go中可被import的模块需满足：正确声明module路径（如github.com/yourname/mylib）、含导出标识符（首字母大写）、无main.go、路径与托管地址一致；发布版本须打v前缀tag并推送；路径变更不自动迁移。
Go 语言中没有传统意义上的“可安装库”概念，go install 生成的是可执行命令，不是供其他项目 import 的模块；真正可重用的单元是 **以 module 为边界、导出合法标识符、满足语义化版本规则的 Go 包**。
如何定义一个可被他人 import 的模块
关键不在“写多少代码”，而在 go.mod 文件是否正确声明了模块路径（module path），且该路径能被 Go 工具链解析为唯一、可寻址的源码位置：
- 模块路径应与代码托管地址一致（如
github.com/yourname/mylib），否则go get会失败或拉取错误版本 - 必须在项目根目录运行
go mod init github.com/yourname/mylib初始化，不能依赖 IDE 自动生成的模糊路径 - 模块内至少有一个
.go文件，且其中至少一个func、type或var名字首字母大写（如DoSomething），否则外部无法访问 - 避免在模块根目录放
main.go—— 这会让go build默认构建二进制，掩盖其作为库的用途
为什么别人 import 后调用报 undefined：不是包没导入，而是符号未导出
Go 的可见性由标识符首字母大小写决定，和 public/private 关键字无关。常见误判场景：
- 写了
func helper()（小写）想给内部工具函数用，结果用户mylib.Helper()报错：这是设计使然，不是 bug - 结构体字段全小写（如
type Config struct { host string }），外部无法读写 —— 应改为Host string并配文档说明用途 - 包名与目录名不一致（如目录叫
v2，但package v1），导致go list -f '{{.Name}}' ./v2输出异常，影响构建一致性
如何发布带版本的稳定库（非 master 分支直连）
Go 模块依赖版本由 go.mod 中 require 行 + tag 共同决定，不靠分支名。发布步骤极简但易漏关键动作：
github-issue-creator
下载
将原始笔记、错误日志、语音听写或截图转换为简洁的 GitHub 风格 Markdown 问题报告。当用户粘贴 bug 信息、错误消息或非正式描述，并想要结构化的
立即学习“go语言免费学习笔记（深入）”；
- 本地测试通过后，先
git add . && git commit -m "v0.3.1: fix race in NewClient" - 打 tag 必须带
v前缀：git tag v0.3.1，否则go get github.com/yourname/mylib@v0.3.1会报invalid version - 推送 tag 而非仅 push 分支：
git push origin v0.3.1（很多人只git push，tag 留在本地） - 下游项目升级时，建议用
go get github.com/yourname/mylib@v0.3.1显式指定，而非go get -u—— 后者可能跳过中间兼容版本，触发意料外的 breaking change
模块路径变更后老项目还能用吗
不能自动迁移。Go 不提供重定向机制，旧路径（如 gopkg.in/oldlib.v1）一旦停更，所有依赖它的项目都会在 go build 时卡在 go: finding module for package。稳妥做法只有两种：
- 保持旧路径仓库存活，用
replace在新模块里桥接：replace gopkg.in/oldlib.v1 => ./internal/compat
，然后在./internal/compat中重新导出原逻辑 - 发一次最终版（如
v1.9.9），在 README 顶部加粗注明 “MOVED TO github.com/yourname/mylib/v2”，并让 CI 对每个 PR 检查是否含旧 import
模块路径就是契约。改它等于换身份证号，别指望 runtime 自动帮你认亲。
