Composer如何处理包名规范_Composer命名约定说明【入门】-composer-PHP中文网

composer 的 name 字段必须为 vendor/package 格式，vendor 须与 packagist 用户名一致且全小写，package 用短横线分隔；它决定包标识、自动加载命名空间（如 acme/api-client → acme\apiclient），错误会导致安装失败、类无法加载。

composer如何处理包名规范_composer命名约定说明【入门】

Composer 的 name 字段不是“起个名字而已”，它直接决定包能不能被装、类能不能被加载、别人能不能正确 require 你。 写错就卡在第一步，后续所有操作都白搭。

为什么 `name` 必须是 `vendor/package` 格式

Composer 完全不看你的目录名、Git 仓库名或本地文件夹名，只读 composer.json 里的 name 字段。这个字段是整个 PHP 生态中该包的全局唯一标识符。

vendor 部分必须和你在 Packagist 注册的用户名/组织名完全一致（比如 GitHub 用户名 myname），不能是邮箱、项目代号或系统用户名
package 部分必须全小写，单词之间用短横线（-）分隔，比如 json-helper，不能是 JsonHelper 或 json_helper
整个字段只允许小写字母、数字、-、_、. 和单个 /；禁止大写字母、空格、@、:、=、|
如果填成单段（如 "myapp"），Composer 会自动补为 root/myapp，但 root 不是合法 vendor，别人 require 时根本解析不到

`name` 怎么影响 PSR-4 自动加载

如果你没显式配置 autoload.psr-4，Composer 会按 name 自动生成默认命名空间：把 vendor/package 转为首字母大写的驼峰形式，比如 acme/api-client → Acme\ApiClient。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

这个转换是机械的，api-client 变成 ApiClient，cache-driver-redis 变成 CacheDriverRedis
但你的实际代码里如果写了 namespace App\ 或 MyApp\，而 name 是 acme/app，那自动加载器永远找不到类
更隐蔽的坑：name 含数字（如 my-app-v2）→ 转成 MyAppV2，但你文件里写的是 MyAppv2，Linux 下直接 Class not found
修改 name 后，必须同步更新 autoload.psr-4 配置和所有 namespace 声明，否则 CI 构建失败

本地开发最容易踩的三个坑

发布前没暴露问题，上线后用户一 require 就报错，基本都出在这三处。

composer init --name 没填，让它从当前目录名推断——比如目录叫 LaravelApiClient，它可能生成 root/laravelapiclient，root 是非法 vendor
用 path 仓库本地测试时，name 和实际路径不匹配：比如 name 是 myname/json-helper，但 path 指向 ../json-helper，Composer 直接拒绝安装
autoload.psr-4 的命名空间前缀末尾少了一个反斜杠，比如写成 "MyName\MyHelper" 而不是 "MyName\MyHelper\"，结果整个映射失效

验证 `name` 是否合规的最快方式

别等提交到 Packagist 才发现被拒，本地就能跑通关键检查。

运行 composer validate：它会报出 name 格式错误、非法字符、保留字（如 php、ext）等问题
用 composer dump-autoload -d ./test-project 在独立测试项目里验证自动加载是否生效
执行 var_dump(class_exists('MyName\MyHelper\SomeClass'))，而不是只看 require 成功与否
打 tag 前确认 git tag v1.0.0 和 git push origin v1.0.0 都执行了——Packagist 只认 tag，不认分支

最常被忽略的一点：大小写敏感不是开发环境的问题，而是规范本身的要求。macOS 和 Windows 上能跑通的 name，在 Linux 服务器上大概率失败。别依赖“本地能用就行”，从 composer init --name 开始就严格按 vendor/package 小写短横线来写。