标准库包名即导入路径，第三方包导入路径必须为完整URL；标准库无需go get，第三方包依赖go mod tidy管理；导出规则和并发安全均一视同仁，但第三方包需格外注意文档说明。
标准库包名就是导入路径，第三方包必须带域名
Go 标准库的包名和导入路径完全一致：fmt、net/http、encoding/json——这些路径就是官方定义的，不需额外配置，import 直接写就行。而第三方包的导入路径一定是完整 URL 形式，比如 github.com/gin-gonic/gin 或 golang.org/x/sync/errgroup，它本质是模块坐标，不是“包名”。你不能只写 gin 或 errgroup，否则编译报错 cannot find package。
- go mod 初始化后，
import语句里的路径会被go mod tidy自动解析为具体版本，但路径本身不能省略任何一级 - 别名导入（如
mrand "math/rand"）对标准库和第三方包都适用，但别名只是本地引用符号，不改变原始路径 - 如果误把第三方包当标准库用（例如写
import "gin"），Go 不会提示“找不到 gin”，而是直接报错：无法解析该导入路径——因为没匹配到任何已知模块或标准库入口
标准库无需 go get，第三方包必须靠 go mod tidy 补全依赖
标准库随 Go 安装自带，只要版本兼容（比如用了 io.ReadAll 就得 Go 1.16+），import 后就能用，不需要任何下载动作。而第三方包哪怕只 import 一行，也必须确保它出现在 go.mod 中；否则构建时会失败，尤其在 CI 或新机器上。
- 手动
go get github.com/sirupsen/logrus不是必须步骤，go mod tidy足够——它会扫描所有 import 并拉取缺失项 -
go mod tidy还会清理未使用的依赖，避免go.mod膨胀，这点标准库完全不参与（它压根不出现在go.mod里） - 如果网络受限导致
go mod tidy卡住，错误信息通常是failed to fetch或超时，这时要检查GOPROXY设置，而不是怀疑 import 写法
导出规则一视同仁，但第三方包更常遇到“找不到函数”问题
无论是标准库还是第三方包，Go 的导出规则完全一样：首字母小写的标识符（如 doubleSpace、parseHeader）永远无法被外部包调用。但你在用第三方包时更容易撞上这个限制，因为标准库文档和 IDE 提示较全，而很多第三方包的私有函数没注释、没文档，只在内部使用。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 看到
undefined: xxx报错，先确认你要调的函数名是不是大写开头；比如blackfriday.doubleSpace必然失败，它根本不在导出列表里 - 不要尝试用点操作符（
import . "github.com/xxx"）绕过包名前缀——这只会让冲突更隐蔽，且无法解决私有函数不可见的问题 - 若确实需要某私有逻辑，正确做法是在自己包里重写，而不是 fork 修改源码或强行导出——后者会让升级变得高危且不可持续
标准库默认并发安全，第三方包得看文档，不能假设
标准库中多数包（如 sync.Map、bytes.Buffer、strings.Builder）明确说明了并发使用场景，有些甚至专为并发设计；但第三方包几乎从不默认提供并发安全保证，除非文档白纸黑字写了 “safe for concurrent use”。
立即学习“go语言免费学习笔记（深入）”；
- 比如
github.com/gorilla/sessions的CookieStore实例，多个 goroutine 同时调用Get()没问题，但修改 session 值后必须显式Save()，且 save 过程非原子——这不是 bug，是设计选择 - 常见陷阱：把一个第三方客户端（如
redis.Client、http.Client）当成单例全局复用，却没确认它是否支持并发调用；结果偶发 panic 或数据错乱 - 最稳妥的做法是：查它的 README 或 godoc，搜索 “concurrent”、“goroutine”、“safe”，没写清楚就默认不安全，加锁或按需新建实例
最容易被忽略的是：标准库的稳定性是强承诺，第三方包的 API 可能在小版本更新里静默变更——尤其是没遵循语义化版本、或把 v0.x 当正式版发布的项目。别只盯着 import 能不能通过，得盯住 go.sum 里那串哈希有没有变，以及 changelog 里有没有 breaking change。
