首选==，因其是编译器内建操作，先比长度再逐字节比较，平均耗时2.9 ns，比strings.compare（7.4 ns）快两倍多；后者专为三态排序设计，相等判断应避免使用。
字符串比较用 == 还是 strings.Compare？
直接用 == 更快，而且更安全。基准测试显示，== 平均耗时约 2.9 ns，strings.Compare 约 7.4 ns——慢了两倍多。Go 官方也明确推荐优先使用 == 做相等判断。
原因在于：== 是语言原生操作，底层会先比长度，长度不等直接返回 false；长度相等才逐字节比较。这个快速路径能避开大量无效内存访问。
strings.Compare 则必须走完整三路比较逻辑（-1/0/1），即使你只关心是否相等，它也无法提前退出。
- 只判断相等或不等 → 无条件选
== - 需要知道谁大谁小（比如排序回调）→ 才用
strings.Compare - 忽略大小写比较 → 必须用
strings.EqualFold，它内部不依赖长度快速路径，性能天然更低
UTF-8 编码下，中文或 emoji 会影响比较性能吗？
不会额外拖慢比较速度，但会影响「长度判断」的触发时机。
Go 字符串按字节存储和比较，len() 返回的是字节数，不是字符数。一个中文字符占 3 字节，一个 emoji（如 ?）可能占 4 字节。所以两个视觉上等长的字符串，字节长度可能不同，== 会在第一步就判 false，反而更快。
真正影响性能的是「字节序列是否一致」：如果两个字符串字节完全相同，无论含多少中文或 emoji，比较都很快；如果前几个字节就不同，也立刻结束。
-
len("a") == 1，len("你好") == 6（UTF-8 编码下，“你”“好”各 3 字节） -
"你好" == "你好"→ 先比长度 6 == 6，再逐字节比，共 6 次比较 -
"你好" == "你好！"→ 长度 6 != 9，一步返回 false - 不要用
len([]rune(s))做比较前预检——它要遍历全部 rune，开销远大于直接==
为什么 strings.EqualFold 比 == 慢得多？
因为它不能跳过长度检查，也不能短路退出：必须把每个 rune 解码、转为小写、再逐个比较。哪怕第一个字符就不同，它仍得走完整个转换流程。
更麻烦的是，strings.EqualFold 对 Unicode 规范敏感。比如带组合音标的 "é"（U+00E9）和 "e\u0301"（e + 重音符），视觉一样，但字节不同，== 判 false，strings.EqualFold 也可能判 false——除非双方都按 Unicode 正规化处理过。
- 仅当业务明确要求忽略大小写时才用
strings.EqualFold - 不要在热路径里对长字符串反复调用它
- 若需高频不区分大小写的查找，考虑预处理成小写后用
==，或用 map[string]struct{} 索引
容易被忽略的字节 vs 字符陷阱
开发者常误以为 len() 返回字符数，结果写出错误的边界判断或切片逻辑，间接导致比较行为异常。
例如：s[:len(s)/2] 对英文没问题，对中文就可能切在 UTF-8 字节中间，产生非法字符串；再拿它去 == 比较，虽然不会 panic，但结果不可预测（因为非法字节序列与合法序列永远不等）。
- 判断空字符串，用
len(s) == 0，别用s == ""—— 虽然结果一样，但前者语义更清晰，且避免潜在的零值误解 - 做子串提取或索引操作前，先确认是否需要
utf8.RuneCountInString或[]rune转换 - 从外部接收字符串（如 HTTP 请求、文件读取）时，无法保证其 UTF-8 合法性，
strings.EqualFold可能静默失败，而==至少行为确定
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
