composer插件需同时满足type为"composer-plugin"、extra中声明入口类、require包含"composer-plugin-api"三条件才被激活；核心能力通过监听事件实现，常见坑包括缓存未清、autoload配置错误及插件未置于根项目。
Composer 插件不是“装完就能用的功能包”，而是运行在 Composer 自身进程内、能改写其行为的轻量级扩展模块——它不提供业务逻辑，只干预安装、更新、加载等生命周期。
插件怎么被 Composer 识别和激活
Composer 在 vendor/ 中扫描所有已安装包，仅当满足三个硬性条件时才视为有效插件：
-
"type"字段必须严格等于"composer-plugin"（不是"library"或"metapackage"） -
"extra"中必须声明入口类："class": "Vendor\Plugin\Class" -
"require"中必须包含"composer-plugin-api": "^2.0"（对应 Composer 2.x；v1.x 已废弃）
缺一不可。哪怕只是多一个空格、大小写错一位（如 "Composer-Plugin"），插件都不会被加载，且无任何报错提示——它就静默失效。
插件的核心能力靠事件监听实现
插件类必须实现 PluginInterface，并在 activate() 方法中通过 $composer->getEventDispatcher()->addListener() 订阅事件。常见事件包括：
-
pre-install-cmd：命令执行前，适合做约束检查或环境预检 -
post-package-install：单个包安装完成后，可用于生成配置、发布资源 -
post-autoload-dump：自动加载文件生成后，适合注入运行时钩子 -
pre-package-install：可调用$event->disablePackageInstallation()中断特定包安装
注意：post-update-cmd 和 post-update-dump 容易混淆——前者是命令执行完触发，后者是 autoloader 重写完才触发，时机差很多。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么插件写了却没反应
最常踩的坑不是代码写错，而是环境与缓存干扰：
- 修改插件逻辑后未清缓存：
composer clear-cache必须执行，否则旧版本类仍被加载 - 插件类未正确 autoload：
"autoload": {"psr-4": {"My\Plugin\": "src/"}}路径末尾漏了/，或命名空间与目录结构不严格匹配 - 误把插件放在被依赖包里：插件必须出现在**根项目**的
require或require-dev中，否则不会激活 -
getInstallPath()返回了绝对路径或含..的路径：Composer 会直接跳过，不报错也不安装
调试时优先用 $io->writeError() 输出日志——$io->write() 在非 verbose 模式下可能被吞掉。
安装器插件（Installer Plugin）的特殊规则
这类插件专用于接管某类 "type" 包的安装路径（如 "type": "theme"），但匹配极其严格：
-
supports($packageType)必须返回true仅当$packageType === 'theme'（字符串全等，不支持前缀或模糊） -
getInstallPath()返回值必须是相对路径，如'public/themes/acme/my-theme'，不能以/开头 - 目标包自身
composer.json中也必须明确声明"type": "theme"，否则不触发该插件 - 改完插件后，必须删掉
vendor/和composer.lock，再重新composer install——缓存会固化旧路径
真正难的从来不是写逻辑，而是让 Composer “看见”你写的逻辑——它对声明规范的容错率极低，错一个字符，整个插件就消失在流程里。
