composer.json是PHP包的身份证,必须存在且合法;它定义名称、类型、许可证、自动加载等核心配置,缺失则Packagist不认、依赖无法安装,需通过composer validate校验、dump-autoload生效。

composer.json 必须存在且合法
没有 composer.json,Packagist 不认你,composer require 会报 Package not found。它不是可选配置,而是包的身份证。
- 运行
composer init交互生成基础文件,或手写一个最小可用版(至少含name、type、license) -
name必须是vendor/name格式,且与 GitHub/GitLab 仓库名一致(大小写敏感) - 执行
composer validate—— 失败就别推,CI 会卡在这里;常见错如license字段缺失、description为空 - 如果项目是库(非应用),
type建议设为library;是框架扩展则用metapackage或plugin
autoload 配置决定别人能不能用你的类
不配 autoload,require 进来也 class not found。Composer 不自动扫描文件,它只信 composer.json 里写的路径。
- PSR-4 是首选:
"autoload": { "psr-4": { "Vendor\Package\": "src/" } }—— 确保命名空间前缀与目录结构严格对应 - 测试类要单独加
autoload-dev,否则composer install --no-dev后phpunit找不到TestCase - 改了
autoload后必须运行composer dump-autoload,否则新路径不生效 - 不要把
vendor/或tests/目录塞进主autoload—— 这会导致生产环境加载测试代码
support 和 funding 字段不是装饰,是维护入口
用户遇到问题或想赞助,第一反应是看 composer show vendor/package 或 Packagist 页面 —— 这些字段直接决定他们能不能找到你。
工作流任务拆解与模型编排技能。使用场景:(1) 收到复杂工作任务需要拆解为可执行步骤,(2) 需要为不同步骤选择最合适的模型,(3) 需要跟踪工作流进度和模型使用情况,(4) 长时间任务卡住需要问题诊断和解决方案。
-
support要真实可用:issues指向开启的 GitHub Issues 页面,source必须能git clone,email推荐用security@这类专用别名 -
funding只有按规范写才被识别:"type": "github"(小写,不能写Github),url必须是完整 HTTPS 链接(如https://github.com/sponsors/yourname) - 这两个字段不会影响安装,但若没同步到 Packagist(push tag 或手动 sync),本地改了也白搭 —— 终端不会显示赞助提示,Packagist 页面也不出现 ? 图标
- 别把 PayPal 链接塞进
support.email,那是给求助用的,不是打赏入口
本地开发时,composer update 才认 path 仓库
fork 项目后改代码,composer install 依旧拉远程稳定版 —— 它不重新解析仓库配置,也不会重建软链接。
- 在主项目的
composer.json中加repositories:{ "type": "path", "url": "../my-forked-package", "options": {"symlink": true} } -
require里版本必须用"*"或"dev-main",写"1.2.3"会让 Composer 忽略本地路径 - 必须执行
composer update vendor/package-name,不是install—— 否则 vendor/ 下还是旧副本 - Windows 上软链接失败?用 PowerShell 管理员模式运行,或临时换
--prefer-source
关键点不在“加支持”,而在“让每个环节都可验证”:composer validate 过了,composer dump-autoload 生效了,composer show 能看到 support/funding,composer require 装完就能 new 出类——这才算真正支持了 Composer。










