Temp不能跨扫描周期，也就是不能实现数据的连续轮转。

所以temp在一个扫描周期中的使用先后次序就很重要。这是一种耦合，由底层机制带来的用法上的耦合和限制。

随着一个FB或FC内部的结构越来越复杂，其内部会分成多个子模块。

如果一个Temp的使用范围超出一个子模块，在多个子模块中存在，那么这些子模块的组织顺序，就在某种意义上被锁定了，不能前后随意拖拽窜动。Static就没有这个问题。

例如：我先前开源的Modbus案例源码，其内部由17个子模块构成。这些子模块的位置组织和摆放，可以随意前后挪动，都不会有问题，唯独有一个子模块例外。

时间久了就不记得先前的程序细节。一查看才发现，其中用了Temp变量，就出现了上述的问题。

开销、便利与代价，相互之间是平衡的，就看自己想要什么。事物在时间中会变得复杂，贯彻一个原则并不容易。

为什么前后可以自由窜动很重要呢？是因为想要一个解耦的架构。

这样子模块可以随意修改扩展，而不会影响其它的。这样的子模块可以被称为一个层，也就是一个功能子集，其中的元素可以自由增删。

非常复杂的FB内部调度机制和结构设计，最后就会走到这一步。

那为什么不用很多独立封装的FB或FC嵌套组合而成一个大FB呢？因为我喜欢扁平化设计。

一个解耦的层，与一个独立的FB或FC在逻辑本质上是等价的，但开销更低，可以明显降低架构的复杂度，提高清晰度。这方面的实践效果对比都验证了这一点。

另外，用FB或FC组合出更大FB的想法，乍看是有道理。但当问题变得极度复杂和需求动态化后，这些组件FB或FC的处理会变得更复杂，接口需要不断调整和缠绕。

这时候你有可能会意识到一件事：先前你认为一个独立的局部，可以独立封装成一个FB和FC的。但在更复杂的局面下，这些独立FB和FC之间其实是更应该耦合的。而你先前的做法，只是因为当时的局面简单，就认为它们永远会彼此无关，就把这些局部元素解耦分开了，而其实这些元素在更复杂的局面下，本应就是内聚在一起的。