应优先使用C# 7+命名元组（如(int id, string name)），轻量且可读；重复出现、需方法/序列化或语义模糊时改用record或自定义类；避免混用ValueTuple与旧Tuple。
用 Tuple.Create 快速返回多个值，别手写类或 out 参数
直接用 Tuple 是最轻量的多返回值方案，尤其适合临时组合、内部方法、原型阶段。它不需定义新类型，调用侧也能立刻解构——但得注意命名缺失带来的可读性风险。
-
Tuple.Create(1, "ok", true)推断出Tuple<int string bool></int>，比手动写构造函数省事 - 返回值是只读的，字段名固定为
Item1、Item2… 不能改名，看代码时容易懵 - 如果函数要被多人调用或长期维护，
Item1到底代表 ID 还是 Code？没人知道，靠注释撑不住 - 性能无压力：值类型包装开销极小，但频繁分配（比如循环里）会增加 GC 压力
用命名元组语法让 Item1 变成 id 和 name
C# 7+ 支持命名元组，本质还是 Tuple，但编译器帮你加了字段别名，既保兼容又提可读。
- 声明返回类型时直接写
(int id, string name, bool success)，调用方能用result.id访问 - 函数内 return 仍可用
(123, "test", true)，顺序和名称必须严格对应，否则编译报错CS8129 - 命名只是编译期特性，反编译后仍是
Item1，跨程序集调用时对方看不到你的命名（除非也用 C# 7+ 且引用同一份源码） - 别混用：写
(int, string)返回，却想用.id—— 编译不通过，命名必须显式声明
什么时候该换 record 或自定义类，而不是硬扛元组
元组适合“一次性的数据包”，一旦出现以下任一情况，就该停手、建类型：
- 相同结构在多个地方重复出现（比如
(DateTime start, DateTime end)在日志、统计、API 里各来一遍） - 需要方法、验证逻辑或默认值（元组字段全 public readonly，没法加
get计算属性） - 要序列化到 JSON 或数据库，元组字段名默认变成
Item1，除非手动配JsonPropertyName - 团队里有人吐槽“又看到三个
Item，我猜第四个是状态？”——说明语义已经模糊到影响协作
ValueTuple 和旧版 Tuple 别搞混
现在写的 (int, string) 其实是 ValueTuple<int string></int>，栈上分配，轻；而老式 Tuple.Create(...) 是引用类型，堆上分配。两者不兼容，不能互相赋值。
- 用
var t = (1, "a")→ 得到ValueTuple - 用
var t = Tuple.Create(1, "a")→ 得到旧Tuple，性能差，且无法用命名解构 - VS 提示“使用语言支持的元组”时，别点“全部替换”，先确认项目没引用旧框架（如 .NET Framework 4.6.1 以下）
- 检查生成的 IL：如果看到
System.ValueTuple`2就对了；要是System.Tuple`2，说明你还在用过时写法
实际写函数时，第一反应应该是命名元组；但只要这个组合出现超过两次，或者字段含义开始让人犹豫，就得停下来建 record——不是为了“规范”，是怕下周你自己回来读，也得查十分钟。
