go项目必须使用go mod，gopath模式已淘汰；go mod init的module名决定所有import路径，错误将导致编译失败；go mod tidy严格对齐代码实际引用与go.mod声明，会删除未使用的依赖。
Go 项目现在必须用 go mod，GOPATH 模式已淘汰，硬切 GOPATH 工作流只会卡在依赖拉不下来、版本冲突、本地开发路径错乱上。
go mod init 时 module 名写错会导致后续所有 import 路径失效
module 名不是随便起的，它直接决定你项目内所有包的导入路径。比如你在 ~/myproject 下执行 go mod init myapp，那你在 internal/service 里写 import "myapp/internal/repository" 才合法；如果写成 import "./internal/repository" 或 import "github.com/user/myapp/internal/repository"，编译会报 cannot find package。
- module 名推荐用域名前缀，比如
go mod init example.com/myproject，哪怕只是本地开发 - 一旦
go.mod生成，就别手动改module行——改了就得同步更新所有import语句 - 如果项目要推到 GitHub，module 名和仓库地址保持一致（如
github.com/user/myproject），否则go get无法正确解析
go mod tidy 不只是“自动加依赖”，它会删掉没被引用的 require 行
go mod tidy 的行为常被误解：它不是“补全依赖”，而是“对齐代码实际 import 和 go.mod 声明”。如果你删掉某段代码里对 github.com/gorilla/mux 的引用，再跑 go mod tidy，这行就会从 go.mod 里消失——哪怕你本地 vendor/ 还留着它。
- 执行前确保所有
.go文件都保存了，未保存的 import 不会被识别 - 如果依赖是通过
_匿名导入（比如只调 init 函数），go mod tidy会保留它，但要注意这种依赖容易被误删 - CI 环境中建议加
-v参数观察变化：go mod tidy -v，避免静默删掉关键依赖
internal/ 目录不是语法强制，但违反它会导致包被外部 import
Go 没有 private 关键字，internal/ 是约定俗成的“内部包”标识。只要路径里含 /internal/，Go 编译器就会检查：如果 A 项目 import B 项目的 internal/foo，而 A 和 B 不是同一个 module，就会报错 use of internal package not allowed。
- 目录名必须是
internal，拼错（如internals或internal_pkg）就失去保护作用 -
internal可以嵌套，比如internal/handler/v1、internal/repo/mysql，只要中间有/internal/即可 - 不要把 config、model 这类可能被测试或 CLI 工具用到的包放
internal里，否则cmd/下的main.go会 import 失败
go.sum 不该手改，但得知道它什么时候会变
go.sum 是自动生成的哈希清单，记录每个模块版本的 SHA256。它变的唯一原因是：某个依赖的 zip 包内容变了（作者重推 tag、删 commit、换代理源返回不同压缩包）。这时候 go build 会失败并提示 checksum mismatch。
- 遇到 mismatch，先确认是不是用了非官方代理（比如某些国内镜像缓存过期），换
https://proxy.golang.org试试 - 如果确定是上游改了，运行
go mod download+go mod tidy会自动更新go.sum - 提交时必须带上
go.sum，否则别人go build会卡在 checksum 校验
真正容易被忽略的不是命令怎么敲，而是 module 名和 import 路径的绑定关系——它贯穿整个项目生命周期，改一次就要全局 grep + 替换，而且 IDE 很难全自动修复跨 module 的引用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
