SearchValues是.NET 8引入的高性能文本扫描工具，专为ReadOnlySpan上的字符查找优化，通过预构建位图或哈希表加速IndexAny系列操作，不适用于子字符串搜索或泛型集合筛选。
SearchValues 是 .NET 8 引入的高性能字符串/字符查找工具，专为替代 string.Contains、IndexOf 等低效调用而设计。它不适用于泛型集合筛选，只作用于 ReadOnlySpan<char></char> 和 ReadOnlySpan<byte></byte> —— 换句话说，它是底层文本扫描的加速器，不是 LINQ 替代品。
什么时候该用 SearchValues<char></char> 而不是 Contains
当你在高频循环中反复检查某段文本是否含多个可能字符（比如解析日志、过滤控制符、提取分隔符）时，Contains 每次都从头线性扫描，而 SearchValues 预构建查找表，单次初始化后可复用。
- 适用场景：解析 CSV 行、跳过空白/注释、识别 SQL 关键字首字符、HTTP header 值截断
- 不适用场景：查找子字符串（如
"error"）、模糊匹配、正则需求 - 性能差异：对 1KB 文本查 5 个候选字符，
SearchValues比Any(c => " \t\n\r".Contains(c))快 3–5 倍（实测 .NET 8.0.4）
SearchValues.Create 的三种构造方式和陷阱
构造方式直接决定能否命中优化路径。.NET 8 内部对不同输入做了特化：小字符集走位图（bitmask），大字符集或 Unicode 走哈希表。
-
SearchValues.Create(" \t\n\r")→ 安全，ASCII 字符自动启用位图，O(1) 查找 -
SearchValues.Create(new char[] { ' ', '\t', '\n', '\r' })→ 同上，但注意数组不能含重复项，否则抛ArgumentException -
SearchValues.Create("αβγ")→ 回退到哈希表，仍比Contains快，但失去位图优势；若混用 ASCII 和 Unicode，整个表降级 - 常见错误：传空字符串或
null，会直接抛ArgumentNullException
如何配合 Span<char></char> 实现零分配查找
真正发挥性能的关键是避免字符串分配 —— 所有操作必须基于 Span 或 ReadOnlySpan。一旦调用 .ToString() 或 Substring()，就失去优势。
- 正确姿势：
var separators = SearchValues.Create(" \t\n\r"); ReadOnlySpan<char> line = stackalloc char[256]; // ... 从文件读取到 line int firstSep = line.IndexOfAny(separators); // 零分配，返回索引 </char> - 错误姿势：
line.ToString().IndexOfAny(separators)→ 多一次堆分配 + 复制 - 注意：只有
IndexOfAny、IndexOfAnyExcept、LastIndexOfAny这三个方法能利用SearchValues；Contains不行
和 HashSet<char></char> 对比：为什么不用现成集合
看起来 HashSet<char></char> 也能做存在性判断，但它每次 Contains 都要计算哈希、处理桶冲突，且无法内联进 Span 查找逻辑。
-
SearchValues是密封类型，无虚方法调用，JIT 可完全内联其IndexOfAny路径 -
HashSet<char></char>在foreach或linq Any()中会触发枚举器分配，而SearchValues完全无 GC 压力 - 实测：10 万次查找 4 字符集，
SearchValues分配 0 字节，HashSet平均多出 1.2MB 临时对象
SearchValues 的价值不在“功能更多”，而在“在最窄的文本扫描路径上砍掉一切冗余”。它要求你主动管理内存视图（Span），放弃字符串便利性，换来的是日志解析、协议解包等场景下可量化的吞吐提升。用错地方（比如拿它查单词）反而更慢。
