好了，有几种方法可以实现代理对象。但是，由于您希望代理与被代理bean具有“相同”类型，因此您必须使用继承（或您随后可以实现的需求接口，但这不是每个POJO都可以是一个bean的方法）
CDI）。
也就是说，它们从您要注入的类内部扩展，围绕该类生成一些代理代码，然后为您提供该子类。
然后，该代理将处理所有魔术，以确保您始终有一个适合您上下文的bean（并且该bean的所有成员变量bean均指向正确的bean）。
因此，您实际上并没有收到要注入的bean的类型，而是该bean的代理子类。这对于最终方法和类以及私有构造函数而言效果不佳。
如果该类不是final，则代理可以扩展该类，但是它不能轻易覆盖您的final方法。但是，这可能是需要的（例如，如果您的bean已序列化，则代理需要对其进行反序列化）。
有更复杂的方法可以解决。可以通过通过代理操作类的字节码来注入此功能（例如，删除最终修饰符，注入默认构造函数等），甚至可以将其与继承混合使用，但这还没有实现（和同样对支持多个JVM实现也很重要）。
在链接的资源中，有一条注释表明已计划在将来的发行版中使用：
注意
未来的Weld版本可能会使用非便携式JVM
API支持针对此限制的非标准解决方法：Sun，IcedTea，Mac：Unsafe.allocateInstance（）（最高效）IBM，JRockit：ReflectionFactory.newConstructorForSerialization（）但是我们还没有实现这个目标。
