Deconstruct方法必须是public void实例方法且参数全为out类型，编译器按参数个数静态绑定解构变量顺序；元组解构无需实现Deconstruct但类型推导严格按位置和元素类型；结构体解构会复制值，需确保每个out参数被赋值。
Deconstruct 方法必须是 public 实例方法，且不能有返回值
解构不是语言自动提供的魔法，它依赖你手动实现 Deconstruct 方法。C# 编译器在看到 var (x, y) = obj; 这种写法时，会查找目标类型是否有匹配签名的 Deconstruct 方法——必须是 public void，参数为 out 类型，顺序对应你要解构出的变量。
常见错误：把方法写成 private、加了 return、参数用 ref 或没写 out、参数名和解构变量名强绑定（其实无关）。
-
Deconstruct方法名大小写必须完全一致，C# 区分大小写 - 参数数量决定你能写几个变量：
var (a, b, c) = obj;要求三个out参数 - 不支持重载区分「解构成 2 个还是 3 个」——编译器按参数个数静态绑定，同个类型只能有一组固定参数个数的
Deconstruct
元组解构最安全，但要注意命名丢失和类型推导陷阱
元组自带解构能力，不用写 Deconstruct，比如 (int, string) 可直接 var (id, name) = GetUser();。但别以为名字能保留——除非你用命名元组，否则解构后变量名和原始元组字段名无关，只是按位置赋值。
容易踩的坑：
- 写
var (x, y) = (1, "abc");，x是int、y是string，没问题；但写var (x, y) = (Value: 1, Name: "abc");，x和y仍是按位置，不是按Value/Name名字匹配 - 如果函数返回
ValueTuple，而你解构成var (id, name)，id的类型就是int?，不是int——类型推导严格按元组元素类型来 - 嵌套元组如
(int, (string, bool))可以多层解构：var (i, (s, b)) = t;，但括号必须对齐，少一个就编译失败
类/结构体解构时，out 参数顺序即解构顺序，和属性名无关
你定义的 Deconstruct 方法参数顺序，完全决定了解构语法里变量的顺序。哪怕类里属性叫 FirstName、LastName、Age，只要你 Deconstruct 写成 void Deconstruct(out int age, out string firstName, out string lastName)，那 var (a, f, l) = person; 中 a 就是 Age，f 是 FirstName，l 是 LastName。
这点特别容易混淆，尤其从 JSON 或数据库映射过来的对象，下意识以为按属性声明顺序或字母序解构。
- 没有机制让编译器“猜”你想按什么逻辑解构，全靠你写的
out参数顺序 - 如果类有多个构造逻辑（比如支持 ID+Name 或 Name+Email 两种主干数据），别试图靠多个
Deconstruct重载实现不同解构路径——C# 不支持，只能选一种主流顺序 - 结构体也能用，但注意值类型语义：解构过程会复制整个结构体再调用
Deconstruct，大结构体慎用
解构失败不会抛异常，但可能因 out 参数未赋值导致运行时错误
编译器只检查 Deconstruct 方法是否存在且签名匹配，不验证方法体内是否真的给所有 out 参数赋了值。如果漏写某个 out x = ...;，编译能过，但运行到解构那行会报 Use of unassigned local variable 'x'——这个错误发生在调用方代码里，而不是 Deconstruct 方法内部。
这是最隐蔽的坑：错误提示指向解构语句，但根因在 Deconstruct 实现里。
- 务必确保每个
out参数都在方法末尾前被明确赋值，哪怕只是out var = default; - 如果解构逻辑有分支（比如根据状态返回不同字段），每个分支都得覆盖全部
out参数 - 单元测试里别只测「能解构」，要测解构后各变量的值是否符合预期——因为编译器不帮你校验业务逻辑
解构看着简洁，但它的契约全靠你手写 Deconstruct 方法去维持，任何疏漏都会拖到运行时才暴露，而且错误位置和原因常常错位。
