字符串相等判断用==，它直接比较字节序列是否完全相同（区分大小写和unicode码点），高效且安全；strings.equalfold仅用于忽略大小写的比较，有额外开销。
字符串相等判断用 ==，不是 strings.EqualFold
Go 中字符串是不可变的值类型，直接用 == 比较是否完全相等（包括大小写、Unicode 码点），这是最常用也最高效的方式。很多人误以为要调用 strings.EqualFold，其实它只用于忽略大小写的比较，且有额外开销。
-
"abc" == "abc"返回true；"Abc" == "abc"返回false -
strings.EqualFold("Abc", "abc")返回true，但会做 Unicode 大小写规范化，性能略低 - 空字符串
"" == ""为true，无需特殊处理 - 注意：
==对nil字符串安全，但 Go 中字面量和空字符串变量都不会是nil；只有*string指针才可能为nil
按字典序比较大小用 strings.Compare 或直接用 /<code>>
Go 标准库提供 strings.Compare 函数返回 -1、0、1，但它底层就是逐字节比较，和直接用 、<code>> 运算符行为一致——两者都基于 UTF-8 编码的字节序，不是按 Unicode 排序规则（即不支持 locale）。
"apple" → <code>true（因为'a' ）-
strings.Compare("go", "golang")→-1（前两个字节相同，但"go"更短） - 中文或 emoji 场景下，
"你好" 依赖 UTF-8 字节序列，结果可预测但未必符合人眼“字典序”——比如 <code>"α" 成立，因为希腊字母 α 的 UTF-8 编码（<code>\xce\xb1）字节值小于 ASCIIz - 如需真正的语言敏感排序（如中文拼音序、德语变音符号处理），必须用
golang.org/x/text/collate包，不能靠原生操作
避免在循环里反复调用 strings.EqualFold 或 strings.Compare
这两个函数每次都会遍历字符串，如果在高频路径（如 HTTP 请求头校验、日志过滤）中被频繁调用，可能成为性能瓶颈。尤其 strings.EqualFold 还涉及 Unicode 大小写映射表查找。
- 若只需一次比对，用
==或即可，无需导入 <code>strings - 若需多次忽略大小写匹配固定字符串（如检查 header key），建议提前转成小写再用
==：strings.ToLower(s) == "content-type"，但注意：这会分配新字符串；更优做法是用strings.EqualFold(s, "Content-Type")—— 它内部做了优化，比手动ToLower+==略快且内存更少 - 切忌在
for循环内对长字符串反复调用strings.Compare做排序——应改用sort.Slice配合自定义比较函数，避免重复计算
注意字符串底层是 UTF-8，但比较不解析 Unicode 码点
Go 的字符串比较永远按字节进行，不会解码成 rune 再比较。这意味着包含多字节字符（如中文、emoji）的字符串，其“大小”关系由 UTF-8 编码字节流决定，而非字符语义。
"??" 结果取决于各自 UTF-8 编码的字节序列，不是按“男/女”语义排序-
"café" == "cafe\u0301"→false，前者是预组合字符é（U+00E9），后者是e+ 组合重音符（U+0065 U+0301），UTF-8 字节不同 - 需要语义等价判断时，得先用
unicode/norm包标准化（如NFC），再比较 - 简单场景下，只要确保输入来源统一（如都来自同一 HTTP 客户端、都经过相同 normalization），直接
==就足够可靠
== 和 。真正容易出错的是混淆「字节序比较」和「自然语言排序」，以及在不该用 <code>EqualFold 的地方硬套——它不是免费的。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
