为什么二进制【1000 0000】是 -128 而不是【负零】？（记忆向）

Java里面的byte是8bit的空间；

一直以来都是知道它是存放的是-128到127的整数；但是怎么更好理解呢？

首先8个bit 最高位表示符号位，0正1负；

所以剩下只剩下7个bit来表示数据；

对于能表示多宽范围的值域，正常的思路是把所有二进制bit位变为【全1】；

所以对于8bit的数据最小肯定是个负数，即1开头，后面全1，即【1111 1111】；

理所当然最大的数就是0开头，后面全1，即【0111 1111】；

8bit的各个位的权重如下：

所以对于8位的byte类型，最小的数【直观】（注意，是直观）上是-127，最大的数是127。

不过有两个特殊状态值得注意，一个是1开头的7位全0【1000 0000】，另一个是0开头的全0，即【0000 0000】；后者表示数轴中间状态的0；至此，我们已经有了一个数轴的概念，最左端是-127，最右端是127。而前者【1000 0000】比较特殊，先暂且叫它为【负零】（实际没有这个玩意儿）。

分割线——————————————————————————————

现在就剩下这个【负零】了，也就是【1000 0000】，它为啥是-128呢？

首先紧邻-128的十进制数是-127（即【1111 1111】），高位不动，想要把后面7个1代表的127再增加1，则8位全1加1之后往前进一位，变为【1 0000 0000】，对于8位的byte类型来说，显然这已经超出了8位bit的限制。

但是我们可不可以使用刚才那个【负零】来表示-128呢，显然是可以的，【1000 0000】可以理解为它高位为1，所以是负数，其次，又因为低7位都为零，实际它是【1 0000 0000】当中的后七位的零截取过来的。

另外有一点就是，刚才讨论的都是原码，对于-128的补码是 【1000 0000】（即win10计算器上面的BIN显示补码），而对于16位的容器，-128为：

暂时写到这，还有东西没搞清。