为何实际类型与泛型类型的类型赋值表现不同？

非泛型场景：具体类型的宽松兼容 #

当C是明确的{b: string}类型时，C & {a?: any}本质就是给原类型追加了一个可选属性a。对于{b: string}类型的值来说，有没有a都不影响它符合这个交叉类型的要求——毕竟可选属性本来就允许缺失，所以TypeScript直接放行赋值操作。

泛型场景：任意类型参数的严格校验 #

泛型里的C是一个通配符，可以代表任何类型，TypeScript必须考虑所有可能传入的C类型，包括那些会与{a?: any}产生冲突的场景：

• 如果C是{a: number}（a为必填数字类型），C & {a?: any}会将a的类型合并为number & undefined，也就是只能是undefined。但原C类型的实例（比如{a: 5}）的a是number类型，根本无法匹配undefined，此时赋值必然不合法。
• 如果C是原始类型（如string、boolean），C & {a?: any}是一个矛盾类型——字符串、布尔值这类原始值不可能拥有a属性，这种类型几乎没有合法实例，原C的值自然无法赋值给它。

TypeScript在泛型检查时遵循安全优先的原则，不会假设传入的C一定能和{a?: any}安全交叉，因此直接抛出类型不兼容的错误。

关于鸭子类型的误区 #

鸭子类型的核心是“只要拥有目标类型的所有必填属性即可赋值”，但泛型场景中C可能自带与交叉类型属性冲突的定义（比如C的a是字面量类型1，交叉后a必须为undefined），此时原类型并不满足交叉类型的属性要求，自然无法通过鸭子类型的兼容性校验。

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