Cast()仅适用于引用类型向上转型或装箱/拆箱逆向还原，不支持隐式转换；Select更通用安全，适合值映射，且错误定位清晰。
Cast() 什么时候能用、什么时候会崩
Cast<t>()</t> 不是万能类型转换器，它只做「引用类型间的向上转型」或「装箱/拆箱的逆向还原」。比如 object[] 里存的是 string，转成 IEnumerable<string></string> 没问题；但要是存的是 int（已装箱），你想转成 long，直接 Cast<long>()</long> 就会抛 InvalidCastException —— 它不调用隐式转换或 Convert.ToInt64()。
- ✅ 能用：从
object[]转回原始类型（原数组元素确实是该类型） - ❌ 不能用：
int→string、double→int、接口→实现类（除非运行时对象真是那个类） - ⚠️ 注意：泛型参数
T必须和实际运行时类型严格匹配，不支持协变推导
示例：
var objs = new object[] { "a", "b", "c" };<br>var strings = objs.Cast<string>(); // OK<br><br>var nums = new object[] { 1, 2, 3 };<br>var ints = nums.Cast<int>(); // OK（装箱的 int 可 Cast 回 int）<br>var longs = nums.Cast<long>(); // ❌ 运行时报错
ConvertAll 更安全，但只属于 List
ConvertAll<toutput></toutput> 是 List<t></t> 的实例方法，靠传入的 Converter<t toutput></t> 委托逐个转换，支持任意逻辑 —— 隐式转换、ToString()、Parse、甚至自定义映射。但它不适用于 IEnumerable<t></t> 或数组，想用必须先确保是 List<t></t>。
- ✅ 优势：可处理
int→string、DateTime→string等真正需要计算的转换 - ❌ 局限：输入必须是
List<t></t>；返回新List<toutput></toutput>，不是懒执行 - ? 替代方案：对普通
IEnumerable<t></t>，用Select(x => (TOutput)x)或Select(Convert.ToInt32)更通用
示例：
var ints = new List<int> { 1, 2, 3 };<br>var strings = ints.ConvertAll(x => x.ToString()); // OK<br><br>// 如果只有 int[]，得先转 List：<br>var arr = new int[] { 1, 2, 3 };<br>var list = arr.ToList().ConvertAll(i => $"num-{i}");
别硬套 Cast，多数时候 Select 才是正解
90% 的“批量转类型”需求其实不是类型擦除还原，而是值映射。比如把 DataRow 转成实体、把 int 转成 Guid、把字符串数字转整数 —— 这些都该用 Select()，配合显式转换或 Convert 类方法。
- ✅
Select(x => (int)x)：适用于有明确定义的强制转换（如long→int） - ✅
Select(Convert.ToInt32)：更健壮，自动处理null（对可空类型）和字符串解析 - ⚠️
Select(int.Parse)：可能抛异常，生产环境建议包TryParse逻辑 - ? 性能提示：如果集合很大且转换开销高，
Select是懒执行，而ConvertAll和ToArray()会立即遍历并分配内存
示例：
var strs = new[] { "1", "2", "3" };<br>var nums = strs.Select(s => int.TryParse(s, out var i) ? i : 0); // 安全解析<br><br>var rows = table.AsEnumerable();<br>var users = rows.Select(r => new User {<br> Id = r.Field<int>("Id"),<br> Name = r.Field<string>("Name")<br>});
Cast 和 Select 的性能与调试差异
Cast<t>()</t> 几乎零开销，就是换个枚举器外壳；Select() 多一层委托调用，但现代 JIT 优化后差距微乎其微。真正影响体验的是错误信息：Cast 失败报的是模糊的 InvalidCastException，连第几个元素出错都不说；Select 报错带完整堆栈，能准确定位到哪次转换崩了。
- ? 调试建议：开发阶段优先用
Select，错误上下文清晰；确认逻辑无误后再权衡是否换Cast - ⚡ 极致性能场景（如高频日志管道）：若确定是纯类型还原，
Cast略优，但通常不值得为这点省略可维护性 - ? 兼容性注意：.NET Framework 3.5+ 和 .NET Core / 5+ 行为一致，但
Cast对值类型数组（如int[]）转IEnumerable<object></object>会触发装箱 —— 别指望它绕过装箱成本
最常被忽略的一点：Cast<t>()</t> 返回的是 IEnumerable<t></t>，但底层没做任何类型检查，直到你第一次 MoveNext() 才抛异常。这意味着延迟报错，可能藏在 foreach 深处，比 Select 更难定位。
