Php 作曲家优化级别1

关于作曲家的：

注意：您不应该在开发中启用这些优化，因为它们在添加/删除类时都会导致各种问题。在开发环境中，性能的提高是不值得的

我可以肯定地看到开发环境中的2级优化（权威类映射）存在问题，但是如果我遵循PSR-4标准，我无法确定问题是什么（类映射生成）

• 如果我添加了一个没有在类映射中生成的类，它将返回到PSR-4规则来查找该类
• 如果我重构（移动）一个类到另一个名称空间，它也不会在类映射中找到它，并尝试使用PSR-4规则解析它

---

对于符合PSR-4的项目，在开发环境中生成的类映射有哪些潜在问题？

如果将类移动到不同的目录而不更改名称空间，则级别1优化可能会产生问题。由于可能有多种方法来解析单个命名空间，因此Composer将正确处理此类更改，但当您拥有过时的类映射时，这些更改可能会失败

例如：

"autoload": {
    "psr-4": {
        "app\\": "src",
        "app\\db\\": "src/drafts/db"
    }
},

Class

app\db\Entity

可以放在

src/drafts/db/Entity.php

或

src/db/Entity.php

中，作曲家将按此顺序搜索类文件。通常，如果将文件从

src/drafts/db

移动到

src/db

中，Composer最终将找到此类。但若你们有过时的类映射，Composer会盲目地包含不存在的文件，你们会得到一个致命的错误

除此之外，apcu autoloader选项还将缓存未命中。因此，如果您请求一个不存在的

app/db/NewEntity

类，然后添加该类，Composer将不会检测到该更改，因为它缓存了该类不存在的信息

这些通常是边缘情况，通常你永远不会注意到这样的细微差别。但这仍然是可能的，而且开发环境中不明显的性能提升不值得在调试Composer autoloader的缓存相关问题上损失几个小时