发布子包前须确保composer.json的name全小写带vendor前缀、version为语义化版本、type明确；CI应按变更路径单包发布；根目录repositories需清理，开发配置应分离至composer.dev.json。
发布前必须确保子包 composer.json 的 name 和 version 可被 Packagist 正确识别
Packagist 不会扫描你的仓库目录，它只认你 composer.json 里写的 name 和 version。如果子包的 name 缺失、格式非法（如含空格或大写字母），或 version 是 dev-main 这类开发专用值，Packagist 会直接拒绝收录。
常见错误现象：composer publish 报错 “Package name is invalid” 或 “Version constraint not satisfied”
-
name必须是全小写、带 vendor 前缀的合法包名，例如myorg/data-validator，不能是DataValidator或data_validator -
version在发布前应设为语义化版本（如"1.0.0"），而非"*@dev"或"dev-main"—— 后者仅用于本地 path 仓库调试 - 确保
type字段明确，如"library"、"metapackage"，避免留空或填错
用 GitHub Actions 自动触发单个子包发布，而不是全量构建
Monorepo 中多数变更只影响一个子包，全量发布既慢又易出错。推荐在 CI 中检测文件变更路径，只对受影响的子目录执行发布流程。
示例 GitHub Actions 判断逻辑（YAML 片段）：
if: ${{ startsWith(github.event.head_commit.message, '[publish: data-validator]') || contains(github.event.head_commit.modified, 'packages/data-validator/') }}
匹配后执行：
- 进入子目录：
cd packages/data-validator - 安装不含 dev 依赖的最小环境：
composer install --no-dev --optimize-autoloader - 调用
composer config github-oauth.github.com ${{ secrets.GITHUB_TOKEN }}配置认证 - 推送 tag：
git tag v1.0.0 && git push origin v1.0.0（Packagist 默认监听 tag）
根目录的 repositories 配置不能带到生产环境
你在根 composer.json 里写的 "type": "path" 仓库，只适用于本地开发。一旦推送到生产服务器或私有 Packagist，Composer 会因找不到本地路径而报错：Could not find package myorg/data-validator。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
正确做法是：在发布流程中自动移除或覆盖根目录的 repositories 段，并确保所有子包都已注册到目标源（如私有 Satis 或 Packagist）。
- CI 脚本中可用
composer config --unset repositories清理临时配置 - 若使用私有源，提前在生产环境的
composer.json中声明该源："https://packages.myorg.com"，并配好认证 - 切勿在子包自己的
composer.json中写repositories—— 它只负责描述自己，不负责发现别人
发布后仍需维护本地开发体验，别让 dev 和 prod 配置互相污染
很多人发布完就忘了：本地开发时，你依然需要 path 仓库来快速验证改动。但若根 composer.json 里的 repositories 没做环境区分，CI 构建时可能误用本地路径，导致失败。
安全做法是把开发专用配置抽离成独立文件，再通过 Composer 的 config 机制动态加载：
- 新建
composer.dev.json，只放repositories和require开发依赖 - 本地运行：
composer install -c composer.dev.json - CI/CD 使用默认
composer.json，不加载任何 path 配置
这个细节容易被跳过，但一旦团队成员在本地改了根 composer.json 却没提交，或 CI 错误地读取了开发配置，整个发布链就会卡在“找不到包”的第一步。
