Go strconv.ParseBool 怎样兼容配置里的 yes/no 字符串

配置文件里的布尔值经常写成 yes/no，但把这两个字符串直接交给 strconv.ParseBool 往往会得到解析错误。更稳妥的做法是把兼容逻辑放在配置入口：先清理空白、统一大小写，再把明确约定的 yes/no 映射成 true/false，最后仍交给标准库完成严格解析。

这样既不会放宽所有输入，也不会把未知拼写悄悄当成默认值。官方参考：https://pkg.go.dev/strconv#ParseBool。

先分清 ParseBool 接受什么

ParseBool 返回一个 bool 和一个 error。它接受 Go 约定的大小写变体，以及数字形式 1/0；yes/no 不在这组标准文本里。因此，问题不在于配置文件“不能写 yes/no”，而在于外部词汇和标准解析器之间缺少一层明确的适配。

package main

import (
    "fmt"
    "strconv"
)

func main() {
    raw := "yes"
    value, err := strconv.ParseBool(raw)
    if err != nil {
        // 解析失败要保留原始值，便于定位是哪一项配置不符合约定。
        fmt.Printf("parse %q failed: %v\n", raw, err)
        return
    }
    fmt.Println(value)
}

这段代码展示的是边界，不是运行截图：标准解析器收到 yes 时应进入错误分支。不要用“出错就返回 false”替代错误处理，因为 false 可能是用户明确配置的值，也可能只是输入非法。

在配置入口增加 yes/no 兼容层

兼容层应只处理已经写进配置约定的词，不要用模糊的“非空即 true”。下面的函数允许标准布尔文本继续由 ParseBool 解释，同时额外支持大小写不敏感的 yes/no。

package config

import (
    "fmt"
    "strconv"
    "strings"
)

func parseBool(raw string) (bool, error) {
    value := strings.ToLower(strings.TrimSpace(raw))
    switch value {
    case "yes":
        // yes 是配置格式的兼容词，先转换为标准布尔文本。
        value = "true"
    case "no":
        // no 同理转换为 false，避免把未知词误判为关闭。
        value = "false"
    }

    parsed, err := strconv.ParseBool(value)
    if err != nil {
        // 包装错误并带上原始配置，调用方可定位字段和输入。
        return false, fmt.Errorf("invalid boolean %q: %w", raw, err)
    }
    return parsed, nil
}

这里的关键顺序是“规范化但不猜测”：空格和大小写属于格式噪声，yes/no 属于明确兼容项，其它文本仍由 ParseBool 拒绝。若项目不希望接受 1/0，可以在调用标准库前增加白名单；不要在没有产品约定时随意扩展。

缺省值和非法值不要混成一件事

配置系统通常还会遇到“字段缺失”。缺失可以使用业务默认值，但字段存在且拼写错误时应返回错误；两种情况如果都返回 false，排查时很难知道配置到底有没有生效。

如果配置来自多个来源，建议先在最靠近输入的地方完成一次解析，后续业务只接收 bool 和错误，不要让每个调用点各自实现一套 yes/no 规则。这样回滚时只需撤回兼容层的配置约定，业务代码不必跟着改。

迁移前后的核对清单

• 列出文件、环境变量和命令行参数实际允许的布尔文本。
• 确认字段缺失与字段非法分别对应默认值和错误。
• 统一在入口 trim 和大小写处理，避免不同调用点行为不一致。
• 记录原始输入或字段名，但不要把敏感配置值写入公开日志。
• 给 yes、no、TRUE、false、1、0、空值和未知词分别设计边界用例。

一句话总结：strconv.ParseBool 负责标准布尔文本，yes/no 是配置格式的兼容问题。把映射集中在入口、让非法值继续报错，就能兼顾旧配置和可维护性。

两个常见疑问

能不能直接用 strings.ToLower 后比较非空？ 不建议。非空字符串、拼写错误和明确的 yes 都会被混在一起，最终把配置错误伪装成业务开关。

要不要把 YES、Yes 一起支持？ 如果兼容约定允许，统一转小写后即可支持；若配置格式要求严格大小写，则应去掉这一步并在文档中写清楚。规则越集中，迁移和回滚越容易。