composer depends 只查询已安装包的显式 require 关系，基于 composer.lock 快照，不分析代码加载、provide 替代或未安装依赖，需确保包名正确、在根目录运行且已安装。
composer depends 只能查到当前 composer.lock 和 vendor/ 中已解析、已安装的反向依赖路径，不预测、不推导、不覆盖虚拟包替代关系。
它查的是“谁在 require 这个包”，不是“谁可能用到它”
命令扫描的是所有已安装包的 composer.json（包括 root 项目），检查其 require 或 require-dev 字段是否显式声明了目标包。它不会分析代码里的 require_once、运行时 class_alias 或插件动态加载逻辑。
- 如果某个包只写在
composer.json的require-dev里，但你执行过composer install --no-dev，那它不会出现在depends结果中——因为没被安装 - 如果目标包是通过
replace或provide被满足的（比如monolog/monolog提供了psr/log），直接查psr/log会返回空，得换查提供者 -
depends不关心版本约束是否兼容，只认 lock 文件里实际锁定的版本和路径
加 --tree 才能看到完整路径，但层级有严格限制
composer depends --tree vendor/package-name 展示的是当前 composer.lock 中真实存在的依赖链，每一层都必须在 lock 文件的 packages 或 packages-dev 数组里有对应条目。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 中断在某一层（比如只显示
laravel/framework就停住），大概率是它用provide声明满足了目标包，Composer 不再向下解析 - 不会显示未被 lock 文件采纳的分支或别名路径，例如你写了
"dev-main as 1.0.0"，但 lock 文件里记录的是dev-main#abc123，查1.0.0就找不到 -
--tree输出中带[dev]后缀的节点，表示该依赖来自require-dev，不影响生产环境类加载
区分 require 和 require-dev 必须加参数
depends 默认把两类依赖混在一起输出，无法直接判断一个包是生产依赖还是开发工具链引入的。
- 只看生产环境依赖：用
composer depends vendor/package-name --link-type=require - 只看开发依赖：用
composer depends vendor/package-name --link-type=require-dev - 想确认是否可安全移除：如果它只出现在
require-dev链路里，且没有 runtime 类被 autoload 加载，通常可删 -
--format=json输出中字段linkType明确标出类型，适合脚本自动判断
空输出 ≠ 没人用，先核对这三件事
执行后没结果，不是命令失效，而是环境或输入没对齐：
- 不在项目根目录运行 ——
composer.json和composer.lock必须存在且可读 - 包名拼错 ——
monolog/monolog对，Monolog/Monolog、monolog-monolog、monolog全错 - 包根本没安装 —— 运行
composer show vendor/package-name，若报Package not found，说明它不在vendor/里，depends无从查起
真正容易被忽略的是：所有输出都基于 composer.lock 的快照，不是 composer.json 的声明。改完配置不 update，查出来的就还是旧关系。
