项目名称必须为「vendor/name」格式，如”myorg/my-awesome-package”，vendor通常为gitHub用户名或公司域名反写，name须全小写加连字符；description、type、license虽非强制但影响Packagist显示、工具识别与CI/CD流程。
项目名称写在 name 字段里，且必须是「vendor/name」格式
composer 不接受随意命名，name 是必填字段（除非是根项目且未发布），格式强制为两段式：用户名/包名，中间用斜杠分隔。比如 "name": "myorg/my-awesome-package" 合法，"name": "my-awesome-package" 或 "name": "myorgmy-awesome-package" 都会报错或被忽略。
常见错误现象：composer install 报 Invalid package name "xxx": name must be in the format vendor/name；或者 packagist.org 拒绝提交。
- vendor 名通常是你 github 用户名、组织名，或公司域名反写（如
acme-corp） - name 部分不能含大写字母、空格、下划线（推荐全小写 + 连字符）
- 本地开发时可暂用占位符如
"name": "local/test-project"，但上线前需改真实标识
description、type、license 这三个字段虽非强制，但影响实际使用
没有 description，Packagist 页面显示为空白；不设 type（如 "type": "library" 或 "type": "project"），某些工具（如 Composer 自动加载器、插件管理器）无法正确识别项目用途；license 缺失会导致 packagist 标为 “unknown”，部分企业 CI/CD 流程会直接拦截。
典型配置示例：
"license": "MIT", "description": "A lightweight config loader for php applications", "type": "library"-
type值为project表示这是最终应用（如 laravel 项目），不会被其他包 require；library才是可复用的包 - 多个许可证用数组：
"license": ["MIT", "apache-2.0"] -
description最好控制在 120 字以内，packagist 只显示前段
别把 name 和 autoload 的命名空间搞混
name 是包的全局唯一标识，用于 Composer 生态中的查找与依赖解析；而 autoload 下的 psr-4 或 classmap 定义的是 PHP 类文件如何映射到命名空间——两者无语法绑定关系，但人为保持一致能减少混乱。
例如，"name": "foo/bar" 并不要求你必须写 "autoload": {"psr-4": {"Foo\Bar\": "src/"}}，但如果你写了 {"psr-4": {"App\": "app/"}}，那这个 App 命名空间和 foo/bar 就完全无关。
- PSR-4 映射的前缀末尾必须带反斜杠：
"Foo\Bar\"✅，"Foo\Bar"❌ - 若项目是纯命令行工具，
type设为bin，并配合bin字段声明可执行脚本路径 - 修改
name后，已安装的依赖缓存可能残留旧信息，建议运行composer clear-cache
根项目（如 Laravel 应用）的 name 字段可以省略，但有隐藏代价
Composer 允许根项目（即不作为包被别人 require 的项目）不写 name，此时它被视为匿名项目。表面上一切正常，但一旦你尝试用 composer archive 打包，或接入某些私有仓库同步工具，就会因缺失标识失败。
更隐蔽的问题：某些 ide（如 phpstorm）依赖 name 推导自动补全路径；Laravel Octane 或 swoole 环境下，未设 name 可能导致热重载识别异常。
- 如果真不想暴露真实 vendor 名，可用伪命名如
"name": "private/app" -
composer create-project生成的模板默认带name，删掉它等于主动放弃生态兼容性 - CI 构建时若用
--no-interaction，且name缺失，某些自动化发布脚本会静默跳过版本标记步骤
项目名称不是贴个标签那么简单——它连着 Packagist 的索引逻辑、自动加载的路径推导、私有仓库的权限模型，还有各种工具链的隐式假设。一个看似无关紧要的 name 字段，往往在交接、部署或升级时才突然暴露出所有约束。