有用，但仅在composer install/update时做运行时扩展加载检查，不负责安装扩展；若未启用则报错退出，可提前暴露ci/cd环境问题。
require里写ext-curl到底有没有用
有用，但只在安装/更新时起作用——Composer 会检查当前 PHP 环境是否已加载该扩展，如果没启用，composer install 或 composer update 直接报错退出，不会继续执行。
- 它不负责安装扩展本身（那是系统包管理器或 PHP 编译的事），只做“准入检查”
- 检查依据是
extension_loaded('curl')的返回值，不是看php.ini里有没有这行，而是看运行时是否真的可用 - CI/CD 流水线里加这一条，能快速暴露环境缺失，比运行到代码报
Call to undefined function curl_init()更早发现问题
ext-前缀的写法和常见拼写陷阱
扩展名必须和 php -m 输出的模块名完全一致，大小写敏感，且不能带 .so 或 .dll 后缀。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 正确：
"ext-mbstring"、"ext-pdo_mysql"、"ext-xml" - 错误：
"ext-MBString"（大小写错）、"ext-pdo_mysql.so"（多后缀）、"ext-gd2"（实际是gd） - 不确定时，本地跑
php -m | grep -i gd确认真实模块名 -
ext-iconv在某些 PHP 版本中是内置的（不可卸载），但 Composer 仍会检查；而ext-intl必须显式启用，漏掉就崩
和 platform 配置混用时的优先级问题
如果项目 composer.json 里同时写了 require 中的 ext-xxx 和 config.platform 里伪造了 PHP 扩展，后者会覆盖前者检查——这是个隐蔽的坑。
-
"config": {"platform": {"ext-curl": "0"}}}会让 Composer 假装 curl 已存在，跳过真实检查 - 仅应在测试或打包镜像时临时使用，生产环境配置里绝对不要留这种字段
- CI 脚本中如果用了
--ignore-platform-req=ext-curl，等于主动绕过检查，部署时风险自担 - 推荐做法：删掉所有
platform下的ext-条目，让检查回归真实环境
为什么有些扩展声明了却没报错，但运行时还是失败
因为 ext- 只验证扩展是否加载，不保证其功能完整。比如 ext-openssl 存在，但若 OpenSSL 库版本太旧，openssl_encrypt() 仍可能抛出警告或静默失败。
-
ext-pdo存在 ≠pdo_mysql可用；要单独声明ext-pdo_mysql -
ext-gd存在 ≠ 支持 WebP；得看编译时是否链接了 libwebp - 真正保险的做法：在部署后加一个轻量健康检查脚本，调用关键函数并捕获异常，比如
function_exists('curl_init')+extension_loaded('mbstring')
libpng、libjpeg）缺失——Composer 根本不查这个，得靠 Dockerfile 或运维文档兜底。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
