searchvalues.create 比 contains 更快，因其将多个关键词预处理为位图或哈希索引，单次扫描即可定位所有匹配项，避免重复遍历；适用于日志解析、配置提取等多关键词场景。
SearchValues.Create 为什么比 Contains 更快
因为 SearchValues<char></char> 把多个待查字符串预处理成位图或哈希索引，避免每次扫描都重复遍历所有目标词。普通 Contains 或 IndexOfAny 在查 5 个关键词时，每行要调 5 次；而 SearchValues 一次扫描就能标记出所有匹配位置。
适用场景：日志解析、配置文件关键词提取、CSV/TSV 行内多字段定位。
- 只支持
char和string两种泛型参数，查子串必须用SearchValues<string></string>，不能混用 -
SearchValues.Create(new[] { "ERROR", "WARN", "INFO" })会自动去重并优化内部结构，但传入 null 或空字符串会抛ArgumentException - 在 .NET 8 中，
SearchValues<string></string>对短字符串（≤ 16 字节）启用 SIMD 加速，长字符串回退到高效哈希匹配
File.ReadLines + SearchValues.FindFirstCharacterOrValue 怎么配合用
直接对大文件逐行读取 + 检查首字符或关键词存在性，是内存友好且能 early-exit 的组合。别用 File.ReadAllLines 加载全量再查 —— 即使文件只有 100MB，也可能触发 GC 压力。
常见错误：把 FindFirstCharacterOrValue 当成“找完整子串”，其实它只返回第一个匹配的起始索引（或 -1），不区分是单字符还是整个字符串命中。
- 先用
SearchValues<string>.Create(new[] { "StatusCode:", "UserAgent:", "X-Request-ID:" })</string> - 对每行调
values.FindFirstCharacterOrValue(line)，返回 ≥ 0 表示该行含任一关键词 - 若需定位具体是哪个词，再用
line.AsSpan().IndexOfAnyValues(values)获取详细偏移和匹配值 - 注意：如果某行含 "Status" 和 "StatusCode:"，
FindFirstCharacterOrValue只返回第一个匹配位置，不会告诉你匹配的是哪个
IndexOfAnyValues 返回值怎么解读才不踩坑
IndexOfAnyValues 返回的是 Range 类型（.NET 8 新增），不是整数索引。直接打印或比较会得到类似 [12..19] 的结果，不是你想要的起始位置。
使用场景：需要精确提取匹配关键词前后上下文，比如截取 HTTP header 值、提取 JSON key 对应的 value 片段。
- 正确解包方式：
var range = line.AsSpan().IndexOfAnyValues(values); int start = range.Start; - 如果没匹配，
range是Range.Empty，此时range.Start == 0但range.Length == 0，不能只判start == 0 - 搭配
line.AsSpan()[range]可直接拿到匹配到的原始字符串（如 "UserAgent:"），无需额外Substring - 性能提示：反复调用
IndexOfAnyValues时，确保values是复用对象，不要每行都Create新实例
跨平台文件路径和编码问题怎么绕开
SearchValues 本身不处理编码，它只操作 ReadOnlySpan<char></char>。所以真正出错的地方往往在读文件这一步 —— 比如用默认编码读 UTF-8 BOM 文件，导致第一行乱码，关键词永远匹配不上。
Windows 上常见现象：File.ReadLines("log.txt") 返回的行开头多出 \uFEFF，让 "ERROR" 查不到。
- 统一用
File.ReadLines(path, Encoding.UTF8)，显式指定编码，尤其处理日志、配置等文本文件 - 路径分隔符不用自己替换，
Path.Join和Path.DirectorySeparatorChar在 .NET 8 已足够健壮 - 如果文件可能含 BOM，用
StreamReader构造时传detectEncodingFromByteOrderMarks: true更稳妥 - 别依赖
File.Exists做前置判断 —— 它在某些容器环境或网络路径下可能不准，直接 try/catchFileNotFoundException更实际
最麻烦的其实是混合编码日志：一部分是 GBK，一部分是 UTF-8。这时候 SearchValues 再快也没用，得先做编码探测。那已经不是查找问题，而是输入清洗问题了。
