Composer包名必须全小写且用短横线分隔，含大写字母或下划线会直接触发校验失败报错；name字段错误将导致install失败、Class not found或Packagist无法索引，须同步修正autoload路径并清除缓存验证。
Composer 包名必须小写，不是风格偏好，而是底层解析、自动加载和跨平台部署共同强制的结果——写错大小写，composer install 会直接失败，或在 Linux 环境下类根本加载不了。
为什么 Composer 拒绝 MyVendor/MyPackage 这类写法
Composer 在读取 composer.json 的 name 字段时，会立即执行正则校验：/^[a-z0-9]([a-z0-9.-]*[a-z0-9])?(/[a-z0-9]([a-z0-9.-]*[a-z0-9])?)*$/。只要含大写字母（如 MyVendor）或下划线（如 my_package），就会报错：
Invalid package name "MyVendor/MyPackage": Package names should be lowercase and use dashes for word separation
这个校验发生在 composer validate、composer install、甚至 Packagist 提交页面加载时——你连表单都提交不出去。
它不“自动转小写”再处理，而是直接中断。所谓“MyVendor/MyPackage 最终也指向 myvendor/mypackage”只是部分旧文档的误导性描述，实际中 vendor 名大小写不一致会导致 Packagist 账号映射失败、依赖解析歧义、Git 大小写冲突等连锁问题。
name 字段写错后最常触发的三类故障
很多人改完 name 就以为万事大吉，但真正出问题的地方往往藏在后续环节：
- 本地
composer require myvendor/my_package报Could not find package：因为命令里写的包名和composer.json里不一致，而 Composer 不做模糊匹配 - require 成功但运行时报
Class not found：autoload.psr-4映射的命名空间前缀（如MyVendorMyPackage）和实际文件路径（如src/MyPackage/）大小写不一致，Linux 下src/mypackage/和src/MyPackage/是两个目录 - Packagist 页面显示
No releases found：tag 推送了，但name字段的 vendor 部分和 Packagist 账号不一致（比如账号是myname，却写了myname2/my-package），Packagist 根本不会抓取该仓库
怎么验证你的包名和 autoload 是否真合规
别只信 composer install 成功——那可能只是缓存没清干净。真实验证要分三步走：
运行 composer validate，确保输出 ./composer.json is valid；
删掉 vendor/ 和 composer.lock，再跑 composer install --no-cache；
检查 vendor/composer/autoload_psr4.php 里生成的数组键是否和磁盘路径完全一致（包括大小写），例如：
['MyVendor\MyPackage\' => [__DIR__ . '/../src/MyPackage/']]
如果磁盘上实际是 src/mypackage/，那这个映射就失效。
最后用 docker run --rm -v $(pwd):/app -w /app php:8.2-cli php -r "var_dump(class_exists('MyVendor\MyPackage\Helper'));" 在 Linux 容器里实测一次，能过才算真正过关。
最容易被忽略的是：改完 name 后没同步更新 autoload.psr-4 的命名空间前缀，也没清缓存——这时候错误日志里根本不会提“包名不合法”，只会报 Class not found，让人绕半天弯路。
