platform必须写在composer.json根级config对象内，如"config": {"platform": {"ext-mbstring": "8.2.0"}}，字符串版本号需精确匹配php -m输出的扩展名，仅影响依赖解析不解决运行时缺失。
composer.json 里 platform 配置写在哪、怎么写才生效
它必须放在 composer.json 的根级 config 对象里，不是 require 或 autoload 下。写错位置等于没写，composer install 完全无视。
-
platform是 config 的子字段，不是顶级字段；漏掉"config": {}外层包裹会直接报错或静默失效 - 扩展版本号必须是字符串，比如
"ext-mbstring": "8.2.0"，写成8.2或8.2.0.0可能被忽略（取决于 Composer 版本） - 只影响依赖解析阶段，不安装/启用任何扩展；它只是“告诉 Composer：就当这些扩展已装好且是这个版本”
- 常见误写：
"platforms"（多了一个 s）、"php"写在 platform 里（应写在config.platform.php或顶级require.php）
为什么 ext-xxx 指定后仍提示“extension not found”
因为 platform 不解决运行时缺失，只绕过依赖检查。报这个错说明 PHP 实际没加载对应扩展，Composer 已经“信了”，但 PHP 进程不信。
- 先确认扩展是否真实可用：
php -m | grep mbstring或php -i | grep -A5 -B5 mbstring - 如果扩展名拼错（如写成
ext-mb_string），Composer 不报错但不匹配 —— 扩展名必须和php -m输出完全一致（区分下划线/短横） - 某些扩展（如
ext-gd）有子版本差异（freetype/jpg/png 支持），platform无法模拟这种细节，只能骗过主版本依赖 - PHP CLI 和 Web SAPI（如 Apache/Nginx）可能加载不同配置，
composer install用的是 CLI 的 php.ini，而运行时可能是另一个
composer update 时 platform 版本被忽略的几种情况
最常发生在 lock 文件已存在且未强制刷新时。Composer 优先复用 composer.lock 中记录的解析结果，哪怕 platform 改了也不重算。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 改完
platform后必须加--lock或删掉composer.lock再composer update，否则无感知 - 如果依赖包在
require里用了^或~约束，且旧 lock 里已锁死一个兼容旧 platform 的版本，update 可能不升级 —— 要加--with-all-dependencies强制重解 - 某些插件（如
hirak/prestissimo）或自定义 installer 在早期版本中会跳过 platform 检查，升级 Composer 到 2.5+ 可规避 -
composer show --platform可验证当前生效的 platform 映射，比猜靠谱
用 platform 模拟扩展版本的真实限制
它只能伪造“存在性 + 主版本号”，对扩展内部行为、函数签名、常量定义、ZTS/NTS 编译差异完全无感。别指望靠它跑通 mb_str_split()（PHP 7.4+）却在 PHP 7.3 环境里测试。
- 函数级兼容性无法模拟：比如
ext-curl8.1 新增CURLINFO_PRIMARY_PORT，platform 设成"8.1.0"不会让 7.4 的 curl 扩展出这个常量 - 扩展 ABI 不一致时会 Segfault：比如用 PHP 8.2 编译的
ext-redis.so 强行塞给 8.1 运行，platform 设再准也没用 - Windows 下部分扩展（如
ext-sockets）默认不可用，platform 设了也白设 —— 因为底层根本没实现 - 真正可靠的方案仍是容器或 VM：platform 只适合 CI 中快速对齐依赖树，不是本地开发兜底手段
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
