先执行go mod init，再写代码、再go install或go run；不初始化模块会导致回退gopath模式，引发import路径解析失败或依赖无法下载。
Go 环境现在基本不用配 GOPATH 了，go mod 是默认依赖管理方式；本地工程结构也没必要照搬企业级模板，小项目直接用 cmd + internal + pkg 三层就足够清晰且可扩展。
go install 和 go mod init 哪个先执行？
先执行 go mod init，再写代码、再 go install 或 go run。不初始化模块，go 命令会回退到旧的 GOPATH 模式，导致 import 路径解析失败或依赖无法下载。
-
go mod init myapp生成go.mod，module 名必须是合法标识符（不能含点、斜杠、大写字母） - 如果项目名带域名（如
github.com/user/myapp），后续go get引入内部包时路径才一致，否则容易出现 “cannot find module providing package” 错误 -
go install ./cmd/...会自动识别cmd下所有子目录为可执行入口，前提是每个子目录里有main.go且包名是main
cmd/internal/pkg 目录怎么划分才不踩坑？
cmd 放可执行入口，internal 放本项目私有逻辑，pkg 放可能被其他项目复用的库——这个分法不是强制约定，但违反它会立刻暴露问题。
-
internal目录下代码不能被外部go get导入，Go 编译器会报错：”use of internal package not allowed“，这是硬性限制，不是风格建议 -
pkg里的代码如果没做版本兼容（比如没加go.mod、没遵循语义化版本），外部项目引用后升级容易崩，别图省事直接扔一堆函数进去 - 小项目初期可以没有
pkg，把通用工具函数放在internal/util也行；但一旦发现两个cmd子目录重复写了发 HTTP 请求、读配置的逻辑，就是拆pkg的明确信号
为什么 go build -o ./bin/app ./cmd/app 有时报找不到包？
常见原因是当前目录不在模块根目录下，或者 import 路径写死了相对路径（如 "myapp/internal/handler"），但 go.mod 里定义的 module 名是 example.com/myapp，导致导入路径不匹配。
- 始终在
go.mod所在目录执行构建命令，不要 cd 进cmd/app再跑go build -
import必须用完整模块路径，比如example.com/myapp/internal/handler，而不是internal/handler -
go build默认只编译当前目录下的main包；指定路径时，路径必须指向含package main的目录，不能指向.go文件
真正容易被忽略的是：internal 的作用不是“代码放这里就安全”，而是靠 Go 编译器强制拦截跨模块引用；如果你把本该放 pkg 的通用逻辑塞进 internal，等哪天要抽出来单独发布，就得重写所有 import 路径和测试用例。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
