authors 字段必须是对象数组，单人也需写成[{"name":"张三"}]，字符串或单对象均导致validate报错且show无法识别；email推荐填真实可响应地址，homepage可选但利于packagist展示。

composer.json 的 authors 字段必须是数组，哪怕只有一个人

不是可选项，是硬性结构约束：Composer 官方 JSON Schema 明确要求 authors 是对象数组，每个元素至少含 name 字段。写成字符串（如 "author": "张三"）或单个对象（如 "author": {"name": "张三"}）都会导致 composer validate 报错，且 composer show 无法识别、显示为空。

• composer init 交互中输入作者时，它会自动帮你包成数组 —— 但如果你跳过、回车留空，后续手动补，务必记得加中括号
• 只有一人也得写成 [{"name": "张三", "email": "zhangsan@example.com"}]，不是 {"name": "张三"}
• Windows 下用记事本编辑容易因编码问题让 email 字段乱码，建议用 VS Code 或 Notepad++ 并保存为 UTF-8 无 BOM

为什么 email 推荐填、homepage 可选但值得加

email 不是必填项，但几乎所有主流工具（Packagist、GitHub Composer 插件、IDE 插件）都依赖它做联系人溯源；不填会导致 composer show vendor/package 输出里缺失关键标识，协作排查时多一层障碍。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• email 应为真实、可响应的地址，避免用公司统一邮箱（如 support@company.com）—— 多人共用一个 email，composer show 仍能显示，但失去个人责任归属
• homepage 可填个人博客、GitHub 主页或团队官网，对 Packagist 页面展示友好，不影响命令行行为
• 别把 role 当装饰字段乱填；虽然 schema 支持，但目前无任何官方工具解析或展示它

composer init -n 不会覆盖已有 authors，但也不会自动填

很多人以为加 -n 参数就能“静默初始化并写入作者”，实际它只会跳过所有提问，对已存在的字段完全不动，对空字段（如 type、license）才补默认值。如果 authors 没预先写好，init -n 后它就是空数组或根本不存在。

• 安全做法：先用 echo '{ "authors": [] }' > composer.json 创建骨架，再跑 composer init -n 补全其他字段
• 更推荐直接手写最小 composer.json：至少含 name 和 authors，其余字段按需后加
• 别信 AI 自动生成的 composer.json 示例——它常把 authors 写成对象或漏掉中括号，validate 一跑就挂

composer show 看不到作者？先查这三个地方

composer show vendor/package authors 输出为空或报错，大概率不是命令问题，而是元数据源头没写对。

• 检查该包的 composer.json 根层级是否存在 authors 数组（不是 author 单数字段，也不是 contributors）
• 确认数组里每个对象都有 name 字段，且值不是空字符串或纯空格
• 若包是本地开发的（未 push 到 Packagist），composer show 默认查远程源；加 --local 参数才能读取当前项目 vendor/ 下已安装包的本地 composer.json

真正起作用的只有 authors 数组本身，格式不对就等于没写。它不参与依赖解析、不触发任何自动逻辑，但一旦出错，协作链路里第一个被卡住的就是“这包谁维护的？”——这个看似最简单的字段，恰恰最容易因省略中括号、混用单复数、编码错误而失效。