Composer包迁移时不能只改name字段，必须同步更新require、命名空间、autoload映射，并通过abandoned标记或replace机制引导下游项目切换，否则安装失败或类找不到。
Composer 包迁移时 name 字段改了但安装失败
包名（name）是 Composer 识别包的唯一标识，一旦在 composer.json 中修改，旧包就彻底“失联”了。下游项目执行 composer update 时不会自动切换到新包名，反而会报 Package ... not found 或直接卸载旧包、留下依赖缺口。
关键不是改名，而是让旧包“指向”新包：
- 在原包的
composer.json中添加"replace": {"new-vendor/new-package": "self.version"}（仅适用于完全替代场景） - 更稳妥的做法：在原包的
README.md顶部加显眼提示，并在 Packagist 上将原包标记为abandoned，同时填入新包名（如new-vendor/new-package），这样composer require时会收到警告 - 若原包已无维护权限，无法标记废弃，则必须靠文档+发布通知推动用户手动替换
require行
如何让旧项目平滑升级到新包（含自动 autoload 适配）
包迁移常伴随命名空间（namespace）变更，这会导致 Class not found 错误，哪怕 autoload 配置本身没错。
解决核心是兼容层 + 渐进式切换：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 新包的
composer.json中保留旧命名空间的autoload映射（例如"OldVendor\Package\": "src-old/"），并确保类文件仍可被加载 - 在新包中用
class_alias()声明旧类名到新类名的映射（放在src/compat.php并通过"files"自动引入） - 避免在新包中删除旧接口或方法——先
@deprecated注释，等至少一个大版本后再移除 - 下游项目升级时，建议分两步：
composer require new-vendor/new-package:^2.0→ 运行静态分析工具检查弃用警告 → 再批量替换use语句
composer.lock 在迁移中为什么不能直接删
删 lock 文件看似能“重来”，实则破坏确定性：它会让所有依赖重新解析，可能拉取不兼容的次版本（如从 monolog/monolog:2.8.0 升到 2.9.0），而该版本可能已弃用某个你正在用的特性。
正确做法是让 Composer 自己重建 lock：
- 先更新
composer.json（改require、加replace、调autoload） - 运行
composer update --lock（仅更新 lock，不重装包）或composer update new-vendor/new-package --with-all-dependencies（精准更新目标包及其传递依赖） - 若需强制重算整个依赖图，用
composer update --dry-run先预览变更，确认无意外降级或冲突再执行
私有包迁移到新 Git 地址后 composer install 报 404
Composer 默认缓存 VCS 仓库 URL，即使你在 composer.json 里改了 repositories，本地 vendor/ 下的包仍可能指向旧地址，导致 git clone 失败。
必须清理三处缓存：
-
composer clear-cache（清全局 dist 和 source 缓存） - 删项目根目录下的
vendor/目录（否则install可能跳过重拉） - 删
composer.json中旧repositories条目，并确认新地址支持正确的 VCS 类型（如"type": "git"而非"package"） - 若用 GitHub/GitLab Token 认证，检查
auth.json中的 token 是否对新域名有效（比如从github.com迁到gitlab.example.com，token 就不通用）
