go.mod损坏本质是Go模块系统对语法、路径、环境变量高度敏感所致；应禁用GO111MODULE=off，用go fmt -mod=mod修复格式或删行重装，避免手动改indirect、混用replace/exclude，并通过go mod graph和go list验证依赖一致性。
go.mod 文件在 Fiber 安装过程中损坏，本质不是 Fiber 的问题，而是 Go 模块系统对语法、路径、环境变量高度敏感导致的连锁反应。直接删掉重来往往最快，但得知道为什么删、删完怎么补、哪些地方一动就崩。
go get 后 go.mod 语法错位：空格/换行/indirect 错乱
手动编辑过 go.mod，或 go get 过程被中断，容易让 require 行出现不可见错误：比如版本号前多一个空格、路径和版本号被硬换行切开、indirect 标记被误删或误加。
- 典型报错：
go: malformed module path "github.com/gofiber/fiber/v2": invalid char "@"或go: errors parsing go.mod - 别手改 —— 运行
go fmt -mod=mod自动修复格式（它只清理空白符，不改语义） - 如果仍报错，直接删掉整行
require github.com/gofiber/fiber/v2，再执行go get github.com/gofiber/fiber/v2重拉 -
indirect不要自己加或删：它由go mod tidy自动判断，手改后可能让依赖降级或引入冲突
GO111MODULE=off 环境下强行写入 go.mod 导致模块失效
如果你在 GO111MODULE=off 状态下执行了 go get，Go 工具链会忽略 go.mod，但又可能往里写内容，造成文件存在却完全不生效。
- 先确认当前状态：
go env GO111MODULE，如果不是on，立刻执行go env -w GO111MODULE=on - 再删掉现有
go.mod和go.sum，重新go mod init your-module-name - 注意：Go 1.21+ 已默认开启模块模式，
GO111MODULE只用于显式关闭 —— 所以除非你明确关过，否则大概率是终端环境变量没继承到
replace 与 GOPROXY 冲突引发校验失败
安装 Fiber 时用了 replace 指向本地 fork，又没配好 GOPROXY 或 GONOSUMDB，会导致 go.sum 记录原始模块哈希，但构建时加载的是本地路径，校验直接失败。
- 现象：执行
go build报missing go.sum entry或checksum mismatch - 临时解法（仅调试）：
go env -w GOSUMDB=off，但上线前必须恢复 - 正解：删掉
replace行，用go get github.com/gofiber/fiber/v2@commit-hash拉指定 commit；如确需本地开发，确保GOPROXY配置含directfallback，且go.sum用go mod tidy -v重新生成 - 别混用
exclude和replace—— Go 会静默忽略exclude，但构建逻辑会变混乱
模板或中间件依赖引发隐性 require 冲突
Fiber v2 默认不带模板引擎，但如果你顺手装了 github.com/gofiber/template/html，它可能间接拉入旧版 golang.org/x/net 或 golang.org/x/text，和 Fiber 主体依赖的版本打架，导致 go.mod 被反复修改、indirect 标记飘忽不定。
- 检查是否真需要该模板：
go mod graph | grep template查来源；若只是试用，删掉相关 import 和go get记录 - 统一用
go mod tidy -v（加-v看详细过程），观察哪些包被“悄悄”加上了indirect - 如果
go.mod里出现大量golang.org/x/...且版本不一致，优先升级 Go 版本（Fiber v2 推荐 Go 1.21+），再跑一遍tidy
最危险的修复动作，其实是“以为修好了”——go.mod 表面能 build，不代表依赖图干净。每次修复后，务必跑一次 go mod graph | grep fiber 确认 Fiber 相关路径唯一，再用 go list -m all | grep fiber 看实际加载的版本。模块系统不报错，不等于没埋雷。
