tolowercase() 搜索匹配需同时转换用户输入和目标字符串，仅转一边会导致漏匹配；ascii场景有效，但土耳其语等locale下会出错，推荐用/i正则或tolocalelowercase('en-us')。
toLowerCase() 做搜索匹配的正确姿势
直接对用户输入和目标字符串都调用 toLowerCase() 再用 includes() 或 indexOf() 判断，是最简单有效的方案。但要注意它只适用于 ASCII 字符为主的场景，遇到土耳其语、希腊语或带重音符号的字符时可能出错。
为什么不能只转一边的大小写？
搜索匹配必须两端统一处理，否则会漏匹配。比如用户输 "HTML"，目标里是 "html"，如果只把输入转小写而目标没转，就变成 "html".includes("html") ✅；但如果目标是 "Html" 而你没转它，就变成 "Html".includes("html") ❌。
- 永远同时对搜索词和被搜索内容调用
toLowerCase() - 不要依赖浏览器自动转换或 CSS 文本转换——它们不参与 JS 字符串比较
- 避免在循环里反复调用
toLowerCase()，提前存好结果
遇到非英语字符时的坑
toLowerCase() 在不同 locale 下行为不一致。例如土耳其语中大写 "I" 转小写不是 "i"，而是 "ı"（无点 i），导致 "I".toLowerCase() === "i" 返回 false。
- 若业务明确面向多语言用户，改用
toLocaleLowerCase('en-US')强制指定 locale - 更稳妥的做法是用正则配合
i标志：/search/i.test(text)，它底层使用 Unicode 大小写映射，兼容性更好 - 注意
toLocaleLowerCase()在旧版 Safari 中有 bug，iOS 12 及更早版本可能返回空字符串
性能敏感场景下的替代建议
高频搜索（如实时输入过滤）中，反复调用 toLowerCase() 会创建新字符串，触发 GC。如果数据集固定且查询频繁，可以预处理：
- 构建索引时就存一份
text.toLowerCase()的副本，搜索时直接比小写版 - 用
Intl.Collator实现更准确的排序与匹配（支持重音忽略、大小写不敏感等），但初始化开销略高 - 纯 ASCII 场景下，手动查表（如
charCodeAt()判断范围再减 32）理论上更快，但可读性和维护性差，一般没必要
真正容易被忽略的是：大小写不敏感匹配 ≠ 重音不敏感匹配。比如 "cafe" 和 "café" 即使都转小写也还是不等，这时候得上 normalize('NFD') 去除变音符号——那是另一个问题了。
