在实际的业务开发中，为了促进弹簧容器中的bean对象，一个常见的情况是创建一个Springutil类，该类内部持有SpringContext上下文，然后提供了获取Bean对象的静态方法。然而，事故可能导致NPE。
让我们今天看看这个场景。
构建一个基本的Springboot项目。此处省略了具体过程。关键信息如下标记
该项目由 + +开发
打开用于测试的网络服务
建立一个基本的Springutil工具类，并在SpringContextaware的帮助下保持上下文
首先构建一个简单的豆对象
然后是另一个对象，依靠上述对象，提供给外界的主要接口是其内部实现是基于枚举类别的策略选择。
专注于上述实施的枚举类别。在枚举类中，获得基于springutil的对象，然后执行其私人方法和 - 包装方法
这种用法有什么问题吗？
接下来，写一个简单的接口测试
下次访问以查看将是什么
什么？不是NPE吗？这不是正常返回！
下一步是见证错误，上面的相同代码，让它出现NPE
接下来，我们添加剪切表面，目的是让获得的对象是代理类
然后重复上述访问
私人方法在这里扔了。从服务器的堆栈中，您可以看到异常类型是NPE。主要原因是无效
简而言之，当访问代理类的私人方法时，如果有内部bean对象，目前为null
这有点奇怪，所以让我们再次更改它。请勿直接在私有方法中使用注入的bean对象。继承豆对象的常见方法。会发生什么？
重写上面的show（）方法
再次测试，输出如下：
没问题！交叉剖面
这是如此神奇，所以原因是什么？
看来我只是进入主体，结果就在这里。太多了？首先，让我们首先总结此问题的场景。至于具体原因，它必须
当我们获得通过SpringContext获得的BEAN对象时，请勿直接访问其私有方法，这可能会导致NPE
100％第一场景
当您看到上述内容时，会有一个问题，谁将访问私人方法？我的想法没有扎根？此外，私人方法无法在外面访问。
这涉及一个非常普遍的场景。内部方法A调用切割面条部分的方法。目前，我们经常这样做。
上述方法，访问测试B方法可以采用切割逻辑。在上类中，可能有一个直接使用的场景。
此外，当反映某种逻辑时，也可能会有一种私人的访问方法，并且不会在这里扩展；
欢迎有兴趣的朋友回复互动，您也可以关注我的公共帐户：一个灰色的博客