使用C#的in参数修饰符处理Span<T>与ReadOnlySpan<T>是否无弊端？

背景说明 #

in参数修饰符要求目标类型为readonly struct，Span<T>和ReadOnlySpan<T>恰好满足这一条件，典型的合法用法示例如下（修正了原示例的变量名冲突问题）：

void CallerMethod()
{
    Span<decimal> numbers = stackalloc decimal[2] { 5, 6 };
    Method1(in numbers);
}

void Method1(in Span<decimal> numbers)
{
    // 业务逻辑代码
}

潜在的弊端分析 #

虽然语法层面完全合法，但实际使用in修饰符处理这两种特殊类型时，存在几个需要注意的问题：

• 容易引发认知混淆：不少开发者会误以为in修饰后，不仅Span实例本身不可修改，连它指向的内存内容也会被锁定。但实际规则是：in仅限制Span实例自身的状态（比如内存指针、Length属性）不可修改，Span<T>指向的内存内容依然可以正常修改（ReadOnlySpan<T>本身就限制内容不可改，不受in影响）。这种认知偏差可能导致逻辑bug。

• 增加不必要的编译约束：in强制参数为只读引用，如果方法内需要修改Span实例本身（比如执行切片后重新赋值给参数变量：numbers = numbers.Slice(1);），这类操作会直接编译失败，必须额外创建新变量存储修改后的Span，增加了代码冗余。

• 性能收益可忽略，甚至可能引入额外开销：Span<T>是轻量级值类型，仅包含内存指针和长度两个字段，按值传递的拷贝成本极低。使用in虽然避免了这微小的拷贝，但编译器对只读引用的处理可能引入额外的边界检查或优化限制，实际性能和直接传值几乎无差异，部分场景下反而更差。

总结 #

如果你的方法不需要修改Span实例本身，且能清晰区分“Span实例只读”与“内存内容只读”的差异，使用in是可行的，但它没有显著收益，反而可能带来上述问题。多数场景下，直接按值传递Span<T>或ReadOnlySpan<T>是更简单、安全的选择。

内容的提问来源于stack exchange，提问作者Ikenna