最安全直白的字符串空判断是len(s) == 0，因它直接读取结构体长度字段、零开销、无歧义；s == ""虽等效但易被误读为语义空；string不可为nil，s == nil会编译失败。
最安全、最直白的判断方式是 len(s) == 0；s == "" 虽然等效，但容易引发语义误解；s == nil 在纯 string 类型上根本不能写，会编译失败。
为什么推荐用 len(s) == 0 而不是 s == ""
len(s) == 0 明确表达「这个字符串没有字节」，不涉及任何字符比较逻辑，也不存在 Unicode 解码或内存遍历——它直接读取字符串结构体里的长度字段，是 O(1)、零开销操作。而 s == "" 看似简洁，实际触发字符串字面量比较：编译器虽能优化成相同指令，但人在代码审查时容易误以为它在做“语义空”判断（比如把 "\t\n " 也当空），尤其后续混入 strings.TrimSpace(s) == "" 时，行为割裂更明显。
常见错误现象：if s == "" || strings.TrimSpace(s) == "" 这种写法逻辑混乱——前者只认真正零长度，后者吃掉所有首尾空白，两者根本不是同一维度的判断。
-
len(s) == 0和s == ""性能完全一致，不必为“效率”纠结 - 选
len(s) == 0是为了可读性与意图一致性，尤其当你紧接着要访问s[0]或做for i := range s时 - 标准库如
strconv多用len(s) > 0，不是偶然
*string 参数必须先判 nil 再判长度
Go 中 string 是值类型，不可能为 nil；但 *string 是指针，可能为空。JSON 反序列化时若字段声明为 *string，缺失字段会得到 nil，而非 ""——这是唯一需要区分「字段不存在」和「字段为空字符串」的场景。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
错误示例：if len(*s) == 0 —— 若 s 是 nil，运行时 panic。
- 正确顺序：先
if s == nil（判指针是否为空），再if len(*s) == 0（判解引用后是否真为空） - 常见使用场景：API 请求体中可选字符串字段、配置文件中允许省略的键
- 别给非指针
string写s == nil，Go 编译器直接报错：invalid operation: s == nil (mismatched types string and nil)
空白字符串 ≠ 空字符串，别用 len(s) == 0 混淆二者
用户输入 " \t\n" 或 " "（全角空格）时，len(s) == 0 返回 false，但它业务上就是“空”。这时候必须用 strings.TrimSpace(s) == ""，而不是硬编码 s == " " 或 s == "\t"。
性能提示：strings.TrimSpace 是单次遍历，O(n)，对普通表单校验足够快；若协议要求严格限定仅空格和制表符（排除换行、全角空格等），则用 strings.IndexFunc(s, func(r rune) bool { return r != ' ' && r != '\t' }) == -1。
-
len(s) == 0和s == ""都只解决「零长度」问题，和空白无关 - 用
strings.TrimSpace前，确保你真的需要「忽略首尾空白」——有些日志字段或二进制协议里，开头空格是有意义的 - 别在热路径里反复调用
strings.TrimSpace；如果同一个字符串要多次判断，缓存结果
真正容易被忽略的点在于：空字符串判断本身很简单，但一旦混入指针、JSON 序列化规则、Unicode 空白多样性，边界就立刻变模糊。每次写判断前，先问自己一句——这里要的是「没内容」，还是「没有效内容」，还是「字段压根没传」。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
