package 是代码组织最小单位，module 是依赖管理基本单元；标准库包如 fmt 无需 go mod init，而自定义包必须匹配 module 路径，否则报错；package 名与目录名不一致易致维护混乱；多 main 包或混用 go.mod 会破坏模块解析。
package 是代码组织的最小单位，module 是依赖管理的基本单元——二者不在同一抽象层级，不能互换或混用。
为什么 import "fmt" 不需要 go mod init？
因为 fmt 是 Go 标准库包，它属于内置模块（std），不参与 module 依赖解析。Go 编译器直接识别标准包路径，无需通过 go.mod 查找或版本控制。
- 所有以
fmt、net/http、encoding/json开头的导入，都走标准库路径，与当前项目是否启用 module 无关 - 但如果你写
import "myproject/utils"，Go 就必须通过 module 路径定位该包——此时若没go.mod或路径不匹配，会报错cannot find module providing package myproject/utils - 即使项目在
GOPATH下，只要启用了 module（如设置了GO111MODULE=on），Go 仍优先按go.mod解析，忽略GOPATH/src
package 名和目录名不一致会出什么问题？
编译能过，但 import 路径和使用方式会割裂，极易引发维护混乱和 CI 失败。
- 目录叫
studentmanage，但studentmanage/add.go写的是package student→ 外部要import "your-module/studentmanage"，却得用student.Add()，路径和包名不统一 - 如果多个子目录都声明为
package main（哪怕只是测试文件），go build会报错multiple main packages - 更隐蔽的坑：
go list -f '{{.Name}}' ./...会按实际package声明返回名字，不是目录名——CI 中做自动化检查时容易误判
go mod init 后，为什么 import 路径必须匹配 module 名？
因为 Go 的 import 路径 = module path + 相对目录路径，这是 module 机制的硬性解析规则。
立即学习“go语言免费学习笔记（深入）”；
myapp/
├── go.mod # module myapp
├── main.go # package main; import "myapp/handler"
└── handler/
└── api.go # package handler-
main.go中写import "myapp/handler"才合法；写import "./handler"或import "handler"都会失败 - 如果
go.mod里是module github.com/user/myapp，那正确 import 就得是import "github.com/user/myapp/handler" - 本地开发想快速引用未发布模块？用
replace：在go.mod加一行replace example.com/old => ./local-fix
最容易被忽略的一点：一个目录下可以有多个 .go 文件，但它们的 package 声明必须完全一致；而一个 module 可以包含几十个 package，但 go.mod 只有一个——别试图在一个项目里建多个 go.mod，除非你明确要做多 module 工作区（go work init）。否则，子目录里的 go.mod 会被视为独立 module，导致 import 解析断裂。
