私有包拉不到90%是鉴权问题：auth.json必须放在项目根目录或~/.composer/auth.json，格式为{"http-basic":{"your-internal-mirror.example.com":{"username":"api","password":"token123"}}}，权限需设为600，且镜像服务须启用认证校验。
私有包拉不到，90% 不是网络问题，而是鉴权没配对——auth.json 位置错、凭据格式不对、或镜像服务根本没启用认证校验。
私有镜像源要求 Basic Auth 或 Bearer Token 时，auth.json 必须放对位置
Composer 只在两个地方找 auth.json：当前项目根目录（优先），或全局 ~/.composer/auth.json。它不会递归查找，也不会读取 vendor/ 或子目录下的同名文件。
- 项目级鉴权（推荐）：把
auth.json放在和composer.json同级的目录下，内容为：{"http-basic": {"your-internal-mirror.example.com": {"username": "api", "password": "token123"}}} - 全局鉴权（慎用）：运行
composer config -g http-basic.your-internal-mirror.example.com api token123，会自动写入~/.composer/auth.json - 别把凭据硬编码进
composer.json的repositories里——这既不安全，也会被 Git 提交泄露
composer install 报 401 Unauthorized 或 403 Forbidden 的真实原因
不是密码输错了，而是请求头没发过去，或者服务端没识别到。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 确认镜像服务是否真启用了鉴权：有些 Satis 部署默认无认证，你配了
auth.json也白搭 - 检查
curl -v -u api:token123 https://your-internal-mirror.example.com/packages.json是否返回 200 —— 这比composer install日志更直接 - Bearer Token 场景下，
auth.json要写成：{"github-oauth": {"your-internal-mirror.example.com": "ghp_abc123..."}}，注意字段名不是http-basic - 若镜像基于 Artifactory/Nexus，需确认其 Realm 值（如
Artifactory Realm）是否与 Composer 发送的Authorization头匹配，不匹配就 403
私有包能下载但 vendor/autoload.php 找不到类？
鉴权成功 ≠ 自动加载生效。这是两个独立环节。
- 先验证包是否真装进来了：
ls vendor/myorg/package-a/src/，如果目录空或结构不对，说明 ZIP 包本身没打包正确 - 检查私有包自己的
composer.json是否声明了autoload，例如："autoload": {"psr-4": {"MyOrg\PackageA\": "src/"}} - 项目级补 autoload（仅临时绕过）：
"autoload": {"psr-4": {"MyOrg\": "vendor/myorg/package-a/src/"}}，然后必须跑composer dump-autoload - 如果私有包是 ZIP 归档且无
composer.json，只能靠classmap手动映射："autoload": {"classmap": ["vendor/myorg/package-a/lib/"]}
最常被忽略的点：Satis 生成的 packages.json 里每个包的 dist.url 是由 satis.json 中的 homepage + archive.prefix-url 拼出来的；如果这两项没配对，即使鉴权通过，ZIP 下载地址仍是 404 —— 此时 composer install 会卡在 “Downloading” 然后静默失败，连错误码都不报。
