装箱和拆箱是实打实的堆分配、数据拷贝与运行时类型检查，console.writeline(i)、list.add(100)等看似安全的调用会隐式触发boxing；拆箱要求类型完全一致，否则抛invalidcastexception；泛型可从根本上避免boxing；需用内存分析工具定位真实boxing热点。
装箱和拆箱不是“语法糖”，而是实打实的堆分配 + 数据拷贝 + 运行时类型检查；高频路径里一次 Console.WriteLine(i) 或 list.Add(100) 就可能引入不可忽视的 GC 压力和缓存失效。
哪些代码会悄悄触发 boxing（且你根本没写 object）
装箱常发生在“看起来很安全”的调用中，尤其当方法签名接受 object 或接口时：
-
Console.WriteLine(i)（i是int）→ 调用的是WriteLine(object)重载，隐式 boxing -
string.Format("x={0}", value)（value是DateTime或自定义struct）→ 参数数组是object[]，每个值都 boxing -
List<object>.Add(42)</object>→ 明确往泛型为object的集合里塞值类型，必然 boxing -
IComparable comp = DateTime.Now;→ 接口变量引用值类型，只要该接口不是通过泛型约束（如T : IComparable）承载，就触发 boxing -
$"Time: {dt}"（dt是DateTime）→ .NET Core 2.1+ 对基础类型做了插值优化，但老版本或自定义struct仍走ToString()→ 若该方法被虚调用（如重写了ToString），仍可能间接引发 boxing
InvalidCastException 不是运气差，是拆箱类型不匹配的必然结果
拆箱不是“转换”，而是“还原”：它要求目标类型必须与装箱时的原始类型完全一致。哪怕兼容（如 int → long），也不行。
-
object obj = 42;→ 装箱成System.Int32 -
int x = (int)obj;✅ 成功 -
long y = (long)obj;❌ 抛InvalidCastException，因为堆上存的是int，不是long -
if (obj is double)→ 永远 false，is检查的是装箱时的运行时类型，不是“能不能转” - 用
Convert.ToInt32(obj)看似绕过，但它底层仍是先拆箱再转换，类型错照样崩 - 稳妥写法：
if (obj is int i) { /* 直接用 i */ }（C# 7.0+ 模式匹配），一次检查 + 一次拆箱，避免重复开销
泛型不是“更好用”，而是从根上消除 boxing
泛型在编译期为每个值类型参数生成专用 IL，跳过 object 中转层，值直接存在栈/结构体内存中。
-
List<int></int>→ 内部数组是int[]，Add(100)不分配堆、不拷贝、无类型检查 -
ArrayList→ 内部是object[]，Add(100)必须 boxing，每次访问还要拆箱 -
void Log<t>(T value)</t>→ 编译器生成Log<int></int>、Log<datetime></datetime>等独立方法，无 boxing -
void Log(object value)→ 所有值类型传入都先 boxing，哪怕只是打日志 - 注意：泛型约束如
where T : IComparable不会触发 boxing，因为接口调用由 JIT 在运行时内联或使用 constrained call 指令优化
怎么确认你代码里真有 boxing？别猜，看内存分配
真实性能瓶颈不会靠“感觉”，得靠工具定位。装箱的本质是堆上创建值类型对象，所以看“谁在疯狂 new System.Int32、System.DateTime”最准。
- 在 Visual Studio 中启用「性能探查器」→ 选择「.NET 内存分配」视图
- 跑一段典型逻辑（比如 UI 刷新循环、JSON 序列化批量处理）
- 查看热点方法的「已分配字节数」和「实例数」，重点关注
System.Int32、System.Double等值类型的堆分配记录 - 用 JetBrains dotMemory 或 BenchmarkDotNet 的
[MemoryDiagnoser]也能快速比对泛型 vs 非泛型版本的分配差异 - 特别注意：UI 事件回调里每帧调用
Debug.Log(x)（x是Vector3struct）、反序列化 foreach 中调用jsonWriter.Write(item.Value)（Value是int）——这些地方 boxing 往往藏得深、频次高、影响大
真正难处理的不是“会不会 boxing”，而是那些被封装在框架 API 里的隐式 boxing —— 比如某个日志库的 Log(string, params object[])，或者旧版 JSON 库对 int 字段的反射写入。这种时候，要么换库，要么提前 .ToString() 或用 Span<char></char> 格式化绕过。
