Composer 无法通过 search 或 show 查找函数，因其仅索引包元数据且函数不参与自动加载；定位函数需依赖 PHP 反射、IDE 跳转或 grep 搜索源码。

Composer 本身不索引函数，composer search 和 composer show 对函数名完全无效；真正能定位函数来源的，只有 PHP 自身的反射机制或 IDE 的符号跳转，再配合手动查包结构。

为什么不能用 composer search 查函数

composer search 只在 Packagist 元数据中匹配包名、描述、关键词，它根本不知道某个包里定义了什么函数。PHP 的全局函数（非类方法）也不参与 Composer 的自动加载机制，不会出现在 autoload_classmap.php 或 PSR-4 映射里。

• 函数可能来自扩展（如 curl_init()）、PHP 内置（如 array_filter()）或纯 PHP 文件（如 functions.php）
• 即使函数在某个包里，只要没被声明为 autoloaded file（即没写进 composer.json 的 "autoload": {"files": [...]}），Composer 就“看不见”它
• 执行 composer search "str_contains" 会返回一堆无关结果，因为这个函数是 PHP 8.0+ 内置的，跟任何 Composer 包都无关

查函数归属的可行路径

先确认函数是否已加载：运行 var_dump(function_exists('your_function_name'));。如果返回 false，说明函数还没被引入——这时候查也白查，得先 require 或触发自动加载。

Workflow Decomposer

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

下载

• 若函数来自 "autoload": {"files": [...]} 声明的文件：打开对应包的 composer.json，看 autoload.files 数组里有没有包含该函数的文件
• 若函数在某个类的方法里（比如 SomeHelper::doStuff()）：先用 composer show + grep 或查 vendor/composer/autoload_classmap.php 定位类，再进源码找方法
• 最直接的办法：在项目根目录执行 grep -r "function your_function_name" vendor/ --include="*.php"（Linux/macOS）；Windows 可用 findstr /s /i "function your_function_name" vendor\**\*.php
• IDE 如 PhpStorm 能直接 Ctrl+Click 跳转到函数定义处，路径自然暴露包名（如 vendor/guzzlehttp/guzzle/src/functions.php）

常见误判场景和坑点

很多开发者以为 composer why 或 composer depends 能查函数，其实它们只处理包级依赖关系，对函数无感知。

• str_contains()、get_debug_type() 等是 PHP 8+ 新增内置函数，不是任何 Composer 包提供的——查 vendor/ 必然空手而归
• 某些包（如 symfony/polyfill-*）会“模拟”新版本 PHP 函数，但它们的函数定义藏在 bootstrap.php 或 bootstrap80.php 里，且通常通过 autoload.files 加载，必须翻具体包的 composer.json
• 使用 grep 时注意：函数名可能带命名空间（如 function Foo\bar()），正则要写全；另有些函数是 define() 或 if (!function_exists()) 包裹的，简单字符串搜索可能漏掉

函数没有“包归属”的强绑定关系，它可能跨多个包重复定义（靠 function_exists 防重），也可能随 PHP 版本升级从 polyfill 移入核心。查的时候，永远优先确认 PHP 版本和是否已加载，再动 grep 或 IDE 跳转——别在 Composer 命令上浪费时间。