装箱是值类型隐式转为object或接口类型的堆分配复制过程，拆箱是显式转换并校验类型的逆操作；二者均引发性能开销，常见于非泛型集合、接口赋值、日志及反射等场景。
装箱和拆箱不是“要不要用”的问题，而是“有没有在无意中用”的问题——尤其在泛型集合、接口调用、日志记录、反射或序列化场景里，它们可能已经悄悄发生了几十次。
为什么 ArrayList.Add(i) 比 List<int>.Add(i)</int> 慢得多
关键不在语法，而在内存行为。非泛型集合（如 ArrayList、HashTable）的 Add 方法参数是 object，所以每次传入 int 都触发一次装箱；遍历时用 foreach (int x in list) 又强制拆箱。
- 装箱：为每个
int在堆上分配约 12–16 字节（含类型头、同步块索引），远超int自身的 4 字节 - 拆箱：每次都要做类型检查（是否真为
int），失败则抛InvalidCastException - 10,000 次循环 → 10,000 个短命对象 → GC 压力陡增，可能触发 Gen 0 回收多次
换成 List<int></int> 后，底层是 int[]，全程栈/堆连续内存操作，零装箱拆箱。
unbox.any 和 unbox 的区别在哪
IL 层面有两个指令：C# 编译器通常生成 unbox.any（用于显式转换如 (int)obj），而 unbox 更底层，只返回指针，不自动拷贝值——它常被编译器用于优化路径，比如泛型方法内部。
-
unbox.any int32：检查对象是否装箱自int32，是则拷贝值到栈，一步到位 -
unbox int32：只验证并返回指向堆中值的指针，后续还需ldind.i4才能读出数据 - 日常写 C# 几乎不会直接接触
unbox，但知道它存在，有助于理解 JIT 为何对泛型代码更激进地内联和去虚化
接口实现引发的隐式装箱容易被忽略
值类型实现接口时，只要以接口类型使用，就可能触发装箱——哪怕你没写 object。
struct S : IComparable { public int CompareTo(object obj) => 0; }S s = new(); IComparable cmp = s; // 这里就装箱了- 如果
S是readonly struct且只调用只读接口方法，JIT 在 .NET 5+ 可能避免装箱（取决于具体调用链和内联深度） - 更安全的做法：用泛型约束替代接口引用，例如
void Process<t>(T value) where T : IComparable<t></t></t>，这样T是具体值类型，不走装箱路径
真正难防的是那些“看起来没类型转换”的地方：比如把 int 传给接受 object 的日志方法、用 string.Format 拼接值类型、甚至某些 LINQ 方法（Count() 对非 ICollection 实现会枚举，若源是 ArrayList 就连带拆箱）。性能问题往往不出现在大函数里，而出现在高频小路径上。
