go mod init 后找不到本地依赖是因为默认只识别远程路径，需用 replace 指向本地相对路径（如 replace example.com/user/auth => ../auth），上线前替换为真实 git tag。
go mod init 后为什么找不到本地依赖？
微服务拆分时，常把公共包抽成独立仓库，但本地开发阶段还没推 Git，go mod init 默认只认远程路径，直接 go get 会报 module not found 或走代理拉错版本。
解决方法不是硬改 go.mod，而是用 replace 指向本地路径：
- 在主模块的
go.mod末尾加一行：replace example.com/user/auth => ../auth（路径必须是相对当前go.mod的真实路径） -
replace只在当前模块生效，不影响下游；上线前删掉它，改用真实 Git tag - 别用绝对路径——CI 环境会失效；也别指向
vendor/，Go Modules 下vendor是只读缓存
多个服务共用一个 domain 包，怎么避免版本冲突？
拆成微服务后，user-service 和 order-service 都依赖 example.com/domain，但各自 go.mod 锁定的 domain 版本不同，运行时可能 panic：结构体字段不一致、方法签名变了。
核心原则是「单源版本控制」：
- 所有服务的
go.mod中，domain必须通过同一 Git 仓库 + 相同 tag（如v1.2.0）引入，不能一个用v1.2.0，另一个用master分支 - 发版时先
git tag -a v1.2.0 -m "domain: add OrderStatus"推送，再在各服务里go get example.com/domain@v1.2.0 - 禁止在
domain里做 breaking change；新增字段用指针，旧字段别删——Go 没有 schema migration 工具，靠人守规矩
go build -o 生成的二进制为什么启动报错：cannot find module providing package？
这是典型的构建环境与运行环境 GOPATH/GOMODCACHE 不一致导致的。本地 go build 成功，但扔到 Docker 或另一台机器就崩，错误信息里常带 cannot find module 或 missing go.sum entry。
mallcloud商城基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba并采用前后端分离vue的企业级微服务敏捷开发系统架构。并引入组件化的思想实现高内聚低耦合，项目代码简洁注释丰富上手容易，适合学习和企业中使用。真正实现了基于RBAC、jwt和oauth2的无状态统一权限认证的解决方案，面向互联网设计同时适合B端和C端用户，支持CI/CD多环境部署，并提
根本原因是 Go 编译器不打包依赖，只记录路径，运行时靠 GOROOT 和 GOPATH 查找模块。
- 用
go build -trimpath -ldflags="-s -w"构建，去掉调试信息，但不解决路径问题 - 真正可靠的是静态编译：确保
CGO_ENABLED=0，再go build，生成纯静态二进制，不依赖系统libc或模块缓存 - Dockerfile 里别用
FROM golang:alpine构建完再COPY二进制——那只是省镜像体积，没解决运行时依赖查找逻辑
gomod vendor 能不能替代多仓库协作？
不能。有人想用 go mod vendor 把所有依赖打进本地 vendor/ 目录，以为这样就能脱离 Git 仓库协作，结果上线后发现：vendor 只是快照，不解决跨服务接口契约问题。
比如 auth-service 更新了 Token.Verify() 返回值，但 user-service 的 vendor/ 还是旧版，编译不报错，运行时 panic。
-
vendor是构建时优化手段，不是版本治理方案；它冻结的是「代码副本」，不是「接口契约」 - 微服务间通信靠 API 协议（HTTP/gRPC），不是 Go 包引用；
domain包只应放共享类型定义，不含业务逻辑 - CI 流程里加一步：
go list -m all | grep domain，确保所有服务引用的domain版本字符串完全一致
最麻烦的永远不是怎么拆，而是拆完之后谁来对齐每个服务里的 go.mod 里那一行 example.com/domain v1.x.y——它得手动核对，没法全自动。
