实际上，它还远未消亡。尽管开销很大，但许多虚拟主机公司现在出于安全考虑将PHP作为CGI运行，因为它可以与suEXEC一起使用。suEXEC意味着你的脚本在你实际的Unix用户权限下执行，因此受到操作系统权限分离的限制。这是一个比PHP特定的open_basedir替代方案 * 更 * 健壮的安全模型。
此外，CGI是一个 * 真的 * 简单和相当通用的接口，对它的支持永远不会从Web服务器出去。许多新的接口，如FastCGI和SCGI继承了CGI传递HTTP头和其他变量到Web应用程序和返回的方式。甚至PHP的SAPI也用它的$_SERVER变量模仿了这一点。所以CGI不会消失，它只是被构建。

遗产？绝对的。死亡？嗯，它是在生命支持系统上。我怀疑它是否真的会在可预见的未来“死亡”。如果你有一个服务器，没有其他方式运行一个web应用程序，你可能仍然使用CGI写一个 * 非常 * 小的脚本排序，你懒得配置它。
另一个原因是什么呢？也许你有一个程序像筛子一样泄漏内存或资源，但你无论如何都需要运行它，所以你通过结束每个请求来确保一切都被清理干净...
但是说真的，对于真正“重要”的事情，我认为迁移到任何一种具有持久进程的系统的好处都远远超过了成本。而且根据我的经验，它还鼓励编写组织得更好的代码，因为拥有一个良好的模块化应用程序所需的初始化类型在CGI环境中会转化为“不可接受的启动时间”。

它还没有完全死。但是fcgi看起来是更好的方法。虽然没有得到官方的支持，比如说Apache。你需要使用side mods来让它工作。

我也不认为CGI已经死了。毕竟，所有主要的网络服务器都支持它。
启动CGI项目的一个没有提到的原因可能是知识产权保护。例如，您可能决定用C++编写CGI程序，并允许您的客户在不受您控制的服务器上安装应用程序。
也许你的遗留产品有大量的业务实现为库。（. dll，.so.. lib.. a等）在这种情况下，在实现Web界面时，坚持使用c/c ++实际上可能会更快地推向市场。
也许，你在Delphi商店工作？如果你商店里10个工程师中有10个是写Delphi的，那么用PHP写你的新应用程序可能不是你进入市场的最快途径。
因此，简而言之，许多变量发挥作用时，决定什么技术使用您的新产品包括：

• 你的顾客是谁？
• 你的出发点是什么？
• 你的资产和资源是什么？
• 你喜欢什么？
• 您的软件需要与什么接口？
• 应用程序将如何部署？

CGI不是很适合高性能。
但我的建议是忽略这一点，为支持多个API的语言或库编写，然后使用最适合每种情况的语言或库。