Go 的 regexp 包默认处理 UTF-8 编码的 Unicode 文本，\xHH 表示 Unicode 码点 U+00HH 对应的 UTF-8 字节序列，而非单个字节值；因此 \x80 匹配的是两字节序列 0xC2 0x80，而非单字节 0x80。
go 的 `regexp` 包默认处理 utf-8 编码的 unicode 文本，`\xhh` 表示 unicode 码点 u+00hh 对应的 utf-8 字节序列，而非单个字节值；因此 `\x80` 匹配的是两字节序列 `0xc2 0x80`，而非单字节 `0x80`。
在 Go 中，regexp 包严格遵循 Unicode 和 UTF-8 语义：所有正则模式和输入数据均被解释为合法的 UTF-8 编码文本。这意味着反斜杠转义如 \x7f、\x80、\uFFFF 等，并非直接匹配原始字节，而是匹配对应 Unicode 码点（如 U+007F、U+0080）经 UTF-8 编码后的字节序列。
例如：
-
\x7f 对应码点 U+007F（ASCII DEL），其 UTF-8 编码即为单字节 0x7F，因此以下代码能成功匹配：
re := regexp.MustCompile(`\x7f`) match := re.FindSubmatch([]byte{0x7f}) // → [[127]] -
但 \x80 对应码点 U+0080（Latin-1 Supplement 起始字符），它超出 ASCII 范围（> 0x7F），需用 2 字节 UTF-8 编码：0xC2 0x80。因此，直接传入 []byte{0x80} 将无法匹配：
re := regexp.MustCompile(`\x80`) match := re.FindSubmatch([]byte{0x80}) // → nil（无匹配）只有提供符合 UTF-8 规范的输入时才能命中：
match := re.FindSubmatch([]byte{0xC2, 0x80}) // → [[194 128]] // 或更实际地：包含该字符的合法 UTF-8 字符串 match := re.FindSubmatch([]byte("a\xC2\x80b")) // → [[194 128]]
⚠️ 关键限制：Go 标准库 regexp 不支持二进制/字节模式（binary mode）。它会拒绝包含非法 UTF-8 序列的输入（如孤立 0x80），并在匹配前尝试解析整个输入为 UTF-8 —— 若失败（如遇到 0x80 单独出现），行为未定义，通常导致匹配失败或 panic（取决于 Go 版本与上下文）。
✅ 解决方案建议：
- 若数据天然为 UTF-8（如文本协议、JSON、HTML）：确保字面量与输入编码一致，优先使用 \uXXXX 或 Unicode 字符字面量（如 re := regexp.MustCompile(\u0080)）。
-
若需精确字节匹配（如解析二进制协议、网络包、内存 dump）：切勿使用 regexp，改用：
- bytes.Index, bytes.Contains, bytes.FieldsFunc 等 bytes 包函数；
- 或专用二进制模式库，如 github.com/tidwall/gjson（针对 JSON）、golang.org/x/exp/slices（Go 1.21+）进行切片搜索；
- 示例（安全字节查找）：
data := []byte{0x01, 0x02, 0x80, 0x03} if i := bytes.Index(data, []byte{0x80}); i >= 0 { fmt.Printf("Found 0x80 at offset %d\n", i) // 输出：Found 0x80 at offset 2 }
? 总结：Go 的 regexp 是面向文本（UTF-8）的工具，不是通用字节处理器。混淆 \xHH 的语义（Unicode 码点 vs. 原始字节）是常见陷阱。始终确认你的数据编码，并在非文本场景下主动规避正则，选择更轻量、更可控的字节操作方案。
