修复Composer要求包名全小写_命名规范避坑说明【新手提示】

Composer 拒绝 myvendor/my_package 因其包名必须全小写且用短横线分隔，下划线和大写字母均非法；需同步修改 composer.json 的 name、PSR-4 命名空间映射路径，并执行 dump-autoload。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

如果你在项目里尝试引入一个包，结果 Composer 直接报错，那很可能就是包名格式惹的祸。它有一套严格的命名规则：只接受全小写、用短横线分隔的格式，比如 vendor/package-name。像 vendor/package_name 这种带下划线的写法，或者混入大写字母，都会被直接拒之门外。

为什么 Composer 拒绝 myvendor/my_package？

这背后其实有双重考量。一方面，Composer 的包标识符（package name）设计，需要兼顾 URL 安全性和标准化处理。虽然下划线在 PHP 的命名空间里是合法的，但在包名这个层面却被明确禁止。另一方面，Composer 内部会强制将供应商名（vendor）标准化为小写，一旦包名里出现大写字母，就会导致校验失败。

• 所以，composer.json 里的 "name" 字段，必须严格遵守 vendor/name 格式，并且全部使用小写字母。
• 任何下划线都会触发明确的错误提示：Invalid package name "myvendor/my_package": Package names should be lowercase and use dashes for word separation。
• 值得注意的是，即便你在本地开发时通过别名绕过了检查，一旦想把包发布到 Packagist 这样的公共仓库，也会因为命名不合规而被拒绝。

正确改名的三步实操（含 autoload 同步）

修正这个问题，可不是简单地改一下 composer.json 里的名字就万事大吉了。关键是要确保包名、命名空间和实际的文件目录结构三者保持一致，否则自动加载机制就会失灵。具体来说，你需要按顺序完成这三步：

• 首先，把 composer.json 中的 "name" 改为全小写并用短横线连接。例如，从 "myvendor/my_package" 改为 "myvendor/my-package"。
• 接着，同步更新 "autoload" 部分下的 "psr-4" 映射。这里有个容易混淆的点：PHP 的命名空间本身（比如 MyVendor\MyPackage\）是允许使用大小写和下划线的，但目录路径必须符合 PSR-4 规范。这意味着，如果你的命名空间是 MyVendor\MyPackage\，对应的目录应该是 src/MyPackage/，而不是 src/My_Package/。
• 最后，执行 composer dump-autoload 来重新生成自动加载文件，并建议运行一次 composer install 来确保没有缓存干扰。如果这个包之前已经发布过，别忘了还需要在 Packagist 上弃用旧包名并提交新的。

常见踩坑场景：GitHub 仓库名 vs Composer 包名

很多人会在这里栽跟头：误以为 GitHub 的仓库名是什么，Composer 的包名就应该是什么。其实，这两者完全是解耦的。GitHub 的命名相对自由，但 Composer 的包名必须遵守它自己那套严格的规范。

• 简单说，你的 GitHub 仓库叫 myvendor/my_package 一点问题都没有，但 composer.json 里的 "name" 必须写成 myvendor/my-package。
• 如果你用 composer require myvendor/my_package 去安装，而实际的合法包名是 myvendor/my-package，那么结果就是找不到包：Could not find package myvendor/my_package。
• 这个规则对于私有仓库（比如用 Satis 搭建的）同样适用，无法绕过。

话说回来，最让人头疼的还不是上述这些明显错误。而是当你修改了 composer.json 后，忘了清理 Composer 缓存，或者没有同步更新 autoload 的映射路径。这时，错误信息往往会变成令人困惑的 Class not found，很容易让人误判是代码逻辑出了问题，而忽略了根源其实是命名规范。