composer require 是装扩展的唯一安全入口，而 composer update 是重算依赖图的破坏性操作，会连带升级所有满足约束的包，极易引发线上行为突变；require 失败主因是缺失 composer.json 或框架主包、php 版本不足、关键扩展未启用。
composer require 是装扩展的唯一安全入口，composer update 不是安装命令，而是重算依赖图的破坏性操作——它会连带升级所有满足约束的包，线上行为突变风险极高。
为什么 composer require 装不上扩展？
不是网络或权限问题，大概率卡在这三处：
- 当前目录没有
composer.json，或它不包含框架主包（如"laravel/framework"、"yiisoft/yii2"）——Composer 不知道你在管哪个项目 -
php -v返回的 PHP 版本低于扩展要求（比如laravel/sanctum要求 PHP ≥8.0，而你本地是 7.4） - 关键扩展缺失：
php -m | grep -E "openssl|json|mbstring|phar"缺任意一个，composer require会静默失败，报错里常含Could not parse version constraint
composer.json 里 require 和 require-dev 到底怎么分？
不是“开发用的放 dev”，而是看它是否参与运行时逻辑：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
monolog/monolog、guzzlehttp/guzzle必须进require——线上日志、HTTP 请求挂了就不可用 -
phpunit/phpunit、phpstan/phpstan必须进require-dev——生产环境不装它们，还能减小体积、缩短扫描时间 -
autoload-dev只影响require-dev包的自动加载路径，别指望它让 dev 包的类在生产可用
装完类还是 Class not found？检查 autoload 是否生效
Composer 下载成功 ≠ 类能直接 new。常见断点：
- 命名空间和
psr-4映射不一致：比如"MyPlugin\": "src/"，但src/Plugin.php里写的是namespace MyLib; - 没执行
composer dump-autoload—— 尤其当你手动改过autoload配置后，必须刷新映射 - 框架启动时没加载
vendor/autoload.php：Laravel 入口是public/index.php，Yii2 是web/index.php，确认它们第一行就是require __DIR__.'/../vendor/autoload.php';
插件类写了但根本没被调用？先看 composer.json 类型声明
你的插件代码再规范，只要 composer.json 没写 "type": "composer-plugin"，Composer 就当它是个普通库，完全不扫描、不加载、不报错。
- 主类必须实现
ComposerPluginPluginInterface，且含activate()和deactivate()方法（哪怕空着） - 依赖项里必须有
"composer-plugin-api": "^2.0"（对应 Composer 2.x），版本错会导致接口方法找不到 - 监听事件名大小写敏感：
PostInstallEvent≠post-install-cmd；后者是脚本事件，插件无法监听
composer.json 的 type 字段、autoload 映射、以及 require/require-dev 的语义边界——这些地方一错，后续所有调试都是徒劳。
