必须用 Build Tags 隔离平台专属代码，否则因跨平台符号缺失导致编译失败；//go:build 失效最常见原因是缺空行或未并存 // +build，且 GoLand 调试需手动配置 Tags。
必须用 Build Tags 隔离平台专属代码，否则编译会失败——runtime.GOOS 判断只能用于运行时逻辑分支，不能解决跨平台符号缺失问题。
为什么 //go:build linux 写对了却没生效
最常见原因是注释后缺空行，或混用了新旧语法。Go 要求构建约束必须紧贴文件顶部，且 //go:build 行之后**必须紧跟一个空行**，再写 package；同时，为兼容旧工具链，// +build 必须与 //go:build 并存、内容一致。
- 错误写法：
//go:build linux后直接跟package main（无空行 → 被当普通注释） - 错误写法：只写
//go:build linux，不写// +build linux（部分 CI 工具链仍依赖旧语法） - 正确结构：
//go:build linux || darwin // +build linux darwin package main
注意：// +build 中空格表示 OR，逗号表示 AND；而 //go:build 用 || 和 && 更清晰，推荐统一用这种写法。
go build -tags 的参数行为和陷阱
-tags 参数不是“启用某标签”，而是“声明当前构建满足哪些标签条件”；它和源码中 //go:build 的逻辑是匹配关系，不是开关。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 命令
go build -tags linux表示“本次构建目标是 Linux”，因此只会编译含//go:build linux或//go:build linux || darwin的文件，跳过//go:build windows - 多个标签用空格分隔：
-tags "linux amd64"表示 AND（仅 Linux + AMD64），不是 OR - 想表达 OR，必须写在文件约束里，比如
//go:build dev || test，再用-tags dev或-tags test触发 - 别在
-tags里传!windows—— 这个否定逻辑应写在源码约束中，命令侧只传正向标签
GoLand 调试时 Build Tags 不起作用的真正原因
GoLand 默认不读取源码里的 //go:build，它只认你在 Run Configuration 里显式填的 Tags。即使 go build -tags linux 能跑通，GoLand 点三角运行也会忽略该约束。
- 必须进 Run → Edit Configurations… → Go Build，在 Tags 输入框填纯 tag 名，如
linux debug（空格分隔，无引号、无逗号、无//go:build前缀） - 多个 tag 是 OR 关系：
linux darwin表示“Linux 或 Darwin”，不是“Linux 且 Darwin” - 别把
debug塞进 Defaults → Go Build，否则所有运行/测试都带它；应单独建一个名为Debug with debug的配置 - 交叉编译（如
GOOS=windows go build）和 Build Tags 是两套机制，GoLand 的 Tags 框不处理GOOS，需额外在 Environment variables 里设
用 //go:build ignore 安全跳过文件
想临时屏蔽某个 .go 文件参与构建？别删它、别注释掉函数，用构建约束最干净。
- 在文件顶部写：
//go:build ignore // +build ignore package unused
然后构建时加 -tags ignore，该文件就彻底不出现在编译流程里。
- 这比
//go:build !linux更可控——后者依赖你记得所有可能的GOOS值，而ignore是主动、明确的排除 - 适用于 CI 脚本中跳过本地调试专用文件（如
mock_db.go）、或禁用某版本驱动（如sqlite.go在生产构建中） - 注意：该文件仍会被
go list、go vet扫描，如需完全跳过 lint，得配合//nolint或 .golangci.yml 规则
实际项目里，最容易被忽略的是空行要求和 GoLand 的 Tags 配置分离——这两点出错，会导致“代码明明写了约束，却总被错误包含或排除”，排查起来极耗时间。
