根本原因是go111module=on下go强制要求import路径必须匹配模块路径，禁止相对路径或gopath式导入；正确做法是用replace指向含合法go.mod的本地目录，再执行go mod tidy并重载项目。
GoLand 里 import 本地第三方包报错：no required module provides package
根本原因是 GoLand 默认启用模块模式（GO111MODULE=on），而你试图用相对路径（如 ./third_party/mylib）或硬编码本地路径导入——Go 拒绝这种写法，它只认模块路径。
这不是 IDE 的 bug，是 Go 工具链的强制规则：所有 import 路径必须能被 go mod 解析为有效模块路径，否则编译器直接报错。
- 别在代码里写
import "./third_party/mylib"或import "mylib" - 别把第三方源码直接扔进
src/下靠 GOPATH 找——GO111MODULE=on时 GOPATH 失效 - 别手动改
go.mod添加replace后不运行go mod tidy，依赖树不会更新
用 replace 替换模块路径指向本地目录
这是最常用也最稳妥的方式，适用于调试 fork 后的第三方库、尚未发布到远程仓库的内部 SDK，或需要 patch 某个依赖。
假设你有个本地副本放在 ~/dev/my-forked-gin，想让项目使用它而非官方 github.com/gin-gonic/gin：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 在项目根目录执行：
go mod edit -replace github.com/gin-gonic/gin=~/dev/my-forked-gin - 运行
go mod tidy，Go 会拉取该路径下go.mod中声明的模块名，并校验go.sum - 代码中仍写
import "github.com/gin-gonic/gin"——路径不变，只是底层加载来源被替换了 - 确保
~/dev/my-forked-gin目录下有合法的go.mod（模块名必须与原路径一致，比如module github.com/gin-gonic/gin）
GoLand 需要额外配置才能识别 replace 后的本地包
即使 go build 能成功，GoLand 可能仍标红、跳转失败、补全缺失——因为它没主动 reload replace 规则。
- 打开 Settings → Go → Go Modules，确认勾选 Enable Go Modules integration
- 点击 Reload project（不是“Sync”），或右键项目根目录选 Reload project
- 如果还无效，在终端执行
go mod vendor，然后在 Settings 里勾选 Use vendor directory - 避免在
GOROOT或GOPATH下手动创建src/子目录放本地包——这和模块模式冲突，GoLand 会混淆
不要用 GOPATH 模式混搭本地第三方包
有人试过把本地包拷到 $GOPATH/src/github.com/xxx/yyy 然后关掉模块模式，但这在 GoLand 中极易出问题：
- GoLand 默认强制启用模块模式，关闭它需全局设置
GO111MODULE=off，但 2026 年主流工具链已弃用该模式 - 多个项目共用一个 GOPATH 会导致包版本污染，尤其当你同时开发几个用不同 gin 版本的项目时
- Git 提交时容易漏掉
go.mod和go.sum，协作时别人拉代码直接编译失败 - GoLand 的索引、跳转、重构功能在 GOPATH 模式下对跨项目引用支持弱，常卡住或误报
真正麻烦的不是怎么让代码跑起来，而是让 IDE 和 go 命令行达成一致——只要 replace + go mod tidy + IDE reload 这三步做全，本地第三方包就能被正确识别和补全。漏掉任意一环，都会卡在“找不到包”的假象里。
