go.work文件必须显式use有效目录才不被忽略：空文件无效，仅支持目录路径（非通配符/文件/模块名），当前目录未被use时退回到单模块模式，ci中应使用绝对路径生成。
go.work 文件怎么写才不被忽略
Go 工具链只有在当前目录或其父目录存在 go.work 且你显式启用工作区时，才会真正加载它。很多构建失败或本地修改不生效，根源就是 go.work 被静默跳过。
- 运行
go work init后必须手动添加use目录，空的go.work不起作用 -
use只接受目录路径，不能是文件、通配符或模块名；比如use ./cmd/api合法，use ./cmd/*或use example.com/cmd/api都无效 - 如果当前工作目录在
./pkg/storage里，而该目录没被列进go.work的use列表，Go 就退回到单模块模式——此时replace可能还在生效，但跨模块 import 会报cannot load - CI 环境中建议用绝对路径生成
go.work，避免因工作目录差异导致解析失败
增量编译为什么没生效
Go 默认支持增量构建，但在 Monorepo 中常被破坏，不是工具不行，而是配置或结构踩了坑。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
go build本身不感知go.work，它只看当前模块的go.mod；真正触发跨模块增量的是go list -m all -work+ 构建工具链（如make或自定义脚本）的配合 - 每个子模块必须有独立的
go.mod，且module声明与实际 import 路径严格一致；否则 Go 无法识别哪些包属于“已变更”范围 - 不要依赖
vendor/实现增量——vendor锁死的是快照，不是依赖图；改了./lib/util，./cmd/api却不重建，大概率是因为go.mod里没声明对lib/util的 require - IDE（如 Goland）默认不读
go.work，需手动开启 “Enable Go Workspaces” 选项，否则代码跳转和类型检查会断连
replace 和 go.work 能不能共存
能共存，但优先级和行为完全不同：前者是模块替换，后者是模块发现。混用时容易误判谁在起作用。
-
replace在go.mod里写，只影响该模块及其子模块的依赖解析；go.work的use是全局工作区视图，影响所有参与模块 - 如果一个模块既在
go.work的use列表里，又在主模块go.mod中被replace指向本地路径，Go 会优先走go.work——replace被忽略 - CI 环境禁止用相对路径
replace（如replace example.com/lib => ./lib），因为执行路径不确定；应统一改用file:///abs/path/to/lib或直接删掉replace，靠go.work管理 - 子模块自己的
go.mod里的replace不会自动继承到工作区；主模块若要覆盖，必须在自己go.mod里显式require并replace
按服务构建时如何避免全量重编
所谓“按服务构建”，本质是控制构建粒度；Go 没有原生 service-level 缓存，得靠目录隔离 + 显式依赖声明 + 构建脚本协同。
- 每个服务目录（如
./cmd/api）必须有独立go.mod，且只require它真正用到的模块；不要把整个./pkg全部 require 进来 - 公共库（如
./pkg/storage）的变更，只会触发明确依赖它的服务重建；前提是这些服务的go.mod里写了require example.com/pkg/storage v0.0.0-00010101000000-000000000000这类伪版本 - Makefile 或 shell 脚本里别写
go build ./...，改用go build ./cmd/api——省略路径会强制扫描整个树，破坏增量判断 - 构建产物（binary）建议按服务输出到独立目录，如
./dist/api，避免文件时间戳污染干扰下次增量判断
go.mod 未同步更新、或构建命令没限定作用域。工作区和模块文件不是装饰，是 Go 解析依赖图的唯一依据。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
