config.platform.php是编译期欺骗，仅影响依赖解析阶段的PHP版本选包逻辑，不改变运行时环境；PHP 7.2仍无法执行PHP 8.0+语法或函数，运行时错误如str_contains()未定义即表明真实环境不兼容。
config.platform.php 是“编译期欺骗”，不是运行时兼容
直接改 composer.json 里的 "platform": {"php": "7.4.0"} 只会让 Composer 在 install 或 update 阶段假装当前 PHP 是 7.4，从而选到支持该版本的依赖；它不会让 PHP 7.2 突然能执行 match 表达式或 str_contains()。运行时报错（如 Fatal error: Uncaught Error: Call to undefined function str_contains()）说明你漏掉了真正的兼容性检查。
- 这个配置只影响依赖解析，不影响实际执行 ——
php -v是多少，runtime 就是多少 - 如果项目已部署在 PHP 7.2 服务器上，却用
"platform": {"php": "8.1.0"}生成了 vendor，上线必炸 -
config.platform对扩展也有作用，比如写"ext-gd": "true"会跳过 GD 是否启用的检查，但若真没加载，运行时仍会报Call to undefined function imagecreatefrompng()
修改全局 config.json 不能手动编辑，必须用命令
很多人改完 ~/.config/composer/config.json 发现没生效，是因为 Composer 启动时会校验 JSON 格式，一个多余逗号或中文引号就导致整份配置被静默忽略。更隐蔽的问题是：Windows 下 %COMPOSER_HOME%\config.json 和 %USERPROFILE%\AppData\Roaming\Composer\config.json 可能并存，Composer 优先读后者。
- 查真实生效路径：
composer config --global --list --verbose - 加私有仓库：
composer config --global repositories.myrepo '{"type":"composer","url":"https://pkg.example.com"}' - 设镜像源（国内必需）：
composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/ - 删错字段？用
--unset：composer config --global --unset repositories.myrepo
composer install 没报错但运行失败，大概率是扩展缺失或未启用
composer install 成功只代表包下载、解压、autoload.php 生成完成，不代表所有依赖函数都能调用。PHP 7.4 下装了要求 ext-mbstring 的包，但 php.ini 里注释了 extension=mbstring，Composer 不会拦你，运行时才爆 Call to undefined function mb_strlen()。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 确认 CLI 环境扩展全开：
php -m | grep -E 'mbstring|json|xml|curl|openssl|zip' - 看 CLI 实际加载的配置：
php --ini，别只信/etc/php/7.4/cli/php.ini，可能被conf.d/下文件覆盖 - Windows 用户特别注意：
php.exe和composer.bat可能指向不同 PHP 目录，打开composer.bat第二行确认调用的是哪个php.exe - XAMPP/MAMP 用户：CLI 的
php -v和浏览器访问的 PHP 版本常不一致，phpinfo()显示的是 Web SAPI，和 Composer 无关
降级包版本时，composer install 和 update 的行为完全不同
改完 composer.json 里某个包的版本号（比如把 "guzzlehttp/guzzle": "^7.8" 改成 "^6.5"），直接跑 composer update guzzlehttp/guzzle 是最危险的做法 —— 它会重新计算整个依赖图，可能顺手把 symfony/http-client 升到不兼容 PHP 7.3 的版本。
立即学习“PHP免费学习笔记（深入）”；
- 安全做法：先删掉
vendor/和composer.lock，再跑composer install，它只认composer.lock里的记录 - 如果
composer.lock里没有你要的旧版，就得先用composer require guzzlehttp/guzzle:^6.5触发一次写入，再删 vendor 重装 - 单个包强制降级：
composer update guzzlehttp/guzzle --with-all-dependencies比裸写update更可控，避免其他包意外升级 - 回滚到 Git 历史中的
composer.lock是最快恢复手段：git checkout HEAD~2 -- composer.lock && composer install
真正卡住人的从来不是怎么写 platform，而是忘了 php -m 和 php --ini 这两行命令 —— 它们比任何配置都诚实。
