.NET BCL为何多采用int而非无符号类型作为方法参数？
这个问题问得非常好！其实.NET框架里大量选用int作为数值参数类型，背后有好几个关键的设计考量，不光是有没有负数需求这么简单：
历史兼容性与API一致性
.NET框架设计初期，就对齐了很多Win32原生API的参数类型——而Win32里大量使用32位有符号整数（对应C#的int）作为计数、延迟、长度等参数。为了让开发者从原生API过渡到.NET时更顺手，同时保持整个API体系的一致性，后续的方法也延续了这个选择。比如早期的Thread.Sleep(int millisecondsTimeout)，后来的Task.Delay(int millisecondsDelay)都遵循了这个传统，避免给开发者带来不必要的认知负担。规避无符号类型的潜在陷阱
像uint、ushort这类无符号类型，在实际开发中容易引发意外问题：比如当你需要对参数做减法运算时，uint的0减1会直接溢出成最大值（uint.MaxValue），这种行为在多数场景下不是开发者预期的；另外，无符号类型和有符号类型之间的隐式转换容易出错，泛型集合（比如List<int>）也无法直接兼容无符号类型，会增加代码的复杂度。即使某些方法现在不需要处理负数，框架设计时也会优先避免这类潜在的bug风险。性能与内存的平衡
现代CPU的寄存器多是32位或64位的，处理int类型的效率和short、byte几乎没有区别——甚至有时候int更快，因为它是CPU的“自然”处理长度。而内存层面，单个参数的int和byte差别微乎其微，对于绝大多数API来说，这点内存优化完全不值得牺牲API的简洁性和兼容性。通用性与扩展性预留
int的取值范围（-231到231-1，约±20亿）足够覆盖绝大多数业务场景：比如Task.Delay的最大值约24天，完全满足日常的延迟需求；即使是数组长度，int支持的20亿元素也远超普通程序的实际需求。更重要的是，提前选用int可以为未来的扩展预留空间——比如有些方法现在不需要负数，但后续可能需要添加特殊标记（像Task.Delay(-1)表示无限延迟），如果一开始用了uint，就不得不修改API，造成破坏性更新。
举个典型例子：Array.Length属性是int类型，虽然数组长度不可能为负，但选用int就是为了和整个.NET API体系保持一致，同时避免无符号类型带来的转换问题。
内容的提问来源于stack exchange，提问作者YehHyunLee
