关于Array.prototype.indexOf()类型定义的困惑与优化问询

当前定义的原因 #

TypeScript 标准库中 Array.indexOf 的类型定义如下：

interface Array<T> {
    /**
     * Returns the index of the first occurrence of a value in an array, or -1 if it is not present.
     * @param searchElement The value to locate in the array.
     * @param fromIndex The array index at which to begin the search. If fromIndex is omitted, the search starts at index 0.
     */
    indexOf(searchElement: T, fromIndex?: number): number;
}

这个设计的核心目的是严格的类型安全校验：它能在编译期拦截明显的逻辑错误，比如向数字数组传入字符串的情况（[1,2,3].indexOf("foo")），避免这类错误留到运行时才暴露。TypeScript 标准库的类型设计通常偏向保守，优先保障类型严谨性，减少潜在的意外问题。

现有定义的不合理场景 #

但正如你提到的，当需要检查T的超集类型值是否在数组中时，这个限制就显得冗余。比如：

declare const arr: Array<'a'>;
declare const s: string; // API 返回的未知字符串

arr.indexOf(s) // 报错：类型'string'不能赋值给类型'"a"'

从语义上看，indexOf 本身就包含"值不存在则返回-1"的逻辑，用通用类型（如string）检查字面量数组的存在性是完全合理的业务场景，现有定义却强行阻止了这种合法操作。

优化方案的可行性 #

你提出的改进定义思路是可行的，通过泛型条件类型限制仅允许T的超集作为参数，既放开了合理场景的限制，又能阻止完全无关的类型比较。可以优化一下，保留fromIndex参数并使用never替代字符串提示，让错误信息更符合TypeScript的风格：

interface Array<T> {
  indexOf: <U>(searchElement: T extends U ? U : never, fromIndex?: number) => number;
}

这个定义的逻辑是：只有当U是T的超集（即T的所有可能值都属于U类型）时，才允许传入U类型的参数；如果是完全无关的类型（如number和string），则参数类型会被推断为never，编译期直接报错，保留了对无效类型的拦截能力。

标准库未修改的可能原因 #

目前TypeScript标准库没有采用这类定义，大概率是出于兼容性考量：现有大量代码依赖当前的严格校验逻辑，突然放宽类型限制可能会导致一些隐性的类型问题暴露，或者打破既有的代码校验习惯。TypeScript团队在调整标准库类型时，会优先保证向后兼容性，不会轻易变更已有行为。

自定义实现方式 #

如果你需要在项目中使用这个优化后的类型，可以通过全局模块扩充来覆盖标准库的定义：

declare global {
  interface Array<T> {
    indexOf: <U>(searchElement: T extends U ? U : never, fromIndex?: number) => number;
  }
}

// 测试示例
const arr: Array<'a'> = ['a'];
const s: string = 'b';
arr.indexOf(s); // 不再报错，符合预期

内容的提问来源于stack exchange，提问作者sixn