composer怎么配置项目名称_composer修改项目名称方法

改名未生效需清理缓存并验证：先删 vendor/ 和 composer.lock 后重装，再运行 composer show 验证识别；同步更新 autoload 的 psr-4 前缀，确保与新 name 一致，并检查 ci/cd 中变量提取逻辑是否正确解析 composer.json 的 name 字段。

composer.json 里的 name 字段改了但没生效？先看是否被缓存或依赖锁定

Composer 不会自动重命名已安装的包，name 字段只在 packagist 发布、依赖解析、autoload 生成时起作用。本地改完 composer.json 后，如果项目已被其他包引用（比如作为开发依赖），或 vendor/composer/installed.json 里还存着旧记录，就会“看起来没变”。

• 运行 composer dump-autoload 强制刷新 autoload 映射（尤其影响 PSR-4 命名空间）
• 删掉 vendor/ 和 composer.lock，再 composer install —— 这是验证 name 是否真正被识别的最干净方式
• 检查是否有第三方脚本（如 CI 配置、Dockerfile）硬编码了旧项目名，比如 composer config --global github-protocols https 这类命令不碰 name，但有些部署脚本会读取 name 构造镜像标签

修改 name 后 vendor/autoload.php 加载失败？注意命名空间和 PSR-4 的联动

name 字段本身不直接控制自动加载，但它常被用作 PSR-4 的默认根命名空间前缀（尤其在 create-project 生成的模板里）。如果你把 "name": "myorg/old-name" 改成 "myorg/new-name"，但 autoload 段没同步更新，类文件就找不到。

• 确认 composer.json 中 autoload 的 psr-4 键值对是否匹配新 name：例如 "MyOrgNewName": "src/"
• 如果用的是 classmap 或 files，它们不依赖 name，但别忘了手动检查路径是否存在、是否拼错
• 运行 composer show myorg/new-name 看是否能识别到本地包 —— 如果报 Package not found，说明 Composer 还没把它当“可安装包”，可能因为没设 minimum-stability 或缺少 version

想让 packagist 上显示新名字？name 必须全局唯一，且需手动同步

packagist.org 的包名就是 name 字段值，一旦发布过 myorg/old-name，就不能再提交同名新包。改名不是覆盖，而是新建一个包。

• 在 packagist 上不能“编辑”已有包名，只能删掉旧包（需有权限），再用新 name 提交一次
• 旧包的下载量、stars 不会迁移到新包，下游用户不会自动切换 —— 如果是公开库，得发公告、加重定向提示，甚至保留旧包只打 deprecated 标签
• CI 中若用 composer publish 类脚本，请确认它读取的是当前 composer.json 的 name，而不是从 git tag 或环境变量里硬取的

CI/CD 流水线里 name 被当成构建上下文？警惕 shell 变量和 JSON 解析差异

很多自动化流程会用 jq -r '.name' composer.json 或 composer config name 提取项目名用于构建标签、S3 路径等。这些命令行为不一致：

• composer config name 输出格式带空格和冒号（如 name : myorg/new-name），直接管道进 sed 容易出错；推荐用 composer config --json name | jq -r '.name'
• jq 解析时如果 composer.json 末尾缺逗号、缩进错乱，会静默失败 —— 建议 CI 中加一步 composer validate 校验合法性
• windows 上 composer config 输出换行符不同，跨平台流水线建议统一用 jq 或 PHP 脚本解析，避免 shell 截取翻车

name 字段看着简单，但它牵扯 autoload、packagist、CI 变量提取、甚至团队协作时的语义一致性。最容易被忽略的是：改完之后不验证 composer show 是否识别，也不清理 lock 文件 —— 结果本地跑得通，上线就报 class not found。