要限制PHP最高兼容版本，必须显式指定上限，如"php": ">=8.1.0 =8.1.0"，无法阻止PHP 9.0。
composer.json 里怎么写 PHP 版本上限才真正生效
只写 "php": "^8.1" 或 "php": "8.1"，根本拦不住 PHP 9.0 —— Composer 会把它解析成 ">=8.1.0"，没有上界。真要限制最高兼容版本，必须显式写出上限，比如 "php": ">=8.1.0 。
常见错误现象：本地 PHP 8.3 正常，CI 环境升级到 PHP 9.0 后 composer install 成功但运行时报错，就是因为旧约束没封顶。
-
"php": "~8.1"等价于">=8.1.0 ，太窄，连 8.1.10 都可能被拦住 -
"php": "^8.1"等价于">=8.1.0 ，看似安全，但这是 Composer 的默认推导，不是你声明的约束；一旦未来语义化规则变更或解析器行为调整，就不可靠 - 必须手写
"php": ">=8.1.0 ，双引号包裹，含空格和符号，否则 shell 会截断
为什么已发布的包无法 retroactively 加 PHP 上限
一个 tagged 版本（如 v2.4.1）发布到 Packagist 后，它的 composer.json 内容就固化了。你想给 v2.4.1 补上 "php": ">=7.4 ？不行。Git tag 不可变，Packagist 元数据也不可编辑。
强行删 tag + 重推，会导致依赖该版本的项目 composer update 失败或拉到不一致内容，社区信任直接崩塌。
- 唯一合规做法：发新 patch 版本，比如 v2.4.2，里面带上完整上下界约束
- 同时在 CHANGELOG 和 README 显眼位置提醒用户：“v2.4.1 及更早不兼容 PHP 8+，请升级至 v2.4.2+”
- 别用
minimum-stability或prefer-stable替代版本约束——它们管不到 PHP 解析器层面
第三方包的 PHP 版本上限冲突怎么排查
执行 composer install 报错类似 Your requirements could not be resolved to an installable set of packages，且提示某包要求 php: >=8.0，而你的项目锁了 php: >=7.4 ，这就是上限硬冲突。
关键不是看谁“写得更狠”，而是看谁的约束先被 Composer 解析并钉死。
- 运行
composer why php查哪些包间接引入了宽松 PHP 要求 - 用
composer show vendor/package --tree往上翻依赖链，定位最早那个没设上限的包 - 如果它不维护了，只能 fork 后发个带上限的 alias 版本，或加
replace规则临时屏蔽 - 注意：预发布版（如
dev-main）默认被排除，除非你设了"minimum-stability": "dev"，这会让上限更难控
COMPOSER_MEMORY_LIMIT 和 php.ini memory_limit 的优先级关系
内存溢出不是版本问题，但常和大范围版本解析一起发生。Composer 自己的内存控制优先级高于 PHP 全局配置。
比如你在 php.ini 里写了 memory_limit = 1G，但跑 COMPOSER_MEMORY_LIMIT=512M composer update，它就真只用 512MB —— 超了直接报 Allowed memory size exhausted，不会 fallback 到 php.ini 的值。
- 推荐始终用环境变量：
COMPOSER_MEMORY_LIMIT=-1（不限制）或COMPOSER_MEMORY_LIMIT=2G - 避免改 php.ini，尤其在共享 CI 环境中，容易影响其他 PHP 任务
-
php -d memory_limit=-1 composer install是临时方案，适合单次调试，不适合 CI 脚本固化
PHP 版本上限不是“写了就完事”的配置项，它是依赖解析链最上游的守门人。漏掉 这半截，等于把门钥匙交给了未来未知的 PHP 主版本。所有已发布的旧版本都无法打补丁，能做的只有向前兼容、明确提示、强制升级。
