composer插件必须实现plugininterface并注册自定义downloaderinterface和installerinterface才能控制下载与安装逻辑，且需注意package对象不可变、dist.url需提前重写、路径处理要一致。

Composer 插件必须实现 PluginInterface 才能被识别

Composer 不会自动加载任意类为插件，必须显式声明并满足接口契约。如果你写了一个类、加了 composer.json 的 extra.plugin-class，但没实现 Composer\Plugin\PluginInterface，它根本不会被实例化，更别说执行下载逻辑了。

实操建议：

• 你的插件主类必须 implements Composer\Plugin\PluginInterface，且实现 activate() 和 deactivate()
• 在 activate() 中注册自定义 installer 或 downloader —— 这才是控制“怎么下”的入口
• 别漏掉 composer-plugin-api 版本约束，例如 "composer-plugin-api": "^2.0"（对应 Composer 2.x）
• 插件包的 type 必须是 composer-plugin，否则 composer install 时会被跳过

替换默认下载器要用 DownloadManager + 自定义 DownloaderInterface

Composer 的下载行为由 Composer\Downloader\DownloadManager 统一调度，它根据包类型（如 zip、git、package）分发给对应 DownloaderInterface 实现。想改下载方式，就得提供自己的 downloader，并在插件中把它注册进去。

常见错误现象：Package operations: 1 install, 0 updates, 0 removals 正常显示，但实际没走你的下载逻辑 —— 很可能是你注册的 downloader 没匹配上包的 type 或 dist.type。

实操建议：

• 继承 Composer\Downloader\ZipDownloader（或其他基类）比从头实现 DownloaderInterface 更安全，避免漏掉重试、校验、清理等细节
• 用 $dm->setDownloader('zip', $yourDownloader) 替换，注意 'zip' 必须和 composer.json 里 dist.type 值一致
• 若包无 dist（比如 type: package 且只有 source），下载器不会被调用 —— 此时要干预的是 InstallerInterface 的安装阶段
• 调试时可在 downloader 的 download() 方法里加 file_put_contents('/tmp/composer-down.log', ...)，确认是否命中

PackageInterface::getDistUrl() 返回空或无效 URL 就会 fallback 到源码克隆

Composer 下载前会先调用 $package->getDistUrl() 获取归档地址。如果这个方法返回 null、空字符串或 404 URL，Composer 会放弃下载，转而尝试 source 方式（如 git clone），这往往不是你想要的结果 —— 尤其当你想强制走私有 CDN 或临时签名链接时。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

使用场景：你正在写一个插件，用于把 packagist.org 上的包透明代理到内网镜像，但发现部分包仍走 GitHub 克隆，就是因为 dist URL 没被正确重写。

实操建议：

• 不要只监听 PRE_FILE_DOWNLOAD 事件来改 URL —— 那个时机太晚，getDistUrl() 已被缓存调用过
• 应在插件 activate() 后，通过 RepositoryManager 获取所有仓库，遍历 PackageInterface 实例，用 setDistUrl()（如果可用）或包装 Package 类来覆盖行为
• 更稳妥的做法是实现自定义 RepositoryInterface，在 findPackage() 中返回已重写 dist.url 的包对象
• 注意 Package 是不可变对象（immutable），直接改属性无效；必须用 Composer\Package\CompletePackage 并确保所有字段完整

自定义存储路径需绕过 Installers 的硬编码逻辑

Composer 默认把包解压到 vendor/{vendor}/{name}，这个路径由 installer 决定，不是下载器管的。想把某个包装进 resources/libraries/ 或按哈希分目录，不能只改下载器，得替换或包装对应的 InstallerInterface。

性能影响：自定义 installer 若没复用 BaseInstaller 的 getInstallationPath() 缓存机制，可能在 composer update 时反复计算路径，拖慢整个流程。

实操建议：

• 针对特定 type（如 library、theme）注册专属 installer，别试图全局劫持 LibraryInstaller
• 在 getInstallationPath() 中返回绝对路径时，务必用 realpath() 或确保路径以 $this->composer->getConfig()->get('vendor-dir') 为基准，否则 autoload 会失效
• 若路径含变量（如版本号、时间戳），记得在 isInstalled() 和 update() 中保持逻辑一致，否则 Composer 会认为包“未安装”而重复下载
• 别忽略 uninstall() —— 自定义路径不清理，composer remove 会残留文件

最易被忽略的一点：Composer 的 Package 对象在内存中是共享的，你在 downloader 里改了它的 dist.url，installer 里拿到的还是原对象。路径、URL、校验值这些关键字段，必须在同一个生命周期内统一处理，否则行为割裂，问题极难复现。