有用，但仅在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 后缀。

• 正确："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 扩展，后者会覆盖前者检查——这是个隐蔽的坑。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• "config": {"platform": {"ext-curl": "0"}}} 会让 Composer 假装 curl 已存在，跳过真实检查
• 仅应在测试或打包镜像时临时使用，生产环境配置里绝对不要留这种字段
• CI 脚本中如果用了 --ignore-platform-req=ext-curl，等于主动绕过检查，部署时风险自担
• 推荐做法：删掉所有 platform 下的 ext- 条目，让检查回归真实环境

为什么有些扩展声明了却没报错，但运行时还是失败

因为 ext- 只验证扩展是否加载，不保证其功能完整。比如 ext-openssl 存在，但若 OpenSSL 库版本太旧，openssl_encrypt() 仍可能抛出警告或静默失败。

立即学习“PHP免费学习笔记（深入）”；

• ext-pdo 存在 ≠ pdo_mysql 可用；要单独声明 ext-pdo_mysql
• ext-gd 存在 ≠ 支持 WebP；得看编译时是否链接了 libwebp
• 真正保险的做法：在部署后加一个轻量健康检查脚本，调用关键函数并捕获异常，比如 function_exists('curl_init') + extension_loaded('mbstring')

实际部署时最容易被忽略的，是扩展依赖的底层系统库（如 libpng、libjpeg）缺失——Composer 根本不查这个，得靠 Dockerfile 或运维文档兜底。