go语言没有预处理器，#ifdef等c风格宏是语法错误，根本无法编译；必须使用//go:build构建约束，在编译期决定文件是否参与构建，实现真正的条件编译。
为什么不能用 #ifdef，而必须用 //go:build
Go 语言压根没有预处理器，#ifdef、#define 这类 C 风格宏在 Go 里是语法错误，直接报 invalid character。这不是“不推荐”，而是根本无法编译通过。真正起作用的是构建约束（build constraints），它不是运行时判断，而是在 go build 阶段就决定哪些 .go 文件进编译流程——文件被彻底排除，不会产生任何冗余代码。
常见错误现象：写了 // #ifdef linux 或 #if GOOS == "linux"，结果编译成功但逻辑没生效——因为这些行被当作文本注释忽略，根本没参与构建决策。
-
//go:build必须紧贴文件顶部，前面最多一个空行或//注释；夹在package和import中间就失效 - 标签名全小写、下划线分隔（如
with_grpc），大小写敏感；Linux≠linux - 旧式
// +build仍可工作，但go vet不检查它，容易写错且难调试
跨平台文件怎么拆，才能让 Linux/macOS/Windows 各走各的逻辑
不要在一个文件里堆 if runtime.GOOS == "windows"，那只是运行时分支，所有平台代码都打进二进制。正确做法是按平台拆成多个同包文件，靠构建标签控制编译范围：
-
syslog_linux.go开头写：//go:build linux，后面跟package main -
syslog_windows.go开头写：//go:build windows -
syslog_darwin.go开头写：//go:build darwin - 共用接口定义放在无构建标签的
syslog.go里（只声明type SysLogger interface{...}）
这样 go build 时，只会选中当前目标平台匹配的那个文件；交叉编译时（比如 Windows 上编译 Linux 版），也只包含 syslog_linux.go，零体积膨胀。
自定义开关（如 dev / prod）怎么启用和验证
用 -tags 参数激活自定义标签，例如：
go build -tags production main.go
对应文件开头写：//go:build production。注意：
- 标签不自动启用，必须显式传
-tags；没传就等价于-tags ""，所有带//go:build xxx的文件都不参与编译 - 验证是否生效：运行
go list -f '{{.GoFiles}}' .，看输出里有没有你期望的文件名；或者加个println("prod mode enabled")在带标签的文件里，观察是否打印 - 组合多个标签用空格：
-tags "debug sqlite"→ 对应//go:build debug sqlite（AND 关系） - 否定写法：
//go:build !test表示“不启用 test 标签时才编译”
GOOS 和 build tag 混用时最容易漏掉的坑
有人想“只在 Linux 且启用 debug 模式时加载日志模块”，于是写：//go:build linux && debug。这本身没问题，但实际执行时容易栽在环境变量上：
-
GOOS=linux go build -tags debug main.go才能命中；如果只设GOOS=linux但忘了-tags debug，该文件就被跳过 -
runtime.GOOS是运行时值，和构建标签无关——它永远返回当前运行系统的值，哪怕你是在 macOS 上交叉编译 Linux 二进制 - 构建标签只管“编译时包含哪些文件”，
GOOS环境变量只影响“生成哪个平台的二进制”，二者独立；混用时务必确认两者都被正确定义
最常被忽略的一点：构建标签的解析发生在 go build 最初扫描阶段，任何后续的 import 或函数调用都无法改变它——写错位置，就等于没写。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
