共计 626 个字符，预计需要花费 2 分钟才能阅读完成。
如题所示本周遇到了这样的报错。
翻译过去就是类继承了 undefined 或不是构造函数或 null，能够初步确定问题呈现在给出报错的类所继承的类中。
咱们以后的报错类是在 taskApproveService 中。
也就是说能够推断出是他的父类呈现了问题。
搜寻之后发现这个报错次要是因为我的项目本身配置问题或者是存在循环依赖。
首先能够排除是我的项目本身问题，那么问题就呈现在咱们新增的代码局部。
然而依据我之前的教训来看，怎么看也看不出来会存在循环依赖的的中央。
之后又再网上查找了其余解决办法，然而都不实用。
起初又去代码中查看报错地位和咱们新增代码的分割后终于发现了问题所在。
咱们新增的代码构造，圈起来的局部是我所更改的中央：
当系统启动时会实例化 taskApproveService，也就是报错地位的 service，而后他去调用它的父类去注入父类所须要的类，父类注入了 taskAutoMationService，进而一步步注入，直到 taskService，而 taskService 由注入了 taskApproveService，从而导致 TaskBaseService 结构失败，也就呈现了如上的报错。
也就是说下面的报错能够由父类存在循环依赖而引发。
当咱们再写较大的我的项目时兴许呈现这种谬误时很常见的，然而因为之前写的我的项目都较小，循环依赖往往只呈现在两三个文件中并且之前遇到的报错更为人性化———把循环依赖的整个流程都提醒进去。这也就导致了这个经典问题节约了不少工夫。
正文完
