必须。现代 go 项目默认启用模块模式，go mod init 是开启模块支持的唯一入口，不执行会导致 go build、go run 报 cannot find module providing package 错误，因缺失 go.mod 文件无法解析 import 路径。
Go项目初始化时必须执行 go mod init 吗？
必须。现代 Go 项目默认启用模块模式（Module Mode），go mod init 是开启模块支持的唯一入口。不执行会导致 go build、go run 无法解析导入路径，所有依赖报错为 cannot find module providing package。
常见错误现象：刚写完 main.go，执行 go run main.go 却提示找不到标准库以外的包（比如 github.com/gorilla/mux），根本原因就是缺失 go.mod 文件。
-
go mod init后会生成go.mod，其中第一行module github.com/username/projectname就是该模块的导入路径，后续所有import都以此为根 - 模块名不必与 Git 远程地址完全一致，但建议保持一致，否则
go get拉取依赖时容易混淆 - 如果项目已存在
go.mod，再次运行go mod init不会覆盖，而是报错go mod init: go.mod file already exists
Git 提交前该忽略哪些 Go 文件和目录？
不加 .gitignore 直接 git add .，很容易把编译产物、临时文件甚至敏感配置一起提交，污染仓库历史。
标准 Go 项目 .gitignore 至少应包含：
-
/bin/和/tmp/：本地构建生成的可执行文件和临时目录 -
*.exe（Windows）和*_test（Linux/macOS）：测试二进制或平台特有产物 -
go.sum必须提交 —— 它是go.mod的校验快照，删掉会导致依赖校验失败 -
/vendor/一般不提交（除非离线环境强制要求），现代 Go 默认关闭 vendor 模式，go mod vendor是可选操作
注意：go.mod 和 go.sum 是 Git 版本控制的核心文件，它们共同锁定依赖版本，漏提或误删都会导致协作者构建失败。
为什么推荐用 feature/xxx 而不是直接在 main 上开发？
直接在 main（或旧称 master）分支改代码，等于把未验证的功能、未覆盖的 bug 一起推到生产就绪分支，CI 流水线可能通过，但实际不可靠。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
真实协作中，feature/xxx 分支不只是命名习惯，它对应明确的操作约束：
- 每个功能/修复独立分支，便于 Code Review ——
git diff main...feature/login可清晰看到本次变更范围 - 分支名含斜杠（如
feature/user-auth）被 Git 原生支持，GitLab/GitHub 会自动归类为“功能组”，比扁平命名（login-feature）更易过滤和清理 - 合并前必须通过 CI 构建 + 单元测试（
go test ./...），避免main被污染；CI 脚本里通常会检查go fmt和go vet，这些检查在 feature 分支上就能拦截问题
真正容易被忽略的是：分支生命周期管理。没人清理的 feature/old-thing 会堆积，建议在 PR 合并后自动删除远端分支（GitHub/GitLab UI 默认勾选，别手动取消）。
Go 环境变量与 Git 协作时最常踩的坑是什么？
不是 GOROOT 或 GOBIN，而是 GOPROXY 和 GO111MODULE 的本地化设置没纳入团队共识。
现象：A 同学 go build 成功，B 同学拉代码后 go mod download 卡住或报错 no required module provides package，往往是因为：
-
GO111MODULE=off被全局设死（尤其老项目迁移时），导致模块模式失效，依赖全走GOPATH查找 -
GOPROXY没统一 —— A 用https://goproxy.cn，B 用默认官方代理（国内访问极慢），go get超时失败 - 解决方案不是口头约定，而是写进项目根目录的
.envrc（配合 direnv）或Makefile，例如：export GO111MODULE=on<br>export GOPROXY=https://goproxy.cn,direct
真正关键的点在于：Git 不管环境变量，但 Go 构建结果高度依赖它们。把环境配置当作“代码的一部分”来版本化，才能让 git clone && make build 在任何人机器上都行为一致。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
