Composer 不提供函数定义跳转功能，它仅管理依赖和生成类自动加载映射，不解析函数；查函数定义需依赖 IDE、grep 或分析 autoload.files 中注册的全局文件。
Composer 本身不提供函数定义跳转功能
Composer 是依赖管理工具，不是 IDE 或代码分析器，它不解析 PHP 代码、不索引函数定义、也不参与运行时的符号查找。你执行 composer dump-autoload 只是生成或刷新自动加载映射（如 vendor/composer/autoload_classmap.php），这个文件只记录类名到文件路径的静态映射，对函数（尤其是全局函数）完全无感知。
所以，别指望 composer 命令能直接告诉你某个函数在哪个文件里定义——它做不到。
查函数定义得靠 PHP 自身机制 + IDE 或命令行工具
PHP 的全局函数（非类方法）没有命名空间强制约束，且不能被 Composer 自动加载。它们通常来自：
- PHP 内置函数（如
array_merge），定义在 C 源码中，IDE 一般内置了 stub 支持 - 扩展提供的函数（如
mysqli_connect），由扩展 DLL/so 提供，无 PHP 源码 - 项目或 vendor 中的
.php文件里用function声明的函数（如 Laravel 的helpers.php）——这类才是你能手动定位的
实操建议：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用 IDE（PhpStorm / VS Code + intelephense）直接 Ctrl+Click 跳转：它靠的是语言服务器解析 AST，和 Composer 无关
- 命令行下用
grep -r "function my_helper" . --include="*.php"搜索整个项目（含vendor/） - 确认函数是否属于某扩展：运行
php -m看已启用模块，再查对应扩展文档 - 若函数来自 composer 包的 helpers 文件（如
laravel/framework/src/Illuminate/Support/helpers.php），可先查该包的 autoload 配置：composer show laravel/framework | grep -A5 "autoload"，看是否有"files"字段
“配合自动加载查找类文件”其实是两件事混说了
自动加载（autoload）只管 class、interface、trait 的加载，不负责函数。但 Composer 允许你在 composer.json 中声明 "autoload": {"files": [...]}，把某些 PHP 文件在每次请求时无条件 include 进来——这些文件里定义的函数才“间接”被 Composer “带进来”。
要定位这类函数的定义位置，关键不是找 autoload 映射，而是：
- 运行
composer config autoload.files查看当前注册了哪些全局文件 - 检查这些路径是否真实存在（有些包会根据环境动态注册，
composer config不一定反映运行时全貌） - 注意：这些文件在
vendor/composer/autoload_files.php中被硬编码为 require 语句，你可以直接打开这个文件看路径列表 - 如果函数不在上述
files列表里，那它大概率是写在某个类的static方法里，或者根本没被正确引入——此时应检查命名空间和 use 语句
容易忽略的关键点
很多开发者以为 composer dump-autoload -o（优化模式）会影响函数可用性，其实不会：优化只合并 classmap，对 files 加载逻辑毫无影响；函数能否调用，只取决于它所在的文件是否已被执行过（即是否在 autoload.files 里，或是否被其他代码显式 require）。
另一个盲区是：PHP 函数名不区分大小写，但文件系统可能区分。比如你在 macOS 上搜 Str::upper，实际定义可能在 Str.php 里，但函数名叫 str_upper ——这种命名风格差异会让 grep 失效，得结合 IDE 的符号搜索更可靠。
