go的flag包不支持--flag无值写法，必须显式传--flag=true/false；要实现“存在即true”，需用flag.boolvar配合parse后手动判断，或通过指针是否为nil检测是否设置，再统一做语义映射。
Go 的 flag 包本身不支持直接将布尔标志（如 -verbose）“转换”为字符串值（如 "on" 或 "enabled"），必须手动映射。硬编码条件判断或重复写 if flagVerbose { cfg.Mode = "verbose" } 容易漏掉分支、难维护，尤其当标志数量增加时。
用 flag.Bool + 显式条件映射是最安全的写法
不要试图重载 flag.Value 去“自动转字符串”——这会让逻辑分散、调试困难，且无法处理多标志互斥等真实场景。正确做法是：先用 flag.Bool 解析布尔值，再在解析后统一做语义映射。
-
flag.Bool保证类型安全，不会把"true"字符串误转成true（避免strconv.ParseBool的意外行为） - 所有映射逻辑集中在一处（比如一个
configFromFlags()函数），方便加日志、校验或默认 fallback - 支持组合逻辑：例如
-debug和-quiet互斥时，可清晰写if debug && quiet { log.Fatal("conflict") }
示例：
verbose := flag.Bool("verbose", false, "enable verbose logging")
flag.Parse()
var logLevel string
if *verbose {
logLevel = "debug"
} else {
logLevel = "info"
}
避免用 flag.String 模拟布尔标志
有人会写 flag.String("mode", "off", "set mode: on|off")，再手动校验字符串值。这看似灵活，实则引入三类风险：
- 用户输错值（
-mode=oen）导致静默失败或 panic - 丢失布尔语义：无法用
-verbose简写，必须写-mode=on，破坏 CLI 直观性 - 与标准 Go 工具链不一致（如
go build -v是布尔标志，不是字符串）
除非你明确需要三态（on/off/auto），否则别用字符串模拟布尔。
带默认值和环境变量回退时，布尔标志要单独处理
如果配置同时支持命令行、环境变量（如 VERBOSE=1）和默认值，注意布尔解析逻辑不能混用：os.Getenv("VERBOSE") 返回的是字符串，必须用 strconv.ParseBool，而 flag.Bool 是原生布尔。二者语义不等价：
-
flag.Bool的false表示“未设置”，不是“显式设为 false” -
os.Getenv返回空字符串表示“未设置”，但"0"或"false"都应解析为false
推荐分层处理：优先用 flag，未设置时查环境变量，都未设置才用默认值。不要把三者塞进一个 flag.Value 实现里。
最易被忽略的一点：布尔标志的“未设置”状态必须可区分于“显式设为 false”。很多配置库直接覆盖，导致无法实现“环境变量设为 false，但命令行不传该 flag 就用默认 true”的策略。处理时务必保留原始 flag 是否被用户指定的信息。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
