装箱和拆箱是值类型与引用类型间隐式的内存迁移操作，非普通类型转换；装箱将栈上值复制到托管堆并返回引用，触发堆分配和gc压力；拆箱则需运行时类型检查后复制回栈，类型不匹配抛invalidcastexception。
装箱和拆箱不是“类型转换”，而是值类型与引用类型之间隐式发生的内存位置迁移操作；不理解这点，就容易在性能敏感场景踩坑。
装箱（Boxing）发生时，int、struct 等值类型到底做了什么
装箱本质是：把栈上的值类型数据，复制一份到托管堆上，并返回一个指向该堆内存的引用（即 object 或接口类型）。这个过程不是“转成对象”，而是“用堆内存包装它”。
- 每次装箱都触发一次堆分配，可能引发 GC 压力，尤其在循环或高频调用中
- 装箱后的对象是独立副本，修改它不会影响原始值类型变量
- 即使对同一个值类型变量反复装箱（如
int i = 42; object o1 = i; object o2 = i;），也会产生两个不同的堆对象 - 结构体（
struct）装箱后，其字段全部被复制进堆，但方法表指针指向的是该 struct 的虚方法表（支持接口实现）
拆箱（Unboxing）不是“取值”，而是带类型检查的指针解引用
拆箱不是简单地把 object 转回 int，而是：检查堆对象是否为指定值类型的装箱实例，若是，则将堆中数据复制回栈 —— 这个过程包含运行时类型验证，失败会抛出 InvalidCastException。
- 拆箱必须指定**精确类型**，
int装箱后不能直接拆成short或long，否则报错 - 拆箱操作本身不分配堆内存，但若后续再装箱（比如拆完又赋给另一个
object），就会重复触发堆分配 - 常见误写：
int i = (int)(object)42;—— 表面看是一次拆箱，实际发生了“装箱 + 拆箱”两次操作 - 使用泛型集合（如
List<int></int>）可完全避免拆箱，因为类型信息在编译期已固化
ToString()、Equals() 等方法调用为何常暗藏装箱
值类型调用继承自 object 的虚方法时，如果未重写，CLR 会自动装箱以获得虚方法表入口。例如：
int x = 123; string s = x.ToString(); // 不装箱：int 重写了 ToString() bool b = x.Equals(456); // 不装箱：int 重写了 Equals(object)
但以下情况会装箱：
- 调用未重写的虚方法，如自定义
struct没重写GetHashCode()，又调用了它 - 用
object变量接收值类型后调用虚方法：object o = 10; o.GetHashCode();→ 先装箱，再调用 - 用反射调用值类型方法（如
o.GetType()）必然触发装箱
如何快速识别和规避不必要的装箱拆箱
最有效的办法是观察 IL（中间语言）或使用工具（如 dotMemory、PerfView）捕获堆分配热点。但日常编码中可盯住几个信号：
- 看到
object、System.ValueType、接口类型（如IComparable）作为参数或返回值，且传入的是值类型，大概率发生装箱 - 使用非泛型集合（
ArrayList、HashTable、Queue）存储值类型时，每增删查都伴随装箱/拆箱 -
string.Format或插值字符串中传入值类型（如$"x={i}"），在 .NET Framework 中会装箱；.NET Core 3.0+ 已优化，但旧项目仍需注意 - 用
ref struct（如Span<int></int>）可彻底避开堆分配，但受限于栈生命周期，不可逃逸到堆
真正难处理的不是“怎么写才不装箱”，而是“为什么看起来没装箱，却在某层间接调用里悄悄发生了”——这类问题往往藏在日志框架、序列化器或第三方库的通用接口之后。
