包所有权变更需同步修改composer.json的name字段、Packagist权限及autoload命名空间，否则依赖中断、类加载失败；旧包须设abandoned标记并用replace/provide引导下游切换。
不能直接“转移包所有权”，必须通过修改 composer.json + 更新 Packagist/GitHub 权限 + 同步元数据三步协同完成，否则依赖会断、自动加载失效、新维护者无法发布版本。
如何更新 composer.json 中的 vendor 和 name 字段
包所有权变更本质是 vendor 名称变更，composer.json 必须同步更新，否则 Packagist 仍认原 vendor，下游项目 require 时找不到包。
- 将
"name": "old-vendor/package-name"改为"name": "new-vendor/package-name"（vendor 部分必须与新 Packagist 账户或 GitHub 组织名一致） - 如果包已注册到 Packagist，还需在
composer.json中显式声明"type": "library"（避免因 type 缺失被忽略） - 若旧包含自定义 autoload 规则（如
"psr-4": {"OldVendor\": "src/"}），必须同步改命名空间和路径映射，否则类加载失败 - 不要只改
name而忽略autoload—— 这是迁移后Class not found的最常见原因
如何在 Packagist 上解绑旧账户并绑定新账户
Packagist 不支持“转让”操作，只能由原所有者主动取消关联，再由新所有者手动 submit 新 URL。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 原所有者登录 packagist.org → 进入该包页面 → 点击 “Unlink from GitHub/GitLab”（不是 Delete）
- 新所有者用自己账户登录 Packagist → 点击右上角 “Submit” → 输入新仓库地址（如
https://github.com/new-vendor/package-name） - 确保新仓库的
composer.json已更新且可公开访问，Packagist 会自动抓取最新元数据 - 若新仓库是私有 GitLab/GitHub，需在 Packagist 添加对应 OAuth token 或配置 webhook，否则无法自动更新
如何让下游项目无缝切换到新 vendor
下游项目不会自动感知 vendor 变更，必须人工干预或借助重定向机制，否则 composer update 会报 Package old-vendor/package-name not found。
- 最稳妥方式：在旧包的最后版本中，用
replace声明替代关系："replace": { "old-vendor/package-name": "self.version" }+"provide": { "new-vendor/package-name": "self.version" } - 若旧包已归档，可在 Packagist 页面手动添加
abandoned标记，并指向新包："abandoned": "new-vendor/package-name"（需原所有者操作） - 下游项目需手动修改
composer.json中的require条目，把"old-vendor/package-name": "^1.0"换成"new-vendor/package-name": "^1.0" - 别指望
composer update自动替换 —— Composer 不解析 abandoned 字段来重写 require
Git 仓库迁移后如何保持标签和历史兼容
所有权变更常伴随 Git 仓库迁移（如从 GitHub user → org），若仅改 remote 地址不处理 tag，下游 composer install --prefer-source 会失败。
- 迁移仓库后，用
git push --tags强制推送所有 tag 到新地址（git push --mirror已包含，但需确认） - 检查新仓库的 tags 是否完整：
git ls-remote --tags git@github.com:new-vendor/package-name.git - 若旧包使用了
dist方式安装（zip 包），需确保 Packagist 抓取的新 metadata 中dist.url指向新仓库的正确 zip 下载地址（通常自动更新） - 若下游项目 lock 文件里锁的是 commit hash（非 tag），而新仓库提交历史不同，
composer install会校验失败 —— 此时必须composer update new-vendor/package-name重生成 lock
真正容易被忽略的是 autoload 命名空间与 name 字段的耦合性：哪怕 Git 仓库、Packagist、require 全部更新完毕，只要 src/ 下的类仍用旧 vendor 命名空间，composer dump-autoload 就无法映射到新路径。所有权转移不是改几个字符串的事，而是整个符号体系的重建。
