根本原因是go build未在go.work所在根目录执行，go工具链仅在此目录启用工作区模式；cd入子模块后退化为单模块逻辑，无视use声明。
go.work 里 use 了子模块，为什么 import 还报错“module not found”
根本原因不是路径写错，而是 go build 没在工作区根目录执行。Go 工具链只在含 go.work 的目录下才启用工作区模式；一旦 cd 进某个子模块再运行 go build，它就退回到单模块逻辑，完全无视 go.work 中的 use 声明。
实操建议：
- 所有构建命令（
go build、go run、go test）必须在go.work所在目录下执行，不要cd进子目录 - 确认
go.work文件中use ./xxx的路径是相对于该文件所在目录的，不能带../或绝对路径 - 子模块自身
go.mod中若还保留着旧的require行（比如require example.com/lib v0.1.0），必须删掉——工作区模式下，本地模块直接加载，不需要版本声明
子包 import 路径写成 "./utils" 或 "utils" 就失败
Go 模块机制下，import 路径必须是「模块名 + 子路径」，和文件系统相对路径无关。哪怕 utils/ 就在当前目录下，import "./utils" 或 import "utils" 都非法，会触发 import path does not begin with hostname 或 no required module provides package 错误。
实操建议：
- 查清
go.mod第一行的module声明（如module github.com/user/myapp），那么utils/包的合法 import 就是"github.com/user/myapp/utils" - 子包目录名不必和包名一致，但 import 路径必须匹配模块路径；包内
package utils只影响你代码里怎么用这个包，不影响 import 字符串 - IDE 提示找不到包？检查 VS Code 是否以含
go.mod的目录为根打开，而不是父目录；必要时按Ctrl+Shift+P→Go: Restart Language Server
replace 和 go work use 同时存在，哪个生效
replace 优先级永远高于 go work use。只要子模块自己的 go.mod 里写了 replace github.com/user/lib => ../lib，即使 go.work 中已 use ./lib，Go 仍会走 replace 规则——而且它会尝试解析 ../lib，如果路径不存在或没 go.mod，就直接报错。
实操建议：
- 开发阶段统一用
go work use，删掉所有子模块go.mod中的replace行 -
go work use是工作区级静态绑定，只要目录结构不变，就一直有效；而replace是模块级硬编码，每次挪动目录都要手动改 - 运行
go list -m all查看实际加载路径：若看到某模块后缀带=> ./xxx，说明go work use生效；若带=> ../yyy，说明replace还在起作用
多模块互相引用时，import cycle 不是模块问题，是包设计缺陷
工作区模式不会自动切断循环依赖。A 模块 import B，B 又 import A，Go 编译器直接拒绝，错误是 import cycle not allowed。这不是 go.work 配置不对，而是包层级之间出现了双向强耦合。
实操建议：
- 用
go mod graph | grep 'module-a\|module-b'查出真实依赖链，定位哪两个包在互相拉对方 - 把共享的常量、错误类型、基础结构体抽出来，放到一个独立的
shared模块里，让 A 和 B 都import "github.com/user/shared" - 避免在
internal/下放跨模块共享代码——internal对其他模块不可见，强行引用会导致编译失败
go work use 让模块 A 能直接调模块 B，就等于它们能自由互引，但 Go 的 import cycle 检查和 internal 规则依然严格生效，且不因工作区而放宽。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
