在 Go 开发里，字符串判空几乎每天都会写到，但 len(s) == 0 和 s == "" 哪个更合适，常常会让人犹豫。这个问题真正值得比较的并不是“谁更高级”，而是它们在性能上有没有差别、在语义上分别强调什么，以及在什么上下文里哪一种更能把代码意图写清楚。
性能上有没有区别？
先看最直观的两种写法：
// 方法一：使用长度判断
func isEmpty1(s string) bool {
return len(s) == 0
}
// 方法二：直接比较空字符串
func isEmpty2(s string) bool {
return s == ""
}表面上看，这两种方式走的是不同路径：一种是取长度，一种是比较值。但对 Go 编译器来说，它们在“判断空字符串”这个场景里通常会被优化到同一层面。
原文给出的基准测试代码如下：
func BenchmarkTest1(b *testing.B) {
for i := 0; i < b.N; i++ {
isEmpty1("")
}
}
func BenchmarkTest2(b *testing.B) {
for i := 0; i < b.N; i++ {
isEmpty2("")
}
}基准测试的结论很明确：两者执行时间几乎完全相同，而且都不会产生额外的内存分配。继续往下看汇编层面的结果，会发现 Go 编译器会把这两种写法优化成相同的机器码。
这意味着，如果只是想比较“速度”，这里其实没有值得纠结的空间。在性能维度上，len(s) == 0 和 s == "" 可以视为没有区别。
真正的差别在语义表达
既然性能不构成选择依据，剩下就该看代码到底想表达什么。
len(s) == 0 关注的是“这个字符串长度是不是 0”；s == "" 关注的是“这个值是不是空字符串”。功能结果一样，但读代码的人接收到的意图并不完全相同。
这也是为什么在 Go 标准库里，两种写法都能看到，而且都很常见。它们不是谁替代谁的关系，而是各自更适合不同的语境。
什么时候更适合写 s == ""
如果你关心的是“值本身是不是空字符串”，直接比较通常更自然。它读起来更像业务判断，语义也更直接。
// 检查用户输入是否为空
if userInput == "" {
return errors.New("输入不能为空")
}
// 检查配置项是否设置
if configValue == "" {
// 使用默认值
}这类场景里，代码不是在讨论长度，而是在讨论“有没有填值”“这个配置是否为空”“字段是否设置”。因此写成 s == "" 会更贴近业务语义。
原文还提到，在 Go 标准库的 encoding/json 包中，也能看到 s != "" 这样的写法。这种例子说明，直接比较空字符串本身就是标准、自然的 Go 风格，并不是什么“偷懒写法”。
什么时候更适合写 len(s) == 0
如果你后续要继续处理长度、索引或边界条件，那么用 len(s) 往往更顺手，也更容易把逻辑连起来。
// 在访问字符串第一个字符前检查长度
if len(s) > 0 {
firstChar := s[0]
// 处理第一个字符
}
// 处理字符串长度相关的逻辑
if len(s) == 0 {
return emptyResult
}这里的重点不只是“空不空”，而是“长度是否满足后续操作的前提”。例如访问 s[0] 之前，先写 len(s) > 0，读者一眼就能明白这是在做越界保护，而不是单纯做值比较。
原文提到，Go 标准库的 strconv 包中也能找到 len(s) > 0 的用法。这类写法通常都和后续的字符访问、切片处理或长度判断直接相关。
实际开发里怎么选更稳妥
把标准说得简单一点，其实就一句话：关注长度时用 len，关注值时直接比较。
如果你的下一步操作依赖字符串长度，比如要访问某个下标、截取子串、判断边界，那就继续沿着长度这个思路写，例如 len(s) > x。即使这里的 x 恰好是 0，这样写依旧更连贯。
如果你的判断是在表达“它是不是这个特定字符串”，尤其是空字符串这个业务值，那么 s == "" 往往更清晰。
最后还有一个容易被忽略的点：在团队项目中，统一风格比个人偏好更重要。因为这两个写法都属于 Go 的惯用方式，也都被标准库广泛采用，所以真正影响可维护性的，往往不是你选了哪一个，而是同一段代码里是否始终按照同一种语义标准来写。
可以归纳为三条：
- 性能相同：Go 编译器会将
len(s) == 0和s == ""优化为相同的机器码。 - 语义不同：前者强调长度，后者强调值。
- 按上下文选择：哪种写法更能准确表达当前意图，就用哪一种。
所以，这个问题的答案并不是“固定只用一个”，而是根据上下文做语义最清楚的选择。对于 Go 代码来说，可读性和一致性，通常比这种没有实际性能差异的微观选择更重要。
