包是代码组织最小单元，模块是依赖管理最小单元；同一目录下所有.go文件须声明相同包名，模块路径需全局唯一且与仓库地址一致；导入路径=模块路径+子路径，非包名本身。
包（package）是代码组织的最小单元，模块（module）是依赖管理的最小单元
Go 里没有“类”或“命名空间”的概念，package 就是最基础的隔离边界：同一目录下所有 .go 文件必须声明相同的 package name，它们编译后归为一个逻辑单元，彼此可直接访问导出符号（首字母大写）。而 module 是更高层的概念，它不参与编译时的符号解析，只负责记录“这个项目用到了哪些包、来自哪里、具体哪个版本”。go.mod 文件一存在，当前目录就成为模块根，无论里面有没有 main 包。
- 包名由
package xxx声明，但导入时用的是**导入路径**（如github.com/user/proj/pkg/utils），不是包名本身 - 模块路径（
module github.com/user/proj）必须是全局唯一标识，且应与代码仓库地址一致；否则go get或他人引用时会失败 - 一个模块可以包含多个包（比如
cmd/、pkg/、internal/），但一个包不能跨模块——Go 不允许从internal包被本模块以外的其他模块导入
为什么 import "fmt" 能直接用，而 import "myutils" 却报错？
因为 Go 的导入路径不是“包名”，而是“模块路径 + 相对子路径”。fmt 是标准库，它的导入路径就是 fmt；而你写的 myutils 如果没放在模块路径下，Go 就找不到它。常见错误现象：
-
import "myutils"→no required module provides package myutils：没配模块路径，或没在go.mod中声明该路径 -
import "./myutils"→ 编译失败：Go 禁止相对路径导入（除测试中go test -i场景外） - 包名和目录名不一致（如目录叫
helpers，但文件里写package util）→ 同一模块内可编译，但别人go get后导入路径会变成github.com/user/proj/helpers，却要以util.XXX调用，极易混淆
正确做法：目录名 = 包名 = 导入路径的末段。例如：
myproject/
├── go.mod # module github.com/you/myproject
├── main.go # package main
└── pkg/
└── utils/ # ← 目录名
└── helper.go # package utils ← 包名一致然后导入：import "github.com/you/myproject/pkg/utils"，使用：utils.DoSomething()。
立即学习“go语言免费学习笔记（深入）”；
go mod init 后为什么还要 go mod tidy？
go mod init 只生成空的 go.mod，并不分析代码里实际用了哪些包；go mod tidy 才真正扫描所有 import，补全 require 列表，并下载依赖到 $GOPATH/pkg/mod，同时写入校验和到 go.sum。漏掉这步，会出现：
- CI 构建失败：本地能跑，因为缓存了旧依赖；CI 拉新环境，
go build报missing module - 版本漂移：没锁死间接依赖（
indirect），下次go get可能升级某个底层模块，引发兼容性问题 -
go.sum缺失 → 安全扫描工具告警，无法验证依赖完整性
建议每次增删 import 后都运行：go mod tidy -v（-v 查看详细变更）。
同一个包名出现在不同路径下，怎么避免命名冲突？
Go 允许不同路径下有同名包（如 github.com/a/lib/log 和 github.com/b/app/log），但若在同一个 .go 文件里同时导入，就会报错：redeclared as imported package name。这不是 bug，是设计使然——包名只是别名，导入路径才是唯一标识。
-
解决方法只有显式起别名：
import ( loga "github.com/a/lib/log" logb "github.com/b/app/log" ) - 别名不能是
_（那是弃用导入）或.（会把符号注入当前命名空间，极不推荐） - 更稳妥的做法是：避免在单个文件里混用同名包；如确需共存，优先用语义化别名，如
zaplog、stdlog
模块路径稳定性比包名更重要——一旦发布过 v1.0.0，就别轻易改 module 行；包名可以小范围重构，模块路径改了等于换了个新库。
