C# 13 不支持 params Span，编译器强制要求 params 必须为一维数组类型；可行方案是重载方法或接受 ReadOnlySpan 并由调用方用 stackalloc 构造栈上 span。
params Span 在 C# 13 中根本不能直接使用
你无法写 void M(params Span<int> values)</int> —— 编译器会报错 CS0225: The params parameter must be a single-dimensional array type。C# 13 并未放宽 params 对参数类型的限制，它依然只接受一维数组（T[]），不支持 Span<t></t>、ReadOnlySpan<t></t> 或任何其他类型。这是语言规范层面的硬性约束，和性能优化无关。
想用 Span 做高性能可变参数，得绕开 params
真正可行的路径是：用方法重载 + 显式 Span<t></t> 参数，配合栈分配（stackalloc）或借用已有内存。这不是“语法糖”，而是主动控制内存生命周期。
- 对少量固定数量（如 ≤4），提供重载：
void M(int a)、void M(int a, int b)… 避免分配，JIT 可能内联 - 对动态数量，暴露
ReadOnlySpan<t></t>入参：void M(ReadOnlySpan<int> values)</int>，调用方自行构造 span（例如M(stackalloc int[3] {1,2,3})） - 避免在方法内部把
Span<t></t>转成T[]—— 这会触发堆分配，抵消所有优化 - 注意：
stackalloc只能在unsafe上下文或 C# 13 的安全栈分配（需AllowUnsafeBlocks = true且目标框架 ≥ .NET 8）中使用
C# 13 真正相关的改进是 stackalloc 表达式增强
C# 13 允许在更多位置使用 stackalloc，比如直接作为参数传给 ReadOnlySpan<t></t> 方法，且无需显式 unsafe 块（只要方法签名接受 ReadOnlySpan<t></t>）：
void Process(ReadOnlySpan<byte> data) { /* ... */ }
// C# 13 下合法（.NET 8+）
Process(stackalloc byte[256]);但这不是 params Span<t></t>，而是调用方更方便地生成栈上 span。关键点在于：方法签名本身仍是普通 ReadOnlySpan<t></t>，不是 params。
别被“params 优化”误导，Span 的价值在控制权转移
真正的性能收益来自两点：一是避免堆分配（不用 new int[n]），二是让调用方决定数据来源（栈、堆、native 内存、数组切片）。一旦你强行套 params，就得接受编译器强制转成数组 —— 这反而引入了不必要的分配和拷贝。
最容易被忽略的是生命周期：Span 不能逃逸到异步操作或存储在字段里。如果你试图把它塞进 Task.Run(() => { /* use span */ })，编译器会报错或运行时崩溃。优化的前提是理解 Span 的契约，而不是把它当成 params 的更快替代品。
