应使用二维数组动态规划实现Levenshtein距离，时间复杂度O(m×n)、空间复杂度O(m×n)；若只判断相似性（如阈值≤5），可优化为两行滚动数组，空间降至O(min(m,n))。
编辑距离（Levenshtein）在 C# 里怎么算才不慢
直接用 LevenshteinDistance 函数？C# 没内置，得自己写或引第三方。手写最稳，但别用递归——栈溢出+指数级耗时是常态。
常见错误现象：StackOverflowException 或对比两个 200 字符文本要几百毫秒；根本原因是没加缓存或用了纯递归。
- 必须用二维数组动态规划，空间换时间，
O(m*n)时间、O(m*n)空间是底线 - 如果只关心是否“相似”（比如阈值 ≤ 5），可改用空间优化版：只保留两行，把空间压到
O(min(m,n)) - 中文文本注意：UTF-16 编码下，一个汉字是 1 个
char，不用额外拆分，直接传string.ToCharArray()即可
示例关键片段：
int[,] dp = new int[s1.Length + 1, s2.Length + 1];
for (int i = 0; i <= s1.Length; i++) dp[i, 0] = i;
for (int j = 0; j <= s2.Length; j++) dp[0, j] = j;
for (int i = 1; i <= s1.Length; i++) {
for (int j = 1; j <= s2.Length; j++) {
dp[i, j] = Math.Min(Math.Min(
dp[i - 1, j] + 1,
dp[i, j - 1] + 1),
dp[i - 1, j - 1] + (s1[i - 1] == s2[j - 1] ? 0 : 1));
}
}
return dp[s1.Length, s2.Length];余弦相似度为什么不能直接喂原文，得先向量化
余弦相似度算的是向量夹角，不是字符串本身。把“今天天气很好”和“天气很好今天”当成两段文本直接丢进去？结果一定是 0 —— 因为没转成向量。
使用场景：适合中长文本（>20 字）、语义近似但字面差异大的情况，比如用户搜索词和 FAQ 标题匹配。
- 最简做法是 TF-IDF +
string.Split()分词，但中文必须先用分词器（如jieba-net），否则按字切就废了 - 别用
StringSplitOptions.RemoveEmptyEntries忘了去标点，否则“你好！”和“你好”向量不同——建议预处理统一调用Regex.Replace(text, @"[^\w\u4e00-\u9fa5]", " ") - 向量维度取决于词表大小，短文本容易稀疏，此时余弦值敏感度低，建议搭配编辑距离做二级过滤
编辑距离和余弦相似度结果怎么统一成 0~1 的相似分
编辑距离输出是整数（比如 3），余弦输出是浮点（比如 0.67），没法直接比。硬除最大长度？错——编辑距离最大可能是 Math.Max(s1.Length, s2.Length)，但实际很少达到。
性能影响：归一化本身不耗时，但选错公式会让排序失真。
- 编辑距离推荐用：
1.0 - (distance / (double)Math.Max(s1.Length, s2.Length))，简单且对短文本友好 - 余弦值本身就是 0~1，但要注意：完全无关文本可能得负值（用了中心化 TF-IDF），此时需截断为
Math.Max(0, cosine) - 如果两者混用（比如加权融合），务必先各自归一，再按权重算：
0.7 * normalizedLev + 0.3 * normalizedCosine
.NET 6+ 有没有更快的替代方案
有，但要看场景。别急着上 ML.NET 或 ONNX 模型——90% 的业务需求，Span<char></char> 优化的编辑距离已够用。
兼容性影响：.NET 5+ 支持 Span，但若项目锁在 .NET Framework 4.8，就老实用数组。
-
Microsoft.ML提供TextFeaturizer，能自动做 n-gram + TF-IDF，但启动开销大，不适合单次小文本比对 - 轻量级推荐
FuzzySharpNuGet 包，封装了编辑距离、Jaro-Winkler 等，API 干净：FuzzyMatcher.PartialRatio(s1, s2) - 注意：所有基于字符的算法对中文友好，但对 OCR 错字（如“己”→“已”）无感，这种得上字形相似度库（如
ChineseCharSimilarity）
真正容易被忽略的是预处理一致性——计算前没统一转小写、没删空格、没标准化全半角，两个本该 95% 相似的文本可能掉到 60%。这比选哪个算法影响更大。
