go mod tidy 后报“no required module provides package”主因是当前目录未被识别为模块根，而非依赖未下载；需确认 go.mod 存在且路径无空格/中文、终端 pwd 在模块根、module 声明合法，并检查 git 合并冲突残留。
go mod tidy 后仍报 “no required module provides package”
这不是模块没下载，而是当前目录没被识别为模块根。Go 不会自动向上查找 go.mod，也不会凭空推断项目边界。
常见错误现象：
- 从 Git 拉下别人分支后，
go run main.go直接报错，但go mod graph显示依赖正常 - 项目目录里有
go.mod，但文件路径含空格或中文（如~/工作/project/go.mod），某些 shell 或 IDE 会静默截断路径 - IDE（如 VS Code）开了多工作区，实际终端 pwd 是父目录而非模块根目录
实操建议：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 先运行
go list -m—— 若输出main或报not in a module，说明不在模块内；cd 到含go.mod的目录再试 - 检查
go.mod第一行是否为module example.com/foo，而不是module .或空行（后者是手动改坏的） - 避免用资源管理器双击打开终端：Windows 上用
Shift + 右键 → “在此处打开 PowerShell 窗口”，macOS/Linux 用cd $(pwd)确认真实路径
多人合并后 go build 失败，提示 import 路径不匹配
根本原因是模块名（module 声明）和实际 import 路径不一致，而 Git 合并时可能把不同人写的 import 语句混在一起，Go 编译器会严格校验。
典型场景：
- A 分支写的是
import "github.com/user/proj/pkg/util"，B 分支写的是import "proj/pkg/util"（旧 GOPATH 风格残留） - 模块名在
go.mod中是module gitlab.example.com/team/proj，但代码里写了import "github.com/team/proj/..." - 某人本地改过
go.mod的 module 名但没提交，Git 合并后go.sum里存着旧路径哈希，导致校验失败
实操建议：
- 统一执行
go mod edit -module gitlab.example.com/team/proj（替换成你的真实模块名），再go mod tidy - 用
grep -r "import \"" . --include="*.go"扫一遍所有 import，人工对齐前缀；别信 IDE 的“自动修复 import”，它可能补错域名 -
go.sum不要手动删——运行go mod verify看哪行不匹配，再go mod download重拉对应模块
CI 构建成功，本地编译却提示 “checksum mismatch”
这不是网络问题，是本地缓存和远程模块内容不一致。Go 用 go.sum 锁定每个依赖的 h1: 哈希，一旦本地 $GOPATH/pkg/mod 里缓存的包被污染（比如手动改过源码、用 replace 临时覆盖后忘了删），就会触发校验失败。
关键点：
-
go clean -modcache会清掉所有已下载模块，下次go build重新拉取——这是最干净的解决方式，但耗时 - 更轻量的做法是只清对应模块：
rm -rf $GOPATH/pkg/mod/cache/download/github.com/user/repo（Linux/macOS）或用资源管理器删对应文件夹（Windows） - 如果用了
replace且未加// indirect注释，go mod tidy会把它当正式依赖写进go.sum，但别人没这个本地路径，必然失败
实操建议：
- 禁止在团队项目中用
replace指向本地路径；必须临时调试时，加注释并确保 PR 描述清楚，合入前删掉 - CI 脚本开头加
go clean -modcache，避免缓存污染影响构建稳定性 - 本地开发可设
go env -w GOSUMDB=off仅用于调试，但切记不要提交该设置到团队环境
合并分支后 go run 正常，go build 却找不到 main 包
这通常是因为 main.go 文件被 Git 合并冲突标记残留干扰了 Go 的包扫描逻辑——哪怕只是多了一行 ，Go 就会跳过整个文件。
容易被忽略的细节：
- VS Code 默认隐藏冲突标记，需打开设置 → “Files: Auto Save” 关掉，再手动保存一次才能看到真实内容
- 某些 Git GUI 工具（如 Sourcetree）合并后自动标记文件为“已解决”，但其实冲突行还在
-
go build不报具体哪行错，只说no Go files in current directory，让人误以为是路径问题
实操建议：
- 合并后第一件事：
git status看是否有未解决的 conflict 文件；若有，用git checkout --ours或--theirs明确选择版本 - 用
grep -n "^>>>>>" *.go快速扫一遍所有 Go 文件 - 如果
main.go确实没问题，检查是否不小心把package main写成了package Main（大小写敏感）或加了空格（package main）
go.mod 语法，而是 Git 合并时那些没被标红、却悄悄改掉的路径引用和缓存状态。每次拉新分支，先 go list -m 和 git status 过一遍，比等编译报错再查快得多。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
