彻底扫除Golang模块引用自定义本地代码时的常见阻碍-Golang-PHP中文网

根本原因是go mod默认只认远程路径，本地包需用replace映射；正确做法是在go.mod中添加replace mylib => ./mylib并运行go mod tidy，且import路径、module声明、文件目录名必须完全一致。

彻底扫除golang模块引用自定义本地代码时的常见阻碍

根本原因是 go mod 默认只认远程路径（如 github.com/user/repo），你本地写的 mylib 没注册路径映射，Go 就当它不存在。

典型现象：import 语句写的是 "mylib"，go build 报错 cannot find module providing package mylib。

别手动改 go.mod 里 require 行——那是给远程模块用的，填本地路径会触发校验失败
正确做法是用 replace：在 go.mod 末尾加一行 replace mylib => ./mylib（注意路径是相对当前 go.mod 的）
加完必须运行 go mod tidy，否则 replace 不生效，且可能被自动删掉
如果 mylib 本身也有 go.mod，它的 module 声明必须和 import 路径完全一致（比如 module mylib），否则 replace 匹配不上

单项目引用本地库，replace 足够；但多个本地模块互相依赖、又不想发版到远程时，go.work 才是正解。

replace 是 per-module 的，每个子模块都要单独写；go.work 是 workspace 级的，一次定义，全局生效。

用 go work init 在项目根目录生成 go.work，再用 go work use ./mylib ./backend ./frontend 把所有本地模块加进去
go.work 会自动忽略这些模块里的 go.mod 中的 replace，所以要删掉或注释掉它们，避免冲突
启用 go.work 后，go build、go test 都默认走 workspace 模式——不需要额外 flag
CI/CD 通常不支持 go.work，上线前得切回纯 go.mod + replace 或发布到私有 proxy

Go 不允许 import 路径和实际文件系统路径不一致。哪怕只差一个 / 或大小写，都会在 go mod vendor 或交叉编译时出问题。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

常见错误：代码里写 import "MyLib"，但文件夹叫 mylib；或者 go.mod 声明 module github.com/u/p，却在代码里 import "p/sub" 而不是 "github.com/u/p/sub"。

import 路径必须和目标模块的 module 声明完全一致（包括协议、域名、大小写）
本地开发时，可以用 replace 或 go.work “骗过” Go，但 import 语句本身不能乱写——它决定了符号解析和 vendor 目录结构
检查方式：进目标模块目录，执行 go list -m，输出就是你该写在 import 里的路径
IDE（如 VS Code + Go extension）有时会自动补全错误路径，补完务必人工核对

go mod vendor 本质是把依赖“快照”进 vendor/ 目录，但它只处理 require 列表里的模块，replace 是构建期指令，不参与 vendor。

结果就是：vendor 目录里没有你的本地模块，build 时找不到包。

方案一：不用 vendor，直接 go build -mod=readonly（推荐，现代 Go 已很少需要 vendor）
方案二：用 go mod vendor 之前，先确保本地模块已发布到私有 proxy，并在 go.mod 中用真实路径 require 它，再删掉 replace
方案三：硬拷贝——cp -r ../mylib vendor/mylib，然后在代码中 import "vendor/mylib"（不推荐，破坏模块语义）
关键点：vendor 和 replace 天然互斥，选一个就好，混用必踩坑