This was probably a practical decision on the part of the language designers. After all, an int is an Int32, a 32-bit signed integer. Whenever you do an integer operation on a type smaller than int, it's going to be converted to a 32 bit signed int by most any 32 bit CPU anyway. That, combined with the likelihood of overflowing small integers, probably sealed the deal. It saves you from the chore of continuously checking for over/under-flow, and when the final result of an expression on bytes would be in range, despite the fact that at some intermediate stage it would be out of range, you get a correct result.

另一种想法是:必须模拟这些类型上的溢出/欠流，因为它不会自然地发生在最可能的目标cpu上。何苦呢?

从.NET框架代码:

// bytes
private static object AddByte(byte Left, byte Right)
{
    short num = (short) (Left + Right);
    if (num > 0xff)
    {
        return num;
    }
    return (byte) num;
}

// shorts (int16)
private static object AddInt16(short Left, short Right)
{
    int num = Left + Right;
    if ((num <= 0x7fff) && (num >= -32768))
    {
        return (short) num;
    }
    return num;
}

使用。net 3.5及以上版本进行简化:

public static class Extensions 
{
    public static byte Add(this byte a, byte b)
    {
        return (byte)(a + b);
    }
}

现在你可以做:

byte a = 1, b = 2, c;
c = a.Add(b);

This was probably a practical decision on the part of the language designers. After all, an int is an Int32, a 32-bit signed integer. Whenever you do an integer operation on a type smaller than int, it's going to be converted to a 32 bit signed int by most any 32 bit CPU anyway. That, combined with the likelihood of overflowing small integers, probably sealed the deal. It saves you from the chore of continuously checking for over/under-flow, and when the final result of an expression on bytes would be in range, despite the fact that at some intermediate stage it would be out of range, you get a correct result.

另一种想法是:必须模拟这些类型上的溢出/欠流，因为它不会自然地发生在最可能的目标cpu上。何苦呢?

这是由于溢出和携带。

如果您将两个8位数字相加，它们可能会溢出到第9位。

例子:

  1111 1111
+ 0000 0001
-----------
1 0000 0000

我不确定，但我假设int型、long型和double型被赋予了更多的空间，因为它们确实相当大。此外，它们是4的倍数，这对计算机来说更有效，因为内部数据总线的宽度是4字节或32位(64位现在越来越普遍)宽。Byte和short的效率稍低，但它们可以节省空间。

C#

ECMA-334指出，只有在int+int、uint+uint、long+long和ulong+ulong (ECMA-334 14.7.4)上，加法才被定义为合法。因此，这些是关于14.4.2需要考虑的候选操作。由于存在从byte到int、uint、long和ulong的隐式强制转换，所有加法函数成员都是14.4.2.1下适用的函数成员。我们必须根据14.4.2.3中的规则找到最佳隐式转换:

将(C1)转换为int(T1)比将(C2)转换为uint(T2)或ulong(T2)更好，因为:

如果T1是int, T2是uint或ulong, C1是更好的转换。

将(C1)转换为int(T1)比将(C2)转换为long(T2)更好，因为从int转换为long存在隐式转换:

如果存在从T1到T2的隐式转换，且不存在从T2到T1的隐式转换，则C1是更好的转换。

因此使用int+int函数，该函数返回int型。

可以说它深埋在c#规范中。

CLI

CLI只对6种类型(int32、native int、int64、F、O和&)起作用。(ECMA-335分区3节1.5)

Byte (int8)不是这些类型之一，在添加之前会自动强制转换为int32。(ECMA-335分区3节1.6)

我记得曾经读过Jon Skeet(现在找不到了，我会继续找)关于字节如何实际上不会重载+操作符的内容。事实上，当像您的示例中那样添加两个字节时，每个字节实际上都被隐式转换为int。其结果显然是一个整型。至于为什么要这样设计，我将等待乔恩·斯基特自己发布:)

编辑:找到了!这里有关于这个话题的很棒的信息。