Go Workspace是解决Echo多模块依赖最干净的方式，它让service_a直接引用本地lib_b而无需replace指令，但要求go.work显式列出所有模块、路径相对正确、module声明与import路径严格一致，否则会静默忽略修改或报错。
Go Workspace 是解决 Echo 项目多模块依赖最干净的方式——它让 service_a 直接引用本地 lib_b，无需 replace 指令，也不用反复 go mod tidy 同步版本。但前提是路径、go.work 和模块初始化顺序必须对齐，否则 go run 会静默忽略本地修改，或报 cannot find module providing package。
go.work 文件必须显式包含所有参与模块
Workspace 不会自动发现子目录下的模块，必须手动列出。常见错误是只写 go work init ./service_a，漏掉 ./shared 或 ./infra，导致 Echo 服务启动时找不到本地工具包。
-
go work init后立即检查生成的go.work内容，确认每个模块路径都存在且可读 - 路径必须是相对于
go.work所在目录的相对路径，不能用../other-repo - 如果模块名含大写字母（如
github.com/your-org/MyLib），确保其go.mod中module声明与导入路径完全一致，否则 Echo 的go build阶段会失败
Echo 服务模块中 import 路径必须匹配 go.mod module 声明
假设你在 service_api/go.mod 里写了 module github.com/your-org/service_api，那么它想用 shared/util，就必须在 shared/go.mod 中声明为 module github.com/your-org/shared，并在 service_api/main.go 中写 import "github.com/your-org/shared/util" —— 不能简写成 "shared/util"，也不能用本地文件路径。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- Go Workspace 不改变 import 语义，只改变模块解析优先级：先查
go.work列出的本地路径，再查 proxy - IDE（如 GoLand）可能缓存旧 import 补全，删掉
go.sum和vendor/（如有）后重新go mod vendor或关闭 vendor 模式 - 运行
go list -m all可验证当前解析的是本地路径还是远程版本；本地模块应显示为github.com/your-org/shared v0.0.0-00010101000000-000000000000这类伪版本
Echo 中间件或 handler 引用跨模块代码时需注意构建约束
比如你在 shared/middleware/auth.go 定义了一个函数 JWTAuth()，返回 echo.MiddlewareFunc，但在 service_api 中调用时报类型不匹配，大概率是因为两个模块用了不同 minor 版本的 github.com/labstack/echo/v4。
- 所有模块应共用同一份 Echo 依赖：在 workspace 根目录运行
go get github.com/labstack/echo/v4@v4.12.0，而非各模块单独go get - 避免在
shared模块中直接 importecho.Context并暴露 handler 函数——这会让shared强耦合于 Echo；更适合定义纯逻辑函数（如VerifyToken(token string) (string, error)），由 service 层包装为中间件 - 若必须共享中间件，建议把
echo放入shared/go.mod的require，并加注释说明“此模块仅被同 workspace 下的 Echo 服务使用”
真正容易被忽略的是：Workspace 下的 go test 默认不识别其他模块的 init() 函数或全局变量初始化顺序，尤其当 shared/config 依赖 shared/log，而测试又跑在 service_api 目录下时——此时必须显式用 go test ./shared/... 分别验证，不能只信根目录的 go test ./...。
