Packagist要求name字段严格为小写vendor/package-name格式且vendor须与账号一致，tag必须带v前缀（如v1.0.0），并配置GitHub webhook才能自动更新，autoload映射末尾反斜杠不可省略。
Packagist 不会自动发现你的包，必须手动提交公开仓库 URL，并确保 composer.json 合法、Git tag 已推送到远程、且 vendor 名与 Packagist 账号一致——缺一不可。
为什么 composer.json 里 name 字段总被拒
Packagist 校验 name 极其严格：必须是小写 vendor/package-name 格式，且 vendor 必须与你在 Packagist 注册的用户名完全一致（不是 GitHub 用户名，除非你已绑定并同步）。常见失败点：
-
name含大写字母、下划线或空格，例如"MyOrg/utils"或"myorg_utils"→ 直接拒绝 - 填了 GitHub 用户名但 Packagist 账号是邮箱注册，未绑定 GitHub → vendor 不匹配
- 本地
composer.json改了name，但没git add && git commit && git push到远程主分支 → Packagist 抓到的是旧内容
打 Git tag 时为什么 v1.0.0 有效而 1.0.0 无效
Packagist 默认只识别带 v 前缀的语义化版本标签。它不解析 composer.json 中的 version 字段，只靠 tag 名匹配版本约束。不加 v 的后果：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
git tag 1.0.0→ Packagist 完全忽略，composer require vendor/name:1.0.0报Could not find package - 正确命令是：
git tag -a v1.0.0 -m "First stable release"，再git push origin v1.0.0 - tag 必须指向含合法
composer.json的 commit，否则即使推送成功，Packagist 抓取时也会校验失败
为什么提交后 dev-main 可装，但 v1.0.0 找不到
这是 webhook 缺失或未触发的典型表现。Packagist 首次抓取只读一次默认分支（如 main），后续新 tag 不会自动感知。
- 进 GitHub 仓库 Settings → Webhooks → Add webhook，
Payload URL填https://packagist.org/api/github - Events 选
Just the push event（覆盖 tag 推送）或单独勾选Releases - 没配 webhook 时，每次发新版都得手动进 Packagist 包页点
Update，否则元数据永远滞留 - 配置后测试：
git tag v1.0.1 && git push origin v1.0.1，几秒内 Packagist 页面应更新Last updated时间
autoload 配错导致 Class not found 却无报错
Composer 安装成功 ≠ 类能加载。PSR-4 映射写错，composer install 不报错，但运行时直接 Fatal error。
-
"psr-4": { "MyVendor\Package\": "src/" }中末尾反斜杠\不可省略，漏掉会导致 Windows 下路径解析异常 - 命名空间声明必须与目录结构严格对应：若类文件在
src/Helper.php，命名空间就得是MyVendor\Package，不能是MyVendorPackage - 测试方法：本地执行
composer dump-autoload -o，再用php -r "var_dump(class_exists('MyVendor\Package\Helper'));"验证返回true
最易被忽略的点：Packagist 不缓存失败响应。如果某次提交因 composer.json 校验失败而中断，后续修复后必须手动点 Update，不能依赖 webhook 自动重试——它只对新事件生效，不回溯修正历史错误。
