params集合增强是C#12起的编译器级新能力，支持非数组类型但需满足构造/添加契约；C#13扩展支持ReadOnlySpan<T>，但不自动避免堆分配，且重载解析仍优先最具体匹配。
params 集合增强不是“语法糖升级”，而是 C# 12 起引入的编译器级新能力——它允许 params 修饰非数组类型，但必须满足构造/添加契约；C# 13 进一步支持 ReadOnlySpan<T>，但不等于“任意集合都能直接用”。
params List<T> 能直接写，但得满足三个条件
你不能随便把 params 往 List<string> 或自定义类上一贴就完事。编译器只接受满足以下任一条件的类型：
- 有无参构造函数（如
new List<int>()） - 有公开的
Add(T item)方法（参数类型需匹配） - 实现
IEnumerable<T>（用于遍历传入的离散参数）
例如：public void Log(params List<string> messages) 合法，因为 List<T> 满足全部三项；但 public void Process(params HashSet<int> nums) ❌ 编译失败——HashSet<T> 没有无参构造函数（.NET 6+ 才有），且 Add 方法签名不被编译器识别为“构造时填充”的标准路径。
传 int[] 给 params object[] 会变成一个元素，不是五个
这是最常被忽略的隐式行为差异：当你调用 Log(new int[] { 1, 2, 3, 4, 5 })，而方法签名是 void Log(params object[] args)，结果 args.Length == 1，且 args[0].GetType() == typeof(int[])。
原因：编译器不会自动拆包数组，它只对“离散参数”做隐式集合构造；传入已有数组时，直接当作单个 object 引用塞进去。
安全做法：
- 如果想支持数组展开，显式用
Log(args.Select(x => (object)x).ToArray()) - 如果方法语义本就该接收“一组对象”，改用
params object[] args+ 文档注明“不展开嵌套数组” - 避免混用
params object[]和泛型集合参数，容易在日志、序列化中暴露类型错觉
C# 13 的 ReadOnlySpan<T> 支持不等于零分配
params ReadOnlySpan<int> 在 C# 13 中合法，但它**不改变调用侧的内存行为**：传离散值（如 Sum(1, 2, 3)）仍会先堆分配 int[]，再转成 ReadOnlySpan<int>；只有传已有的 ReadOnlySpan<int> 或栈上数组（stackalloc）才能真正避免堆分配。
换句话说：params ReadOnlySpan<T> 是“能接住 Span”，不是“自动给你 Span”。性能敏感路径仍需手动控制生命周期。
典型误用：
-
ProcessData(params ReadOnlySpan<byte> data)→ 调用ProcessData(1, 2, 3)依然触发 GC - 正确姿势：
ProcessData(stackalloc byte[256])或ProcessData(source.AsSpan())
params 集合和重载共存时，编译器优先选“最具体”而非“最方便”
当你同时定义：
void Handle(params List<string> items) { ... }
void Handle(IEnumerable<string> items) { ... }
调用 Handle(new string[] { "a", "b" }) 会进第二个重载（IEnumerable<string>），而不是第一个——因为数组类型更直接匹配 IEnumerable<string>，而 params List<string> 需要额外构造步骤。
这意味着：
- 别指望
params集合重载能“兜底”所有传入方式 - 若需统一处理逻辑，建议只保留一个入口（如
IEnumerable<T>），内部按需构造目标集合 -
params集合更适合明确“调用方希望传离散值”的场景，比如配置项、断言字段名、SQL 参数占位符等
真正难处理的从来不是语法怎么写，而是调用链里谁在构造、谁在持有、谁在释放——params 集合让这层关系更隐蔽了。
