在阅读本文之前，可以先查阅本人以下其它文章：
C++ 20标准协同程序（协程）基于编译器展开的 stackless 协程。_协同编译具体-CSDN博客
C/C++ 如何正确的切换协同程序？（基于协程的并行架构）_c++怎么切换运行程序-CSDN博客
关于 Go 协同程序（Coroutines 协程）、Go 汇编及一些注意事项。_go coroutine-CSDN博客
stackless or stackfull 协同程式（协程）？_boost stackless-CSDN博客
灌水玩玩 ChatGPT AIGC生成的有栈协同程序实现（例子）_任务协同 aigc-CSDN博客
C/C++ 11/14/17 有栈式协同程式的基础框架类库【关于】_c++11 协程-CSDN博客
关于 C/C++ 1Z（17）开源项目 openppp2 协同程式切换工作流-CSDN博客
C/C++ 协同程式切换潜在存在的一些致命性风险问题_go[=] 协程卡死 c++-CSDN博客
基于 C/C++ stackful 有栈协同程式，存在以下缺点，在采纳该架构的协程时，人们应当谨慎评估其风险性。
基于有栈协同程序：
1、需要为每一个协同程序分配独立的栈空间。
2、每个协程，需要确保其调用堆栈（计算堆栈）分配，不会超过分配的栈空间大小。
3、为了可读性，几乎不存在有人单独 “外挂协程计算堆栈空间”，略微类似于 golang。
4、需要单独步入测试，函数调用链所需要的最大栈空间大小，并给予一定额度。
5、不可采用递归类实现，只可以采纳非递归（略复杂）方式，解决类似如树、归纳等。
6、编程时需要注意函数、结构嵌套及圈复杂度，C几乎不会遇见，在 C++ 中会变复杂。
7、基于编译器优化时，或会带来一定的不确定性，它与第六条是联合并存的一个问题。
处理不好，会带来类似：总线错误、段错误的致命性疑难杂症问题。
8、不可产生遗漏及错误的 #PC/EIP 的流程切换问题，否则易产生死线（deadline）问题。
9、代码临界区处理的安全性问题，否则容易产生死锁（deadlock）的问题。
10、合理管控协同程序的膨胀数量，否则宿主机（母机）内存不一定能够承受过多的负载。
stackful 有栈协同程序，在 C/C++ 之中最大的优点是兼容性，在所有的操作系统平台都可以实现它，并且不限制 C/C++ 的编译器版本。
例如：C/C++ 11、14、17、20、22 等，这是好事儿，兼容性很强，但缺点也很明显，使用的复杂度及安全风险性问题会高很多，所以协程架构需要一个 C/C++ 很有经验的人作为，IA基础设施架构师来负责承建工程并且为它提供运行时可靠性保证。
一个好的建议是参考并学习研究本人的网络基础设施开源工具：openppp2liulilittle/openppp2: PPP PRIVATE NETWORK™ 2 VPN Next Generation Reliable and Secure Virtual Ethernet Access Solution!
这是一个由 C/C++ 17 编译器标准构建的 C/C++ stackful 应用程序，它拥有高效的协同程式切换效能，或许会是一个很好的：多核编程有栈协同程序实战性质 Refer 解决方案项目。
当多个线程及协同程序工作时，并承担高负荷的计算及交换压力时，内存负载表现，当然受限于不同的应用场景，内存负载略有不同，但大多数应用程式并不需要多大的内存负载，如果内存占用过多，人们可以仔细思虑是否整体架构及实现存在问题。
服务器：(AMD EPYC 7402P/1C）
客户端：（INTEL ATOM X5-Z8300/4C）
