params是编译器强制支持的可变参数机制，必须为最后一个参数且仅支持一维数组；传多个值会新建数组触发堆分配，性能敏感路径应避免。
params 不是语法糖，而是编译器强制支持的可变参数机制；它能简化调用，但每次传多个值都会新建数组、触发堆分配，性能敏感路径要避开。
params 必须是最后一个参数，否则编译直接报错 CS0227
这是硬性规则，不是建议。编译器不接受任何例外：
- void Log(string level, params string[] msgs, bool ts) → ❌ 编译失败
- void Log(params string[] msgs, string level) → ❌ 同样失败
- void Log(string level, bool ts, params string[] msgs) → ✅ 唯一合法顺序
哪怕你只打算传一个 string，params 也必须收尾。它后面不能跟任何其他形参，包括可选参数、ref、out —— 这些都会导致 CS1736 或 CS0227。
params 只支持一维数组，不能是 List、T[][] 或 T[,]
常见误用全被编译器拦截：
-
params int[][] grids→ ❌ CS0225：“The params parameter must be a single-dimensional array” -
params List<string> items</string>→ ❌ CS1615：“Argument is not valid for parameter” -
params string[,] matrix→ ❌ 类型不匹配，无法隐式转换
真正能用的只有 params T[] 形式。想传集合？得显式调用 .ToArray()；想支持二维数据？得改用普通参数接收 int[][] 或 IEnumerable<int></int>，别指望 params 替你兜底。
传多个值 vs 传已有数组，内存行为完全不同
表面结果一样，底层开销天差地别：
-
Sum(1, 2, 3)→ 编译器生成新int[3]，堆分配 + 元素拷贝 -
Sum(arr)（其中arr是已存在的int[]）→ 直接传递引用，零分配 -
Log(null)→values为null，访问Length就崩，必须手动判空：values ??= Array.Empty<string>()</string>
尤其注意 params object[]：传 new int[] { 1, 2 } 会被当做一个元素（System.Int32[]），而不是两个 int —— 日志或序列化时容易漏掉整个数组内容。
泛型方法里用 params，类型推导按实参而非数组元素
写 void Process<t>(params T[] items)</t> 看似通用，但调用时行为反直觉：
-
Process(1, "hello")→ 编译失败：无法统一推导T为int和string -
Process(1, 2)→T推导为int，没问题 -
Process(new object[] { 1, "hello" })→T推导为object，但数组里每个元素仍是装箱后的值
泛型 + params 不解决混搭类型问题，也不自动适配子类。真需要灵活类型组合，优先考虑 params object[] + 显式类型检查，或拆成多个重载。
最易忽略的一点：params 的堆分配成本在高频小调用中会快速累积，比如日志打点、事件分发循环里反复调用 Log("a", "b", "c") —— 这种场景更适合预分配缓存数组，或改用 Span<t></t> + ReadOnlySpan<t></t> 配合重载，而不是依赖 params 的便利性。
