因为strings.ReplaceAll仅支持字面量匹配，无法识别上下文边界，易误伤地址、价格等嵌入式数字；且需将[]byte转string引发内存开销与UTF-8编码错位风险，故应基于[]byte手动扫描并做边界校验。
为什么不能直接用 strings.ReplaceAll 处理敏感数字？
因为 strings.ReplaceAll 是按字面值匹配的，而“敏感数字”往往有上下文依赖：比如要替换手机号 "13812345678"，但不能把地址里的 "1234" 或价格 "¥123.45" 误伤。更关键的是，原始数据可能来自二进制协议、HTTP body 或日志行，本身就是 []byte，转成 string 再操作会额外分配内存，还可能因 UTF-8 编码问题导致边界错位（比如在多字节字符中间切开）。
所以得在 []byte 层面做模式识别和原地替换，避免字符串转换开销和编码风险。
用 bytes.Index + 手动扫描做精确数字定位
敏感数字通常有固定长度（如 11 位手机号）、前缀（如 "1[3-9]\d{9}"）或前后分隔符（如空格、标点）。直接用正则太重，且 regexp 不支持 []byte 输入；改用朴素扫描更可控：
- 遍历
[]byte，用bytes.Index找到疑似数字起始位置（比如连续 11 个 ASCII 数字） - 检查前后字符是否为边界（
0、空格、标点、或越界），排除嵌入式数字 - 确认后，用
copy覆盖目标区域，例如替换成***对应的字节序列[]byte("***") - 注意：替换后长度变化会导致后续索引偏移，必须从后往前扫，或记录所有匹配位置再批量替换
示例片段：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
// 假设只替换 11 位纯数字，且前后是空白或边界
b := []byte("订单号:13812345678，金额:99.99")
for i := 0; i <= len(b)-11; i++ {
if isAllDigit(b[i:i+11]) && isBoundary(b, i-1) && isBoundary(b, i+11) {
copy(b[i:], []byte("***"))
i += 2 // 跳过已处理区（替换后占 3 字节）
}
}
替换时长度不一致怎么办？
[]byte 是定长切片，无法像 string 那样拼接。若敏感数字长 11 字节，掩码只用 3 字节（"***"），直接 copy 会留下残留（比如原 "13812345678" 变成 "***45678"）。必须显式截断或重分配：
- 最简方案：统一用等长掩码，如
bytes.Repeat([]byte("*"), 11)，保证长度一致 - 若必须变短，只能新建
[]byte，用append拼接非敏感段 —— 这时得预估最终容量，避免多次扩容 - 性能敏感场景（如日志实时脱敏），优先选等长替换；业务允许时，用
unsafe.Slice（Go 1.20+）绕过拷贝，但需确保原底层数组可写
中文环境下的常见坑：全角数字和混合编码
用户输入可能含全角数字（０１２３４５６７８９，Unicode U+FF10–U+FF19），它们不是 ASCII，isDigit 判断会失败。还有混合情况：手机号带 "+"、"-" 前缀，或用中文括号包裹。
- 别只用
b[i] >= '0' && b[i] <= '9'，改用unicode.IsDigit(rune(b[i]))，但注意[]byte到rune要先转string，代价高 - 更实用的做法：预定义合法数字字节集，包括 ASCII 数字 + 常见全角数字的 UTF-8 编码字节序列（如
0xEF 0xBC 0x90），查表判断 - 如果输入确定是 UTF-8，且只处理 ASCII 数字，就加校验：遇到非 ASCII 字节直接跳过，避免
utf8.DecodeRune解码失败
真正难的不是替换动作本身，而是定义清楚“什么是敏感数字”——规则模糊时，宁可漏判也不能误判，否则业务字段被删就不可逆了。
