similar_text() 多次调用结果可能不同，因其算法顺序敏感、中文UTF-8支持差、$percent参数引用易污染、长文本触发超时、以及不可见字符干扰。
similar_text() 为什么对同一组字符串多次调用结果可能不同
因为 similar_text() 内部使用递归查找最长公共子串，而该算法对参数顺序敏感——similar_text('a', 'b') 和 similar_text('b', 'a') 可能返回不同数值，不是 bug，是设计如此。
常见错误现象：你在循环里反复调用 similar_text($a, $b)，但某次把变量顺序写成 similar_text($b, $a)，或中间逻辑意外交换了参数，就会看到“相同文本却出不同结果”。
- 该函数不保证交换参数后结果对称，文档明确写了 “交换 string1 和 string2 可能会产生不同的结果”
- 它不是基于编辑距离或哈希的确定性算法，而是按“先找最长公共前缀/后缀+递归处理剩余部分”的策略，路径依赖强
- 没有缓存机制，每次调用都重新计算，不存在状态残留问题；所谓“不一致”，几乎全是参数顺序或输入值被意外修改导致
PHP7.1 中 similar_text() 的中文支持差，会放大结果波动
该函数底层按字节比对，对 UTF-8 编码的中文字符天然不友好。一个汉字占 3 字节，similar_text() 会把它拆成 3 个独立字节参与匹配，导致“语义相同但字节序列错位”时匹配数骤降。
例如：similar_text('你好', '你好吗') 可能只算出 2~3 个匹配字节（而非 2 个完整汉字），而 similar_text('你好吗', '你好') 因为前缀更长，反而可能算出更高值——这进一步加剧了顺序敏感带来的结果漂移。
立即学习“PHP免费学习笔记（深入）”；
- 不要用它做中文标题/短文本去重或阈值判断，误差常超 ±20%
- 若必须用，先统一转为 GBK（不推荐）或用
mb_substr()拆成字符数组再手写对比，但性能代价大 - 真正稳定的替代方案是
levenshtein()（需 PHP ≥ 7.0，且对中文仍需预处理）或外部库如php-levenshtein
浮点百分比参数传引用，容易因变量复用造成误判
similar_text() 第三个参数是引用传递的 $percent，如果这个变量在调用前已被赋值、或在多处共用，会导致后续调用读到脏数据。
典型陷阱：
- 写成
$p = 0; similar_text($a, $b, $p); echo $p;→ 正常 - 但若之前有
similar_text($x, $y, $p);，再用同一个$p而没重置，$p值可能被上一次调用残留影响（虽然函数内部会覆写，但调试时容易误读） - 更危险的是把
$percent当作返回值直接参与 if 判断，比如if (similar_text($a,$b,$p) > 0 && $p > 80)—— 这里$p的值取决于本次调用，但人眼容易当成“上次的 $p”
算法复杂度 O(N³) 在长文本下触发截断或超时，间接导致“结果不一致”
当字符串长度超过 100 字符，similar_text() 的递归深度和计算量会指数级上升。PHP7.1 默认 max_execution_time=30，一旦超时，函数返回 0 或中断，看起来就像“两次调用结果不同”。
这种情况在开发环境（本地配置宽松）和生产环境（超时严格）之间尤其明显。
- 用
strlen()预检输入长度，超过 50 就拒绝或降级为levenshtein()（O(N²)，更可控） - 别在循环中对多个长文本连续调用
similar_text()，极易触发超时抖动 - 检查
error_log是否有Maximum execution time of X seconds exceeded，这是最隐蔽的“不一致”源头
similar_text() 对这些完全敏感，而 var_dump() 默认不显示它们。建议用 bin2hex() 对比原始字节。 
