asset-packagist 已停服且不兼容 Composer 2.2+，应改用带 dist 的封装包（如 twbs/bootstrap）或完全交由 package.json 管理前端依赖，PHP 仅消费构建后的静态资源。
asset-packagist 已不可用，强行配置会触发 Could not find package 或 Repository returned 404，不是你配错了，是服务本身自2021年底起停止更新，元数据大量失效，且不支持 Composer 2.2+ 默认启用的 HTTPS 仓库协议。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer.json 里加 "repositories" 指向 asset-packagist 就报错
- 错误现象：
composer require npm-asset/jquery直接失败，提示Could not find package npm-asset/jquery或Repository returned 404 - 原因：asset-packagist.org 的镜像多数仅提供 HTTP 地址，而 Composer 2.2+ 默认禁用非 HTTPS 仓库；其元数据自 2022 年后未同步，GitHub tag 删除、zip 链接过期很常见
- 替代做法：
- 改用官方或社区维护的 Composer 封装包（如
twbs/bootstrap、components/jquery），它们把 dist 文件打包进 release，安装即得可用资源 - 手动声明
package类型仓库，指向具体 GitHub tag（需写完整dist路径和type） - 完全放弃该路径，改走
package.json + npm install，用post-install-cmd触发构建（但注意 Node.js 环境必须存在）
- 改用官方或社区维护的 Composer 封装包（如
composer-asset-plugin 早已被弃用且与 Composer 2.x 不兼容
- 错误现象：运行
composer global require fxp/composer-asset-plugin后，后续composer install报Class 'Fxp\Composer\AssetPlugin\Repository\NpmRepository' not found或直接卡死 - 原因：该插件最后一次发布是 2019 年，PHP 8+ 和 Composer 2.x 的内部 API 变更已彻底破坏其运行逻辑；
--no-plugins参数也无法绕过 autoload 冲突 - 真实可用的替代方案：
- 使用
composer/installers配合自定义type，例如把"type": "npm-asset"的包解压到public/assets/（需手动在composer.json中为每个包声明type和install-path） - 在
scripts中写明确的复制命令，比如："scripts": { "assets:install": "cp -r vendor/twbs/bootstrap/dist/* public/css/ && cp -r vendor/components/jquery/* public/js/" } - 不要依赖任何“自动映射 npm 包名”的机制——它现在只是个幻觉
- 使用
为什么 post-install-cmd 调用 npm install 很容易翻车
- 常见陷阱：
- CI 环境没装 Node.js，或版本太低（
npm ci在 Node 14 下可能失败） -
node_modules权限污染：本地开发时反复运行composer install会不断触发npm install，导致node_modules归属变成 root 或混杂 UID - 构建产物路径不一致：
npm run build输出的dist/位置依赖项目自身配置，无法被 Composer 统一识别
- CI 环境没装 Node.js，或版本太低（
- 更稳妥的做法：
- 把前端构建完全独立出来：CI 流程中先
npm ci && npm run build，再composer install - PHP 侧只负责加载已构建好的静态文件，比如
<script src="/assets/app.min.js"></script> - 若必须耦合，至少用
if [ -f package.json ]; then npm ci && npm run build; fi做兜底判断
- 把前端构建完全独立出来：CI 流程中先
asset-packagist 是一个已经死亡的桥接方案，它留下的最大教训是：前端资源不该由 PHP 包管理器承担分发职责。真正稳定的方式只有两种——要么用 Composer 安装带 dist 文件的前端封装包（如 twbs/bootstrap），要么让前端依赖彻底交给 package.json 管理，PHP 只做最终资源的消费方。中间态的“自动映射”看似省事，实则把问题推给了不可控的第三方服务和过时插件。
