能改，而且必须改——只要项目未发布到Packagist或被依赖，name仅作本地标识，修改后立即生效；但若已被外部引用，改名即视为新包，旧依赖不会自动迁移。
composer.json 里 name 字段写错还能改吗
能改，而且必须改——只要项目还没发布到 Packagist 或被其他项目 require，name 就只是本地标识，改完立刻生效。但要注意：一旦 name 被别人依赖过（比如你发过 tag、提交过公共仓库、或有人写过 "your-vendor/your-package": "^1.0"），再改就等于换了个新包，旧依赖不会自动跟着走。
常见错误现象：composer install 报错 Package your-vendor/old-name is not installed，其实是本地 vendor/ 缓存和 composer.json 不一致；或者 CI 构建失败，提示 Package name does not match the one in composer.json，说明 Git 标签名、分支名或打包脚本里硬编码了旧 name。
- 改之前先确认没被外部引用：搜 GitHub、Packagist、公司私有仓库，看有没有
require你的旧name - 改的时候连带检查
autoload的psr-4命名空间，比如"YourVendor\OldName\": "src/"得同步改成新命名空间 - 改完运行
composer update --lock，强制重生成composer.lock，避免残留旧 name 的 hash 记录
修改 name 和 description 的具体操作步骤
直接编辑 composer.json 文件，改两个字段就够了：name 和 description。不需要跑命令生成，也不用清缓存——Composer 读取的就是这个文件本身。
使用场景：初始化项目时填错了 vendor 名；团队统一命名规范调整；从个人项目转为组织项目需要改前缀。
-
name必须是vendor/package格式，中间一个斜杠，全小写，只含字母、数字、下划线、中划线；my-org/my_project✅，MyOrg/MyProject❌，myorg/myproject✅ -
description是纯字符串，不参与解析，但会影响 Packagist 页面展示和composer search结果，建议写清楚用途，比如"HTTP client wrapper with retry and circuit breaker" - 改完别忘了
git add composer.json && git commit -m "chore: rename package to my-org/new-name"，否则协作时别人拉下来还是旧 name
为什么改完 name 后 vendor 目录没变化
因为 composer install 只根据 composer.lock 安装，而 lock 文件里记录的是包的完整坐标（包括 name）。如果你只改了 composer.json 但没更新 lock，Composer 就当没这回事。
性能影响：执行 composer update --lock 会重新解析依赖图，比 install 慢一点，但不会重装所有包——只要依赖版本没变，vendor/ 里的代码文件其实不动，只是更新 lock 文件里的 name 字段和 hash。
- 如果项目没锁文件（没有
composer.lock），直接composer install就会按新name生成 lock - 如果想跳过依赖检查只更新 lock，用
composer update --lock --no-install - CI 环境务必用
composer install（不是 update），否则可能意外升级其他包
修改后测试是否生效的三个关键点
别只信 composer show 输出，那只是读 composer.json；要验证实际行为是否对齐新 name。
容易被忽略的地方：自动加载、PSR-4 命名空间映射、以及 Packagist 同步逻辑，三者不一致就会导致类找不到或发布失败。
- 运行
composer dump-autoload，然后php -r "var_dump(class_exists('YourVendor\NewName\SomeClass'));"，确认自动加载路径已指向新命名空间 - 执行
composer validate，它会检查name格式、必填字段、以及autoload和name是否冲突（比如 vendor 名不匹配） - 如果要推到 Packagist，确保 GitHub 仓库名和
name的vendor/package部分完全一致，否则 Webhook 会失败
