Go strconv.ParseBool 处理环境变量：大小写、空值与配置回滚边界

服务启动时，FEATURE_CACHE=false 看起来很简单，真正容易出事故的是有人把它写成 False、留成空字符串，或者误拼成 flase。如果代码只做字符串比较，错误输入会悄悄落到默认分支；如果把所有解析错误都当成关闭，线上排查会更慢。

线上开关为什么会把三种状态混在一起

一个常见的开关读取代码是：

enabled := os.Getenv("FEATURE_CACHE") == "true"

它只能识别一个精确的小写字面量。配置为 1、TRUE、False 时，结果都会变成 false；而空值、合法关闭、拼写错误在业务层看起来完全一样。规模稍大后，最难查的不是开关没打开，而是大家不知道它为什么没打开。

更稳妥的边界是把输入分成三类：变量不存在或为空，表示使用默认值；输入属于 ParseBool 的合法集合，按值启用或关闭；输入非空但无法解析，表示配置错误。

ParseBool 到底接受哪些值

strconv.ParseBool 会把 1、t、T、TRUE、True、true 解析为 true；把 0、f、F、FALSE、False、false 解析为 false。其他字符串都会返回错误。

这里不要先用 strings.ToLower 再和 true 比较。那样虽然能扩大表面兼容性，却会再次丢掉非法输入的信号。直接保留 ParseBool 返回的 error，判断会清楚很多。

给启动配置加上缺失、关闭和错误三条路径

下面的函数把空值作为默认值，把非空非法值作为启动错误。默认值只对“没有配置”负责，不替拼写错误背锅。

package config

import (
    "fmt"
    "os"
    "strconv"
)

func boolEnv(key string, fallback bool) (bool, error) {
    raw, ok := os.LookupEnv(key)
    if !ok || raw == "" {
        return fallback, nil
    }
    value, err := strconv.ParseBool(raw)
    if err != nil {
        return false, fmt.Errorf("配置 %s 不是合法布尔值: %q", key, raw)
    }
    return value, nil
}

LookupEnv 和 Getenv 的差别在这里很重要：前者能告诉你变量是否存在。若业务规定“存在但为空”必须报错，可以把 raw == "" 从默认分支移到错误分支，并在配置契约中明确写出来。

启动时如何验收

cacheEnabled, err := boolEnv("FEATURE_CACHE", true)
if err != nil {
    return fmt.Errorf("读取功能开关失败: %w", err)
}
fmt.Printf("FEATURE_CACHE=%t\n", cacheEnabled)

启动日志只记录解析后的值还不够，建议同时记录“使用默认值”或“来自环境变量”这样的来源信息，但不要把密钥、令牌等敏感环境变量原样写进日志。

热更新时不要让半套配置先跑起来

如果服务支持重载，错误处理要比启动更严格。先把新环境快照读入临时结构，完成全部解析和校验，再一次性替换旧配置；不要解析一个字段就立即修改全局变量。

type Snapshot struct {
    CacheEnabled bool
    AuditEnabled bool
}

func readSnapshot() (Snapshot, error) {
    cache, err := boolEnv("FEATURE_CACHE", true)
    if err != nil { return Snapshot{}, err }
    audit, err := boolEnv("FEATURE_AUDIT", true)
    if err != nil { return Snapshot{}, err }
    return Snapshot{CacheEnabled: cache, AuditEnabled: audit}, nil
}

重载流程可以采用“读取快照 → 解析全部字段 → 校验依赖 → 原子替换”的顺序。任何一步失败，都保留旧快照，并把错误字段和原始值放到受控的告警上下文里。这样不会出现缓存已经关闭、审计仍按新规则运行的短暂组合。

哪些写法会让排查成本变高

• 把所有非空字符串当成 true：yes、on 和拼写错误都会误开启。
• 把 ParseBool 的 error 当成 false：这会把配置事故伪装成业务选择。
• 先改全局字段再解析下一个：多开关重载失败时会留下混合状态。
• 只依赖启动日志：热更新后的来源、版本和时间点没有记录，回滚难以确认。

如果确实需要支持 on/off 这类业务词，建议在 ParseBool 之前增加一层明确的词法映射，并为映射写测试；不要用“非空即真”替代配置协议。

常见问题

ParseBool 能解析 on 和 off 吗？

不能。它只接受文档规定的 1、0、t、f 及大小写组合。需要 on/off 时应显式做词法映射。

环境变量为空时应该报错还是使用默认值？

两种都可以，但要写进配置契约。可选开关通常使用默认值；必须显式配置的安全开关则应把空值视为错误。

热更新解析失败后要不要关闭旧功能？

通常不要。保留上一份完整快照更安全，同时发出告警，让修正后的配置在下一次重载中生效。

为什么不直接用 strings.EqualFold？

它只能回答是否等于某个词，不能提供 ParseBool 的标准字面量集合，也容易让非法输入悄悄进入默认分支。

布尔配置的关键不是把字符串转成 bool，而是保留“缺失、明确关闭、非法输入”三种不同信号。启动时拒绝错误，热更新时整体替换，排障时再补上来源和版本，开关才真正可控。