通常，我会说几乎在每种情况下，对于任何特定问题都只有一个 PHP 库。（我不算过时的、废弃的、垃圾的。）
因此，使用它从来不是我的“选择”。我必须要么使用它，要么什么都不用。
出于这个简单的原因，“不要使用没有被很多人和大公司推广或使用的晦涩库”的听起来很安全的建议很少适用，因为没有任何替代方案可供选择！
这适用于PHP——地球上最流行/最大/最常用的当前编程语言之一。想象一下，如果我使用的是一些不太流行的语言；我永远找不到图书馆做任何事情！
这个建议似乎只在理论上有效。实际上，除非您打算从头开始自己做所有事情，否则在库甚至语言之间几乎没有选择（如果有的话）。（或者如果你可以付钱，我不能，因此我什至从未考虑过任何潜在的现有付费替代方案。）
我问这个问题的原因是我总是把它作为如何保持安全而不是通过受损/邪恶的 PHP 库获取恶意软件的主要技巧之一。但是，当只有一件事可供选择时，例如“MailMimeParser”，这似乎总是如此（任何“替代品”都有主要的阻碍因素，例如死亡或只是没有像宣传的那样工作），还有什么可以我做？
你说你别无选择，但那不是真的。您可以自己编写所有需要的代码。或者，您可以花钱请一位值得信赖的专业人士为您编写代码。或者，您可以在使用代码之前向安全公司付款以对其进行审核。或者您可以接受风险，并实施其他安全控制措施来降低风险。例如，如果您担心某些代码可能容易受到 SQL 注入的攻击，您可以在其前面设置一个 WAF（Web 应用程序防火墙）。
安全是有代价的：时间、资源、专业知识、金钱。没有免费的午餐。如果你负担不起，你必须要么避免问题（重新考虑你的项目），要么委派它（其他人会处理它），要么减轻它（例如通过纵深防御），或者只是接受您可能会被黑客入侵的风险。
就您个人而言，当您必须处理未广泛使用的代码时，如果库不是太大，我会尝试阅读代码，至少要检查是否有任何“代码气味”。即使您不检查所有逻辑，也很容易检查是否有足够的注释，是否有意义，代码是否干净易懂，某些功能是否根据最佳实践使用，是否有检查输入数据等。代码仅由少数人使用并仅由少数开发人员维护的风险还在于它可能会停止维护，或者维护变得太慢，所以最终你可能会无论如何都要被迫阅读和理解代码，以修复您的应用程序。如果可能的话，我还会尝试实现一些深度防御，
我将首先解决您问题的一般部分，然后是特定的 PHP 部分。
不要相信没人使用的晦涩的 PHP 库！
这只是通常的收益/风险问题。如果风险很低，您可以做任何事情并使用晦涩（甚至损坏）的库。这意味着平台和最终应用程序的结果都不是关键任务。如果它暂时失败，您只需要生成修复程序或找到解决方法。
如果要将库包含在增值应用程序中，则需要评估库的行为与预期不完全一致的风险。最常见的方式是（如在 Stack Exchange 中）名誉。如果已知该库已经过广泛测试，并且仍在维护，那么陷入未经测试的极端情况的风险很低，您可以希望，如果您发现问题，它将得到修复。如果它只是偶尔维护并且用户很少，那么您（或您的用户）可能会在以后陷入这种极端情况，并且没有比记录您的应用程序无法做到这一点更好的方法。
如果声誉没有很好建立，您可以尝试在代码中挖掘一点。如果它看起来结构良好、记录良好并包含测试，那么您至少可以相信已遵守最佳实践规则。作为一个侧面，测试将显示库关注的用例。
如果这个库真的看起来很不起眼，而你想使用它，你不仅要测试你自己的代码，还要测试这个库在你希望你的应用程序接受的所有用例中的行为是否符合你的预期。因为你不能盲目相信它。但如果你认真地去做，那将需要时间。
PHP 与较少使用的语言
PHP 可能是非专业程序员最常用的语言。这意味着，如果您需要某些东西，其他人已经生产了它。但是你不能确定质量。Java 在专业级产品之外的使用要少得多。但是许多库是由大型知名组织制作并经过大量测试的。当我从 Spring 项目中得到一些东西时，我相信它遵循了最佳实践规则并经过了广泛的测试。
这只是我的看法，但这也是我不愿意使用 PHP 代码的原因之一：周围有很多 PHP 代码，其中一些质量非常好，但是获得质量差的代码的风险很高。
该建议基本上是将“真实”世界中的信任原则映射到软件开发世界：
如果您在软件开发中不遵循这些简单的现实世界规则，您可能会像在现实生活中一样被烧毁：有人可能会滥用您拥有的（毫无根据的）信任，这可能会导致例如后门或严重错误在您的软件中。这反过来也可能损害您自己的声誉。
当然，仍然有可能某人拥有良好的声誉并且仍然滥用信任。并且有足够的例子来做到这一点。但与没有声誉的人相比，这种可能性要小得多，因为首先要建立良好的声誉需要付出很多努力。与此相比，良好的声誉如果被滥用，很容易很快就失去了，所以大多数人不会试图滥用他们的良好声誉。
我想你已经听从了建议！你说：
我不算过时的，废弃的，垃圾的。
那么，您使用什么衡量标准来确定某物是否“过时、废弃、垃圾”？在像 packagist.org 这样的网站上，实际上很少有包被标记为“废弃”，而“垃圾”显然是一种主观判断，所以我怀疑你的实际过程是这样的：
在此过程结束时您通常会得到一个选项，这一事实与在此过程开始时只有一个选项非常不同。
还值得注意的是，如果有一个用于解决特定工作的高质量库，那么人们通常没有动力去写一个新的。同样，这并没有否定使用受人尊敬的库的建议，而是加强了它——如果有很多人使用相同的实现，他们中的一些人更有可能发现缺陷，或者支付审计费用。这基本上是对“莱纳斯定律”的重申：
有足够的眼球，所有的虫子都很浅
我可以看到实际应用的问题的唯一情况是没有适合工作的库，因为这是一个非常罕见的用例，没有人编写过。在这种情况下，由您来编写库（或为编写它付费），并由您来确保它的安全（或花钱请人检查它是否安全）。