package是目录级逻辑分组，module是版本化依赖单位；二者抽象层级不同，不可互换：包名须与目录一致且统一，模块由go.mod定义导入路径根，缺失则import失败。
package 是代码组织的最小单位，module 是依赖管理与版本发布的单位——二者不在同一抽象层级，不能互换使用，混淆会导致 import 失败、构建出错或依赖失控。
包（package）是目录级的逻辑分组，不是文件级的
Go 中一个 package 对应一个目录，该目录下所有 .go 文件必须声明相同的 package xxx 名（如 package utils），且包名通常与目录名一致。编译器不认路径，只认包声明；但 import 时用的是**导入路径**（import path），即从模块根开始的相对路径。
- 错误写法：
myproject/utils/helper.go声明package helper，而myproject/utils/validator.go声明package utils→ 编译报错：found packages helper and utils in .../utils - 正确做法：两个文件都写
package utils，然后在 main 包中用import "myproject/utils"导入 - 注意：
main包必须且只能出现在可执行入口目录（如项目根或cmd/xxx），且必须含func main()
模块（module）由 go.mod 定义，决定 import 路径的起点
module 不是代码结构，而是版本化容器。它的名字（module github.com/user/repo）就是整个项目的导入前缀，所有子包的 import 路径都以此为根。没有 go.mod，Go 会退化到 GOPATH 模式（已弃用），跨目录 import 极易失败。
- 初始化命令：
go mod init github.com/user/myapp—— 这一步不是“可选”，而是让myapp/utils能被外部项目以import "github.com/user/myapp/utils"正确引用的前提 - 常见坑：
go mod init myapp（没带域名）→ 后续发布到 GitHub 时，其他项目 import"github.com/user/myapp/utils"会找不到包，因为模块路径不匹配 - 私有仓库？加配置：
go env -w GOPRIVATE=git.internal.company/*，否则go get会尝试走 proxy 并失败
为什么 import "fmt" 不需要 go.mod，但 import "myproject/utils" 一定需要？
fmt 是标准库，硬编码在 Go 安装目录中，路径由编译器内置识别；而 myproject/utils 是用户代码，Go 必须通过 go.mod 知道它属于哪个模块、版本是多少、是否本地存在。没有 go.mod，Go 就不知道 myproject 是指当前目录、还是某个已安装的旧版本、甚至根本不存在。
- 现象：
go run main.go报错cannot find module providing package myproject/utils→ 本质是缺失模块定义或 import 路径与module声明不一致 - 验证方式：
go list -m查当前模块名，go list -f '{{.Dir}}' .看 Go 认定的模块根目录是否符合预期 - 多模块项目？允许，但子模块需各自有
go.mod，且父模块不能直接 import 子模块的包（除非用完整模块路径）
什么时候必须用模块，什么时候包就够了？
单文件脚本或临时测试（如 hello.go 只有 package main）可不用 go.mod；但只要涉及**多个目录、第三方依赖、或想被别人引用**，就必须有模块。包解决“代码怎么放”，模块解决“别人怎么找你、用哪个版本”。
立即学习“go语言免费学习笔记（深入）”；
- 发布库？必须：
go mod init github.com/you/libname+git tag v1.0.0 - 内部微服务？必须：即使不发版，也要用模块管理
require和go.sum校验 - 只是拆了几个
.go文件到不同目录，但没运行go mod init？那你其实还在“无模块混沌状态”，go build可能侥幸成功，但go test ./...或 CI 环境大概率失败
模块路径一旦设定就别轻易改，改了等于换了个新库；包名可以小范围调整（比如 utils → tool），但所有 import 语句和文档都得同步更新——这点比 python 的模块重命名更刚性。