Go module路径解析失败时应先检查go.mod首行module声明是否含非法字符，如中文、空格、特殊符号或BOM头，因Go要求模块路径仅允许字母、数字、点、短横线、下划线及斜杠，且须以字母或数字开头。
Go module 路径解析失败时先看 go.mod 里的模块路径是否含非法字符
Go 的模块路径（module 声明）必须是合法的 URL 片段，不能含空格、中文、全角标点、emoji 或其他非 ASCII 可打印字符。一旦 go.mod 里写成 module my-project/你好 或 module github.com/user/my-app v1.0（末尾带空格），go build 或 go mod tidy 就会报类似 invalid module path "my-project/你好": malformed module path 的错误。
这类问题不是编码格式（UTF-8 vs GBK）导致的，而是 Go 解析器对模块路径有严格语法限制：只允许字母、数字、点、下划线、短横线，以及斜杠（仅用于分隔），且必须以字母或数字开头。
- 检查
go.mod第一行module声明，用cat go.mod | head -n1快速确认 - 用
xxd go.mod | head -n2查看十六进制，确认是否有隐藏的零宽字符（如U+200B）或 BOM 头 - Windows 用户尤其注意：编辑器可能自动插入 UTF-8 BOM，Go 不接受带 BOM 的
go.mod
本地开发用 replace 绕过非法路径依赖，但别提交到仓库
如果你依赖一个路径含中文或特殊字符的私有模块（比如公司内部 Git 仓库地址含中文路径），go get 会失败。此时不能改对方仓库的 go.mod，但你可以在自己项目里用 replace 显式映射为合法路径。
例如对方模块声明是 module example.com/项目A/v2，你在自己的 go.mod 加：
立即学习“go语言免费学习笔记（深入）”；
replace example.com/项目A/v2 => ./local-fix-project-a
然后把对方代码拷贝到 ./local-fix-project-a 目录，并手动改其 go.mod 中的 module 行为合法路径（如 module example.com/project-a/v2）。
-
replace是临时调试手段，CI 环境通常不认本地路径，所以不能提交replace到主分支 - 如果要用 Git 仓库替代，确保远程地址本身不含非法字符（如用英文重命名 GitLab/GitHub 仓库路径）
-
go mod edit -replace命令比手写更安全，避免拼写错误
GO111MODULE=on 环境下，vendor 目录不会缓解路径解析问题
有人以为开启 vendor 就能绕过模块路径校验，其实不行。Go 在构建前仍会完整解析 go.mod 和所有依赖的 module 声明 —— 即使那些模块已存在 vendor/ 里。vendor 只影响源码来源，不影响路径合法性检查。
-
go mod vendor执行失败，往往就是某个依赖的go.mod本身非法，得顺藤摸瓜找到源头模块 - 用
go list -m all 2>&1 | grep "malformed"可快速定位哪个模块触发解析失败 - 禁用模块模式（
GO111MODULE=off）虽能跳过校验，但会退化为 GOPATH 模式，无法正确处理版本和replace，不推荐
CI/CD 流水线中要统一文件编码和换行符
开发者本地用 VS Code 编辑 go.mod 没问题，但 Jenkins 或 GitHub Actions 里执行 go mod download 却失败，常见原因是 Git 提交时自动转换了换行符或编辑器保存用了 UTF-8 with BOM。
- 在项目根目录加
.gitattributes，强制go.mod用 LF 和 UTF-8 without BOM：go.mod text eol=lf charset=utf-8 - CI 脚本开头加检查：
file go.mod应输出go.mod: UTF-8 Unicode text，而非with CRLF line terminators或with UTF-8 Unicode (with BOM) text - Go 1.19+ 对 BOM 更敏感，旧版可能侥幸通过，升级后突然失败，这点容易被忽略
路径解析失败从来不是 Go 的 bug，而是它对模块路径做了明确而严格的定义。修复的关键永远是让 module 声明回归 URL-safe 字符集，而不是尝试解码或转义。
