如何用String.prototype.includes替代indexOf进行更直观的包含判断
includes比indexOf更直观，但要注意它不支持正则
想判断一个字符串里是否包含某个子串？用 includes() 确实更直观——语义清晰，直接返回布尔值，省去了和 -1 比较的繁琐步骤。不过，它的能力边界也很明确：参数只认字符串。如果你不小心传了个正则表达式进去，它会毫不客气地抛出一个 TypeError，提示你第一个参数必须是字符串。
一个常见的坑是，开发者习惯性地把原本用在 indexOf() 场景的正则对象（比如 /abc/g）直接塞给 includes()。这招行不通。遇到需要正则匹配的情况，还是得老老实实用 test() 或者 match()。
大小写敏感是默认行为，忽略大小写得自己处理
includes() 默认是区分大小写的，这一点和某些工具库里可能提供忽略大小写选项的 contains() 函数不同。要实现忽略大小写的匹配，最稳妥的做法是手动统一转为小写再进行比较：
const str = "Hello World";
str.toLowerCase().includes("hello"); // true
这里有个细节：通常更推荐使用 toLowerCase() 而非 toUpperCase()，除非你能确保输入的字符串不包含像德语 ß 这类在大小写转换中有特殊行为的 Unicode 字符。另外，千万要留意空值问题——如果原字符串或者搜索词有可能是 null 或 undefined，直接调用 toLowerCase() 就会导致运行时错误。稳妥的做法有两种：
- 在使用前先用
typeof str === 'string'做类型检查。 - 或者，使用空值合并运算符：
(str ?? '').toLowerCase().includes(search)。
性能差异微乎其微，但 indexOf 能定位位置
如果只是单纯地问“有没有”，那么在 V8 这类主流 Ja vaScript 引擎中，includes() 和 indexOf() !== -1 的底层实现效率几乎不相上下。别指望通过切换这两个函数来获得显著的性能提升。它们之间真正的差异，体现在语义和后续操作的便利性上。
关键在于，includes() 只告诉你“是否包含”，却不告诉你“在哪里”。如果你的后续逻辑还需要用到子串出现的位置（比如进行截取、替换或高亮显示），那么坚持使用 includes() 就显得有点别扭了。这时，保留 indexOf() 才是更自然的选择：
const pos = str.indexOf("target");
if (pos !== -1) {
console.log(`found at ${pos}`);
return str.slice(pos);
}
IE 不支持 includes，必须考虑兼容性兜底
兼容性是个老生常谈但至关重要的问题。Internet Explorer 浏览器完全不支持 includes() 方法。即使你的项目使用了 Babel 进行转译，它也不会自动为原型方法添加 polyfill（因为 Babel 主要处理语法）。因此，在上线前，务必确认你的目标运行环境，或者手动提供一个补丁：
if (!String.prototype.includes) {
String.prototype.includes = function(search, start) {
return this.indexOf(search, start) !== -1;
};
}
上面这个 polyfill 实现了标准的 start 参数，行为与规范一致。当然，如果你的项目已经引入了 Lodash，直接使用 _.includes(str, search) 会更省心——它内部已经妥善处理了类型转换和兼容性问题。
还有一个容易在服务器端被忽略的场景：Node.js 在 v4.0.0 之前的版本也不支持 includes()。如果你的应用涉及服务端渲染（SSR），并且在低版本的 Node 环境中运行，使用了 includes() 就可能导致服务直接崩溃，这一点需要特别警惕。
