go mod init 路径须与最终导入路径一致，推荐直接使用 GitHub 地址如 github.com/username/myapp；cmd/ 存放 main 包，internal/ 存放私有代码且不可被外部 import；单模块项目无需 go.work；Makefile 可统一构建流程，需声明 .PHONY。
go mod init 是初始化项目的第一步，但路径必须与预期导入路径一致
Go 项目依赖的模块路径（即 import 语句中写的包路径）会直接影响 go mod init 的行为。如果执行 go mod init myapp，后续所有 import "myapp/xxx" 都必须匹配这个名称；若实际想发布到 GitHub，应直接用真实路径：go mod init github.com/username/myapp。
常见错误是本地随便起名，等要 push 到远程仓库时发现 import 路径和 URL 不一致，导致其他项目无法正确 go get。
- 在项目根目录执行，不是在
src或cmd下 - 模块名建议与 Git 远程地址保持一致（如
github.com/user/r）
epo
- 若暂无远程地址，可用内部域名或占位符（如
example.com/myapp），但上线前必须替换
标准目录结构里 cmd/ 和 internal/ 的职责不能混用
cmd/ 存放可执行命令的 main 包，每个子目录对应一个二进制文件；internal/ 存放仅本模块使用的私有代码，Go 编译器会阻止外部模块 import 它们。这两个目录不是“约定俗成”，而是 Go 工具链强制识别的语义目录。
把业务逻辑塞进 cmd/myapp/main.go 看似省事，但会导致无法被测试、无法被其他命令复用、也无法被 go list -f '{{.ImportPath}}' ./... 正确扫描。
-
cmd/myapp/main.go只做参数解析、依赖注入、启动服务，逻辑控制权交给internal/或pkg/ -
internal/handler和internal/service是常见分层，但命名按团队理解即可，关键是不暴露给外部 - 不要在
internal/里放main函数，否则go build会报错
go.work 适合多模块协同开发，但单模块项目不必强加
当项目拆分成多个 go.mod 模块（如 api/、core/、cli/），且需要本地联调时，go.work 能绕过 replace 指令，直接映射本地路径。但它不是必需品——单模块项目加了反而增加认知负担。
错误做法是新建项目就跑 go work init，结果发现 go run 行为异常，因为工作区会覆盖当前模块的 go.mod 解析逻辑。
- 只有明确需要同时修改多个本地模块时才引入
go.work -
go.work文件需手动维护，添加新模块要用go work use ./xxx - CI 流水线通常禁用
go.work，确保构建环境只认go.mod
Makefile 不是必须，但能统一 dev/test/build 流程
Go 原生命令足够完成构建，但不同开发者对 go test -race、go vet、gofmt -l -w 的执行顺序和参数偏好不一。一个轻量 Makefile 能收敛这些差异，且比 shell alias 更易共享和 CI 复用。
别写成“全自动 IDE 替代品”：不需要封装 go run 启动调试，也不必集成 lint 自动修复。重点是让 make test 和 make build 在任意机器上行为一致。
build: go build -o bin/myapp ./cmd/myapp test: go test -race -v ./... fmt: gofmt -l -w . .PHONY: build test fmt
真正容易被忽略的是 .PHONY 声明——没有它，当项目下恰好生成了叫 test 的文件时，make test 就会静默跳过。
