执行 composer require 前须确保在含 composer.json 的项目根目录，否则会报错或误创建新项目；--dev 参数决定是否为开发依赖；版本号应明确约束如 ^2.9 避免不兼容升级。

composer require 装不上包？先看是不是没在项目根目录

执行 composer require 前，当前工作目录必须是含 composer.json 的项目根目录。否则会报错 Could not find a composer.json file in /xxx 或默默创建新项目——这不是你想要的。

• 用 ls -la | grep composer.json（macOS/Linux）或 dir composer.json（Windows）确认文件存在
• 如果在子目录（比如 src/ 或 app/），先 cd .. 回到上层，反复直到找到 composer.json
• 误在空目录运行 composer require xxx 会触发 composer init 流程，生成全新配置，覆盖原有依赖逻辑

加不加 --dev 参数，决定包进不进生产环境

composer require 默认把包写入 require 字段，上线时也会被加载；但测试工具、代码生成器这类只在开发期需要的，得显式加 --dev，否则可能引入非必要依赖、拖慢生产启动速度或暴露调试接口。

Discussion Composer

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

下载

• 日常开发装 PHPUnit：用 composer require --dev phpunit/phpunit
• 装 Laravel 框架核心组件（如 illuminate/database）：不用 --dev，它属于运行时依赖
• 检查已装包位置：打开 composer.json，看包名出现在 "require" 还是 "require-dev" 下

版本号写法不对，容易锁死或装错大版本

不写版本号（如 composer require monolog/monolog）默认装最新稳定版，但可能跳到不兼容的主版本（比如 v3 → v4）。更安全的做法是明确约束范围。

• 要兼容旧代码：用 composer require monolog/monolog:^2.9（允许 2.9.x 及以上，但不超过 3.0）
• 只想试用不升级：加 --no-update，只改 composer.json 不立即下载，后续手动 composer update 控制时机
• 错误写法 ~2.9 和 ^2.9 行为不同：~2.9 等价于 >=2.9.0 ，而 <code>^2.9 是 >=2.9.0 —— 这俩在此例中结果一样，但 <code>^1.2 和 ~1.2 就不一样了，别凭感觉猜

装完 vendor 里没文件？可能是 Composer 配置或权限卡住了

命令返回成功但 vendor/ 下没对应目录，常见于国内网络、PHP 配置限制或 Composer 全局设置干扰。

• 先跑 composer diagnose，它会提示 SSL、网络、allow_url_fopen 是否异常
• 国内用户常因源失效卡住：临时切镜像 composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该镜像已停，应换 https://mirrors.aliyun.com/composer/）
• 如果报 file_put_contents(./vendor/autoload.php): failed to open stream: Permission denied，说明当前用户对 vendor/ 目录无写权限，别用 sudo composer require，改用 chown -R $USER:$USER ./vendor 修权限

Composer 的真实复杂点不在命令本身，而在它背后连着 PHP 版本、扩展启用状态、网络策略、目录权限、甚至 packagist 的服务可用性——出问题时别只盯着 require 三个字看。