问在java中，为什么不加宽然后框呢？

EN

我不知道这个规范是如何编写的，但一般来说，你不会在不兼容的类之间自动转换。原语的加宽是一个单独的问题，Java加宽规则早在自动装箱被添加到语言之前就已经制定好了。这是一种权衡，一方面让编译器捕捉到你的错误，另一方面又不会因为一些小细节而激怒你。

在您的示例中，如果您已经自动装箱了一个long，那么您就可以了，或者如果您已经创建了一个以Number为参数的函数，那么您也可以。你可能会认为编译器应该通过意识到Byte可以很容易地拆箱和重新装箱作为Long来帮助你，但是编译器的人并不同意，我也不是。

编译器可以执行装箱操作，然后执行加宽操作，以便将调用与方法相匹配。让我们举个例子

 class BoxAndWiden {
   static void go(Object o) {
   Byte b2 = (Byte) o; // ok - it's a Byte object
   System.out.println(b2);
   }
    public static void main(String [] args) {
    byte b = 5;
    go(b); // can this byte turn into an Object ? 
    }
    }

这将编译(!)并产生输出:5让我展示一下它是如何在scene.when后面工作的，转到调用go()方法的行：

1. 字节b被装箱为一个字节。
2. 字节引用被加宽为一个对象(因为字节扩展了对象)。
3. go()方法获得一个实际引用字节对象的对象引用。
4. go()方法将对象引用转换回字节引用(请记住，在此方案中从来没有对象类型的对象，只有字节类型的对象！)。

<代码>H110 go()方法打印字节的值。<代码>H211<代码>G212

但是在您的case.Why中，当编译器试图处理WidenAndBox类时，难道没有尝试使用先框后宽的逻辑吗？

如果它首先尝试装箱，字节将被转换为字节。现在我们又回到了尝试将字节加宽为长字节，当然，IS-A测试失败了。

我认为主要原因是性能。如果您允许任意组合加宽和(取消)装箱，则需要检查是否存在更多可能匹配的方法。特别是在函数需要多个小范围基元参数的上下文中，可能的组合数量可能会变得相当大。