泛型方法类型推断是编译器根据实参类型自动推导泛型参数T的过程;它仅依赖输入参数类型,要求所有T形参实参类型一致且明确,无参数、含null或类型模糊时需手动指定。

泛型方法类型推断,简单说就是:你调用一个带 `
它靠参数“说话”,不是靠返回值
编译器只看方法的输入参数类型,来决定 `T` 是什么。只要所有参数能统一指向同一个具体类型,推断就成功。
-
能推断:`void Log
(T value)` → 调用 `Log("hi")`,`T` 就是 `string` -
能推断:`void Copy
(T[] src, T[] dst)` → 传入 `int[]` 和 `int[]`,`T` 就是 `int` -
不能推断:`T Create
()` → 没有参数,编译器“没线索”,必须写 `Create ()` -
不能推断:`void Process
(T a, List b)` → `U` 完全没在参数里出现,无法关联到 `T`
多个参数要“意见一致”
如果方法有多个泛型参数或多个 `T` 类型的参数,它们的实参类型必须兼容。否则编译器会放弃推断,报错。
- ✅ `Swap
(ref T a, ref T b)` 传两个 `double` 变量 → `T` 是 `double` - ❌ `Swap
(ref T a, ref object b)` 传 `int` 和 `object` → `T` 无法同时是 `int` 又是 `object`,推断失败 - ⚠️ `Print
(T a, T b)` 传 `1` 和 `null` → `null` 无类型,除非 `T` 是可空引用类型(如 `string?`),否则可能失败
它不是万能的,但知道边界就少踩坑
推断失败不等于写错了,只是编译器“需要你帮个忙”。常见需手动指定的场景:
- 方法没有参数(纯靠返回值)
- 参数含 `null`、`default`、`var` 且上下文模糊
- 存在多个重载,编译器分不清该选哪个
- 泛型嵌套太深,比如 `IReadOnlyList
>`,C# 2.0–7.0 对这类支持有限
本质上,类型推断是编译器帮你省掉重复写类型的工作,前提是它有足够明确的输入信号。写代码时,多想想“我传进去的东西,能不能让编译器一眼认出 `T` 是啥”,就基本不会困惑了。











