TypeScript 的结构化类型系统在比较两个对象类型时，关注的是成员签名是否可赋值，而不是它们是否来自同一个类或接口。方法成员的可选参数让这种比较变得容易混淆：一个常见直觉是参数个数不同就必然不兼容，但实际上可选参数在参数数量检查中属于可省略项，并不会直接阻断赋值。下面从方法签名与函数属性的差异开始，逐步拆解可选参数参与兼容性判断的完整过程。

一、方法签名与函数属性在兼容性上的起点差异

在 TypeScript 中，对象类型的方法有两种常见声明方式。第一种是方法签名：

interface Source {
  handle(value: string, flag?: boolean): void;
}

第二种是函数属性：

interface SourceFunc {
  handle: (value: string, flag?: boolean) => void;
}

这两者在类型检查上并不总是一样。方法签名语法默认参与 TypeScript 的双变参数检查，即便开启了 strictFunctionTypes，方法签名仍然保持较为宽松的兼容性；而函数属性在开启 strictFunctionTypes 后会执行逆变检查。可选参数无论放在哪种写法中，都会先影响参数数量比较，再影响参数类型比较。理解这一点是分析后续赋值行为的前提。

参数数量检查的基本规则是：期望类型中的每个必需参数，在源类型中必须有对应参数；期望类型中的可选参数则不强制源类型提供。换句话说，可选参数在目标侧不会制造负担，在源侧也不会阻碍赋值。这个规则解释了为什么一个带额外可选参数的方法，可以被赋值给参数更少的方法类型。

二、用赋值方向拆解可选参数的检查流程

假设有两个接口：Source 的方法带一个字符串参数和一个可选布尔参数，Target 的方法只带一个字符串参数。把 Source 类型变量赋给 Target 类型变量时，编译器会检查 Target 的调用方式能否由 Source 的方法满足。

interface Source {
  handle(value: string, flag?: boolean): void;
}
interface Target {
  handle(value: string): void;
}
declare let source: Source;
declare let target: Target;
target = source; // 允许：target 只需要一个参数，source 的第二个参数可选

这里的判断逻辑是：Target.handle 只可能用一个 string 参数调用，而 Source.handle 的第一个参数是 string，第二个参数 flag 即使不传也可以，因此源方法完全能够覆盖目标方法的调用场景。参数类型层面，string 可以赋给 string，检查通过。

反过来执行 source = target 也同样通过，原因在于 Source.handle 的第二个参数被声明为可选，所以期望类型并不要求源方法必须声明这个参数。即便 Target.handle 只有一个形参，它依然可以满足带可选参数的 Source.handle 的调用约束。这个双向通过的现象说明，可选参数同时放宽了来源类型和目标类型两侧的限制。

source = target; // 也允许：可选参数不要求 target 方法有形参对应

如果把可选参数改成必选参数，行为就会改变。Target.handle 只有一个参数时，Source.handle 若要求两个必选参数，target = source 会报错，因为源方法无法在缺少第二个参数的情况下被正常调用。这个对比能直观看出可选参数在数量检查中的权重。

三、strictFunctionTypes 下可选参数与方法签名的交互

strictFunctionTypes 是 TypeScript 中影响函数类型参数检查的重要编译选项。开启后，函数属性类型的参数会采用逆变方式比较，也就是目标函数参数类型必须能够赋给源函数参数类型，而不是源参数类型赋给目标参数类型。不过这个逆变规则只作用于函数属性，不作用于方法签名。也就是说，同样的参数列表，写成方法签名和写成函数属性，在严格模式下可能得到不同结果。

考虑函数属性版本的接口。用联合类型参数来观察差异：

interface SourceFunc {
  handle(value: string | number, flag?: boolean): void;
}
interface TargetFunc {
  handle(value: string): void;
}
declare let sourceFunc: SourceFunc;
declare let targetFunc: TargetFunc;
targetFunc = sourceFunc; // 逆变下：目标 value: string 可赋给源 value: string | number，允许

这段代码中，目标参数类型 string 是源参数类型 string | number 的子集，因此逆变检查通过；可选参数 flag 没有阻碍数量匹配。反向赋值则可能因为参数类型范围不同而报错，因为期望的 string | number 并不能安全地由实际只接受 string 的函数覆盖。方法签名版本即使开启严格模式，也不会执行这种逆变约束，因此更容易通过赋值检查。

可选参数在严格模式下的另一层影响是它会被自动视为包含 undefined。例如 flag?: boolean 的参数类型实际上是 boolean | undefined，只是在声明时省略了显式联合。进行参数类型比较时，这个 undefined 分支同样参与判断，不能忽略。如果目标参数类型是 boolean，而源参数是 boolean | undefined，在某些逆变场景中就可能产生类型错误。

四、常见误区与接口设计时的实践建议

一个典型误区是认为只要源对象方法比目标对象方法多参数，赋值就一定失败。实际上源方法多出来的参数如果是可选参数，赋值通常可以通过，因为可选参数不会增加调用方的传参负担。真正需要关注的是多出来的参数是否被声明为必选，以及参数类型是否满足对应方向的兼容关系。

另一个容易被忽略的问题是超额属性检查。对象字面量的额外属性会触发专门检查，但普通变量赋值给接口时不会执行同样的超额属性检查。因此即使某个对象字面量写法因为多余属性报错，也不代表它的类型与实际接口不兼容，这与可选参数的数量检查是两套不同机制。

设计对外接口时，如果希望回调或方法适配更广泛的调用场景，可以优先把某些非关键参数声明为可选，这样实现方和调用方都能获得更大灵活性。如果业务上确实需要严格限制参数数量和类型，建议使用函数属性声明回调，同时开启 strictFunctionTypes，并谨慎使用可选参数。否则可能因为方法签名的双变规则，让原本想拦截的类型错误在编译期静默通过。

• 方法赋值时先看必需参数数量是否匹配，可选参数不参与强制匹配。
• 方法签名保持双变，函数属性在严格模式下执行逆变。
• 可选参数自动包含 undefined，比较联合类型时不能忽略。

把这几条规则与具体赋值方向结合起来分析，就能更准确地判断含可选参数的对象类型方法何时兼容、何时报错，而不必依赖记忆零散示例。TypeScript 的类型兼容性看似复杂，但只要抓住参数数量、参数类型和方法签名差异这三个维度，大部分可选参数相关的检查结果都可以被推导出来。