这是由于溢出和携带。

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

例子:

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

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

我已经测试了字节和int之间的性能。 int值:

class Program
{
    private int a,b,c,d,e,f;

    public Program()
    {
        a = 1;
        b = 2;
        c = (a + b);
        d = (a - b);
        e = (b / a);
        f = (c * b);
    }

    static void Main(string[] args)
    {
        int max = 10000000;
        DateTime start = DateTime.Now;
        Program[] tab = new Program[max];

        for (int i = 0; i < max; i++)
        {
            tab[i] = new Program();
        }
        DateTime stop = DateTime.Now;

        Debug.WriteLine(stop.Subtract(start).TotalSeconds);
    }
}

使用字节值:

class Program
{
    private byte a,b,c,d,e,f;

    public Program()
    {
        a = 1;
        b = 2;
        c = (byte)(a + b);
        d = (byte)(a - b);
        e = (byte)(b / a);
        f = (byte)(c * b);
    }

    static void Main(string[] args)
    {
        int max = 10000000;
        DateTime start = DateTime.Now;
        Program[] tab = new Program[max];

        for (int i = 0; i < max; i++)
        {
            tab[i] = new Program();
        }
        DateTime stop = DateTime.Now;

        Debug.WriteLine(stop.Subtract(start).TotalSeconds);
    }
}

结果如下: 字节:3.57s 157mo, 3.71s 171mo, 3.74s 168mo, CPU ~= 30% int: 4.05s 298mo, 3.92s 278mo, 4.28 294mo with CPU ~= 27% 结论: 字节使用更多的CPU，但它消耗更少的内存，它更快(可能是因为有更少的字节分配)

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上。何苦呢?

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)

除了所有其他伟大的评论，我想我要添加一个小花絮。很多评论都想知道为什么int、long和几乎任何其他数字类型都不遵循这个规则…返回一个“更大”的类型以响应算术。

A lot of answers have had to do with performance (well, 32bits is faster than 8bits). In reality, an 8bit number is still a 32bit number to a 32bit CPU....even if you add two bytes, the chunk of data the cpu operates on is going to be 32bits regardless...so adding ints is not going to be any "faster" than adding two bytes...its all the same to the cpu. NOW, adding two ints WILL be faster than adding two longs on a 32bit processor, because adding two longs requires more microops since you're working with numbers wider than the processors word.

I think the fundamental reason for causing byte arithmetic to result in ints is pretty clear and straight forward: 8bits just doesn't go very far! :D With 8 bits, you have an unsigned range of 0-255. That's not a whole lot of room to work with...the likelyhood that you are going to run into a bytes limitations is VERY high when using them in arithmetic. However, the chance that you're going to run out of bits when working with ints, or longs, or doubles, etc. is significantly lower...low enough that we very rarely encounter the need for more.

从字节到int的自动转换是合乎逻辑的，因为字节的规模是如此之小。从整型到长型，从浮点数到双精度浮点数等自动转换是不符合逻辑的，因为这些数字具有显著的比例。

在添加字节和将结果截断回字节时显示一些低效的答案是不正确的。X86处理器有专门为8位数的整数运算而设计的指令。

事实上，对于x86/64处理器，执行32位或16位操作的效率低于64位或8位操作，因为必须对操作数前缀字节进行解码。在32位机器上，执行16位操作需要同样的代价，但是仍然有专门的8位操作的操作码。

许多RISC架构都有类似的本地字/字节高效指令。那些通常没有存储并转换为某个比特长度的signed值的类型。

换句话说，这个决定必须基于对字节类型用途的感知，而不是由于硬件的底层低效率。