go项目必须以go mod init为起点，模块名需用域名前缀且小写无下划线；package main和func main()缺一不可；依赖须通过import+go mod tidy管理，go.sum必须提交；编译参数应统一收敛至脚本，交叉编译依赖goos/goarch环境变量。
Go 项目能跑起来，不等于环境初始化到位；go run main.go 成功，不代表编译参数、模块结构、依赖校验都可靠。现代 Go 工程必须以 go mod init 为起点，否则后续 CI/CD、多平台构建、依赖锁定都会出问题。
go mod init 是唯一合法的初始化入口
Go 1.11+ 默认启用 module 模式，不执行 go mod init 就写代码，go build 或 go run 会直接报错：go: cannot find main module。这不是警告，是硬性失败。
- 模块名建议用域名前缀（如
github.com/yourname/project），避免纯短名（如myapp）——后者在引入本地子模块时会触发路径解析冲突 - 模块名不能含大写字母或下划线，否则
go mod tidy会拒绝写入go.mod - 已有错误
go.mod时，删掉重来；手动改module行或用go mod edit极易破坏语义，导致go list -m all输出异常 - 执行后生成的
go.mod必须提交 Git，它是模块解析的唯一权威来源
package main 和 func main() 缺一不可
Go 不允许裸代码，也不接受无主函数的可执行文件。漏掉 package main，go build 报 no Go files in current directory；漏掉 func main()，报 missing main function。
- 文件名任意（不强制叫
main.go），但必须在同一目录下且同属package main - 多个
.go文件共存于同一目录时，只要都声明package main，go run .就能自动识别全部 -
import的包若未被实际使用，编译直接失败——这是 Go 的强约束，不是警告
go mod tidy 是依赖同步的唯一可信方式
不要用 go get 单独拉包，除非你明确要指定版本（如 go get github.com/gin-gonic/gin@v1.9.1）。日常开发中，所有依赖应通过代码里写 import + 运行 go mod tidy 自动完成。
-
go mod tidy会：下载兼容版本、写入go.mod、更新go.sum、清理未使用依赖 -
go.sum必须提交 Git——它记录每个依赖的哈希值，删掉会导致go build失败（校验不通过） - 内网环境必须提前配好
GOPROXY，否则tidy卡在 fetch 阶段，无超时、无提示
全局编译参数应统一收敛到构建脚本或 Makefile
Go 本身不提供“全局编译参数配置文件”，go build 的 -ldflags、-gcflags、-tags 等必须显式传入。硬编码在 CI 脚本或 Makefile 中，比散落在各处的 go build 命令更可控。
- 常见参数组合示例：
go build -ldflags="-s -w -X main.version=1.2.0" -o bin/app ./cmd/app -
-s（strip symbol table）和-w（disable DWARF debug info）通常一起用，减小二进制体积 -
-X用于注入变量（如版本号、构建时间），但只支持string类型，且目标变量必须是未导出的全局变量（如var version string） - 交叉编译靠
GOOS/GOARCH环境变量控制，而非go build参数；设错会导致静默生成错误架构的二进制
最容易被忽略的是 go.sum 提交和 GOOS/GOARCH 的环境变量作用域——它们不写进任何配置文件，全靠开发者意识和脚本固化。一旦漏掉，本地能跑，CI 就挂。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
