0909录入redis、envlove、报警三这的地位与联系

首先录入redis可以结合之前所作的项目，往往是项目自身的智能，"项目"是发起者，不过也或许可以做依赖注入，“项目”也就不是发起者了，而是注入到了哪个结构体，哪个结构体是发起者（redis在主函数中被持久化了）

envlove的发起者是物理节点所在的结构体，从思路逻辑上，他本该是发起者，同时代码设计了依赖注入，物理节点结构体包含了envlove工具结构体的指针（envlove包也在主函数中被持久化了）

而报警到底在地位上是否应该和envlove一致呢？他是否需要先持久化呢？

首先，其实"项目"自身也可以去envlove一个物理点值，如果是这种思路，在实际操作上同样会是依赖注入的设计方式，所以谁发起的envlove就变得并不重要了 对于报警目前也涉及了类似的问题，不过啊思前想去，发起者无非也是在"项目"和"物理节点实体"上二选一，所以我不准备想的太明白了，反正最后都要进行依赖注入

最终总结:

已确认报警和envlove地位一致

报警不应该设计成独立的容器，而应该属于数据采集的一部分

报警应该在录入redis前执行

报警不该在envlove进行"envlove操作"与"从新赋值”的间隙进行，而是应该在之后进行，因为envlove的分析的数据源是环境变量，报警的envlove后的各个点值，同时告警的发起者只应该是物理节点或者"项目"，而不该是envlove包，毕竟envlove只是个"动作"，而不是"实体"

补充，到后期(目前还没有实现)其实录入redis也可以理解成是物理节点所发出的，因为和envlove一样，一旦进行了依赖注入，就没必要考虑到底是谁"发出"的了，redis的依赖注入和envlove的依赖注入也几乎一样，所以，这三者可以说都是同等地位的