Go的flag.Bool不支持--flag无值写法，必须显式传--flag=true/false；要实现存在即true语义，需用flag.BoolVar配合手动判断、flag.String解析或自定义flag.Value接口。
flag.Bool 会把未传参的布尔值默认设为 false，但要注意它不支持 “--flag” 这种无值写法
Go 的 flag.Bool 实际上只接受 --flag=true 或 --flag=false 这类显式带值的写法，如果你直接运行 ./app --debug，程序会报错：flag needs an argument: -debug。这不是 bug，而是设计如此——flag.Bool 不处理“存在即 true”的语义。
解决办法是改用 flag.BoolVar 配合 flag.Parse() 后的手动判断，或者更常用的是：用 flag.Bool + flag.Lookup 检查是否被设置过，但更推荐下面这种惯用模式：
- 声明一个 *bool 类型变量，用
flag.Bool注册（返回指针） - 在
flag.Parse()后，检查该指针是否为 nil —— 如果命令行没出现这个 flag，指针就是 nil；如果出现了（无论带不带值），指针非 nil，且值为 true/false - 但注意：即使你写了
--verbose，Go 默认也不会自动赋值 true，必须显式传=true，否则解析失败
用 flag.BoolVar + 自定义逻辑实现 “--flag” 即 true 的行为
真正想支持 --debug、--verbose 这种无参数布尔开关，得绕开 flag.Bool，改用字符串或自定义类型。最轻量的做法是用 flag.BoolVar 配合一个额外的 bool 变量，并在 flag.Parse() 后手动检查 flag 是否被设置：
var debugFlag = flag.Bool("debug", false, "enable debug mode")
func main() {
flag.Parse()
debug := *debugFlag // 注意解引用前要确保 flag.Parse 已执行
}
但这还是不行——因为 --debug 本身无法通过解析。所以实际中大家普遍采用以下方式：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
flag.String接收，比如flag.String("log-level", "info", "set log level")，再做字符串比较 - 或更直接：用
flag.Bool注册两个变体，如--enable-debug和--disable-debug，靠优先级覆盖 - 但最常用、最干净的方案是：用
flag.Set+ 自定义flag.Value实现可选值布尔类型（见下一条）
自定义 flag.Value 实现支持 --flag / --no-flag 的布尔开关
Go 的 flag 包允许你实现 flag.Value 接口（含 Set(string) 和 String() 方法），从而支持类似 --trace、--no-trace、--trace=true 等多种写法。这是生产环境推荐做法，避免歧义且兼容性好。
示例结构：
type BoolFlag struct {
value *bool
}
func (b *BoolFlag) Set(s string) error {
switch strings.ToLower(s) {
case "1", "t", "true", "y", "yes", "":
*b.value = true
return nil
case "0", "f", "false", "n", "no":
*b.value = false
return nil
default:
return fmt.Errorf("invalid bool value %q", s)
}
}
func (b *BoolFlag) String() string { return fmt.Sprintf("%t", *b.value) }
// 使用：
var trace = false
flag.Var(&BoolFlag{&trace}, "trace", "enable request tracing")
- 空字符串
""对应--trace（无等号无值），视为 true -
--no-trace需单独注册另一个 flag，或在Set中识别前缀（如检测s是否以"no-"开头） - 注意：自定义类型必须传指针给
flag.Var，否则修改不会反映到外部变量
别忽略 flag.Parse() 前后顺序和 os.Args 截断问题
flag.Parse() 会修改 os.Args，把已解析的 flag 及其参数从切片头部移除，剩下的是“非 flag 参数”。如果你在 flag.Parse() 前读取 os.Args，或之后还依赖原始参数顺序，就容易出错。
- 所有
flag.Xxx调用必须在flag.Parse()之前完成 - 如果要用
flag.Args()获取剩余参数，请确保在flag.Parse()之后调用 - 子命令场景（如
git commit -m "msg"）中，主命令解析完自己的 flag 后，需用flag.NewFlagSet为子命令新建解析器，并手动传递对应参数片段 - 调试时可用
fmt.Printf("args after parse: %+v\n", os.Args)确认截断是否符合预期
布尔 flag 的易错点不在语法，而在对“存在性”和“值设定”的混淆——Go 不默认把 flag 出现等价于 true，这点和 Python 的 argparse 或 Rust 的 clap 不同，得靠代码逻辑补足语义。
