^1.2.3 等价于 >=1.2.3 =1.2.0
指定版本时，别只写 ^1.2 就完事
Composer 的版本约束看似简单，但实际行为差异很大。比如 ^1.2.3 等价于 >=1.2.3 ，而 <code>~1.2 是 >=1.2.0 ——两者语义完全不同。生产环境建议优先用 <code>~ 锁定次版本，避免意外升级引入不兼容变更。
常见误操作是直接写 1.2，这会被 Composer 解析为 ^1.2.0（即允许升到 1.x 最新版），不是你想要的“固定小版本”。真要锁定，得写成 1.2.3 或加 --no-update 后手动改 composer.lock。
-
composer require monolog/monolog:~2.9→ 允许更新到2.9.x，但不跨2.x -
composer require guzzlehttp/guzzle:^7.5.0→ 允许7.5.0到7.999.999，但不会升到8.0 - 若依赖要求 PHP 8.1+，而当前环境是 8.0，
require会失败并提示Your requirements could not be resolved，不是版本号写错了，是环境不匹配
用 as 别名加载包，绕过命名冲突
当两个包提供同名类（比如都定义了 HttpClient），或你想在项目中统一接口名，可以用 as 语法重命名包的 autoload 命名空间。这不是 Composer 原生支持的“别名”，而是通过修改 autoload-dev 或自定义 PSR-4 映射实现的变通方案。
真正能用 as 的地方只有 repositories 配置里的 package 类型——它允许你伪造一个包，把真实源映射为另一个名字：
{
"repositories": [
{
"type": "package",
"package": {
"name": "myorg/http-client",
"version": "1.0.0",
"autoload": { "psr-4": { "MyOrg\HttpClient\": "vendor/guzzlehttp/guzzle/src/" } },
"source": {
"url": "https://github.com/guzzle/guzzle.git",
"type": "git",
"reference": "7.5"
}
}
}
],
"require": {
"myorg/http-client": "1.0.0"
}
}
这样你在代码里 use MyOrgHttpClientClient; 就不会和别的 HttpClient 冲突。注意：这种写法跳过了 Packagist 校验，需自行保证源码兼容性。
require 命令的 --dev、--global 和 --no-scripts 区别
这三个开关控制依赖安装范围和生命周期行为，选错会导致 CI 失败或本地调试异常。
-
--dev：把包写入require-dev，仅在开发环境启用。运行composer install --no-dev时它不会被安装。适合phpunit、phpstan这类工具 -
--global：安装到全局 Composer 目录（通常是~/.composer/vendor/bin/），命令行可直接调用，如composer global require laravel/installer。但它对当前项目autoload不生效，不能use里面的类 -
--no-scripts：跳过post-autoload-dump、post-install-cmd等脚本。CI 环境常用，避免执行数据库迁移或生成缓存这类副作用操作；但如果你的包依赖post-install-cmd来生成配置文件，关掉就可能报Class not found
混合使用也常见：composer require --dev --no-scripts phpunit/phpunit，既限定范围又防止触发钩子。
环境相关依赖：用 config.platform 模拟目标环境
本地开发机是 PHP 8.2，但线上跑的是 8.0？直接 require 一个只支持 8.1+ 的包，composer install 在线上会失败。这时不能靠人工记版本，要用 config.platform 提前暴露问题。
在 composer.json 里加：
{
"config": {
"platform": {
"php": "8.0.28",
"ext-gd": "8.0.28",
"ext-mbstring": "8.0.28"
}
}
}
这样即使你在 8.2 环境下运行 composer require，也会按 8.0 的能力去解析依赖树。如果某包声明 "php": "^8.1"，Composer 会立刻报错，而不是等部署后才发现。
注意：platform 只影响依赖解析，不改变实际运行时扩展是否加载。它是个“声明式约束”，不是“模拟运行环境”。扩展没装，光声明了也没用。
别忘了 platform 设置后要重新运行 composer update 才生效，require 不会自动刷新平台信息。
