composer require 时需显式指定版本约束以确保兼容性：精确版（如2.9.4）、语义化范围（如^2.9.0）、分支（如dev-main）等，避免依赖冲突与静默降级。
composer require 时版本号写法决定装什么
不加版本号，composer require monolog/monolog 就会拉最新稳定版——但这个“最新”很可能和你的 PHP 版本、框架约束冲突。真正可控的方式是显式写死约束。
-
monolog/monolog:2.9.4→ 精确安装 v2.9.4，适合复现环境或修复已知 bug -
monolog/monolog:^2.9.0→ 允许升到 2.9.x，但跳过 2.10.0（因语义化版本中 2.10 是不兼容变更） -
monolog/monolog:8.0.*→ 只匹配 8.0 开头的 patch 版本，比如 8.0.5，但不会装 8.1.0 -
monolog/monolog:dev-main→ 装开发分支，仅限本地调试，别上生产
写错格式（比如漏掉冒号、多加空格、用中文标点）会导致 Composer 静默降级到旧版，或直接报 Could not parse version constraint。
PHP 版本不匹配时的典型报错和解法
错误信息看起来像 Your requirements could not be resolved，背后往往是扩展包的 php 依赖和你当前 CLI 的 PHP 版本对不上。比如 topthink/think-captcha:^8.0 要求 PHP ≥ 8.1，而你运行的是 PHP 7.4，就会卡住。
- 先确认 CLI 版本：
php -v，不是浏览器里 phpinfo() 显示的那个 - 查包的 PHP 要求：去 Packagist 页面看该版本的
require.php字段，或执行composer show -a monolog/monolog 2.9.4 - 临时切 PHP 版本：用完整路径调
/usr/local/bin/php81 composer.phar require topthink/think-captcha:^8.0
别指望改 composer.json 里的 "php": ">=8.1" 就能绕过校验——Composer 会按实际运行的 PHP 解释器版本做硬检查。
装完类找不到？自动加载和服务提供者没配好
执行 composer require 成功不代表就能直接 use。ThinkPHP、Laravel 这类框架的扩展包往往依赖服务提供者注册或配置文件生成。
- 检查
config/app.php中'providers'是否已加入扩展的服务提供者，如think\captcha\CaptchaService::class - 确认
composer.json没写"dont-discover": ["*"]——这行会关掉所有包的自动注册 - 有些扩展（如
topthink/think-queue）需手动把vendor/topthink/think-queue/config/queue.php复制到项目config/目录下 - 改完配置后必须运行
composer dump-autoload，否则新增的命名空间不会进自动加载映射
类找不到不是 Composer 没装上，而是框架层没“认领”这个包——这点在 TP6/TP8 和 Laravel 中尤其容易忽略。
已有同名包时，require 不等于重装
composer require vendor/name 默认会尝试升级或降级现有包，而不是删了重来。如果你之前装过 v3.0，现在想退回到 v2.9.4，直接 require vendor/name:2.9.4 可能失败或行为异常。
- 稳妥做法：先
composer remove vendor/name，再composer require vendor/name:2.9.4 - 注意
remove会删composer.json里的条目并清 vendor，但不会动你手动加的配置或服务提供者注册 - 如果只是想验证某版本能否跑通，建议在干净目录下新建测试项目，避免污染主项目 lock 文件
composer.lock 是真实安装依据，哪怕 composer.json 改了版本号，不 update 或 require 就不会生效；反过来，require 后没提交 lock 文件，协作时别人 install 就还是旧版。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
