composer fund 命令存在，但仅限 Composer 2.5.0+ 和 3.x 版本；它纯本地读取已安装包 composer.json 中顶层 funding 字段并格式化输出，不联网、不跳转、不验证链接有效性。
composer fund 命令到底存不存在？
它存在，但只在 Composer 2.5.0+（含）和 3.x 中作为内置命令出现；低于该版本的 Composer 会报错 Command "fund" is not defined。这不是 bug，而是版本门槛问题——你运行失败，大概率只是因为 composer --version 显示的是 2.4.x 或更早。
注意：这个命令从不发起任何网络请求、不跳转页面、不验证链接有效性，它纯本地读取已安装包的 composer.json 文件里的 funding 字段，然后格式化输出。
- 确认是否可用：运行
composer list | grep fund，有输出即支持 - 若无输出，升级 Composer：
composer self-update - 升级后仍不可用？检查是否被 alias 或 wrapper 脚本劫持（比如某些 Docker 镜像自带阉割版）
funding 字段写在哪才有效？
必须写在被依赖的包自身的 composer.json 顶层，而不是你项目的根 composer.json。例如你想让 monolog/monolog 的赞助链接出现在 composer fund monolog/monolog 输出里，那字段就得在 vendor/monolog/monolog/composer.json 里，而不是你项目根目录下的那个文件。
常见误配场景：
- 把
funding写在自己项目的composer.json里 →composer fund不会显示它（除非你加--self参数） - 写了但没发新版：Packagist 缓存的是旧版本的
composer.json，即使 GitHub 上已更新，vendor/里还是旧文件 -
type写成Github或GITHUB→ 必须小写，如github、opencollective、tidelift -
url是短链或相对路径 → 必须是完整 HTTPS 地址，如https://github.com/sponsors/Seldaek
为什么运行 composer fund 看不到某个包的赞助链接？
不是所有包都声明了 funding，也不是所有声明了的都能立刻被看到。最常被忽略的三个原因：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer fund默认只扫描require里的包，不包含require-dev；若某工具包（如phpunit/phpunit）只在开发依赖里，需加--dev参数 - 你本地安装的是旧版本：运行
composer show monolog/monolog看当前版本号，再查该版本 tag 对应的composer.json是否含funding字段 - 字段虽存在，但格式非法：比如
funding是对象而非数组、url缺失、type值不在官方推荐列表里（虽然不报错，但部分工具可能跳过）
快速验证方式：cat vendor/monolog/monolog/composer.json | jq -r '.funding[].url' —— 这比依赖 composer fund 更直接可靠。
支持开源，真正起作用的是哪一步？
composer fund 只是信息入口，真正的支持动作发生在你点击链接之后：登录 GitHub Sponsors 页面完成订阅、在 Open Collective 页面选择捐赠档位、或访问作者自建的 PayPal/Buy Me a Coffee 页面付款。Composer 本身不参与资金流转，也不存储任何支付凭证。
这意味着：
- 链接打不开？检查你是否已登录对应平台（如 GitHub Sponsors 要求登录）
- 看到多个链接？优先选
type: github或type: tidelift，它们通常有企业级赞助通道，对维护者更可持续 - 没看到链接 ≠ 不能支持：很多活跃项目（如 Laravel 官方组件）尚未配置
funding，但官网或 README 里明确写了赞助方式
最关键的细节往往藏在版本同步节奏里：一个包今天在 GitHub 主干上加了 funding，但没打新 tag，也没触发 Packagist 同步，那么 composer fund 就永远看不到它——不是命令失效，而是数据还没流动到你的 vendor/ 目录。
