composer处理二进制文件的核心逻辑是：声明→链接/复制→可执行路径匹配；bin字段声明决定暴露哪些文件，bin-dir配置指定存放目录，path或composer exec确保命令可调用，三者缺一不可。
Composer 处理二进制文件的核心逻辑是：声明 → 链接/复制 → 可执行路径匹配。不是“安装完就能用”，而是三者缺一不可。
bin 字段声明决定哪些文件会被暴露
一个包能否提供命令行工具，完全取决于它自己的 composer.json 是否定义了 bin 字段：
-
bin必须是数组，每个元素是相对于包根目录的**可执行脚本路径**（如"bin/phpunit"） - 脚本本身需有 shebang（
#!/usr/bin/env php）或在 Windows 下带.bat后缀；Linux/macOS 还需+x权限（Composer 会尝试自动加，但失败不报错） - 不支持通配符：
"bin": ["bin/*"]无效，必须写死具体文件名 - 没声明
bin，哪怕脚本真实存在，Composer 也完全忽略它
vendor/bin 是默认链接目标，但可被 bin-dir 覆盖
vendor/bin 不是硬编码目录，而是 config.bin-dir 的默认值。改它只影响“放哪”，不影响“有没有”：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 设
"bin-dir": "tools"后，phpunit会链接到tools/phpunit，而非vendor/bin/phpunit - 改完必须删掉旧
vendor/bin（或整个vendor），再运行composer install才生效——配置不会热更新 -
bin-dir对项目自身脚本也生效，但前提是你的composer.json里也写了"bin": ["bin/deploy"]，且bin/deploy文件存在且可执行 - Windows 下生成的是
.bat文件，Linux/macOS 是符号链接；跨平台一致性靠bin-compat控制（默认"full"）
PATH 和 composer exec 决定“能不能直接敲命令”
即使 tools/phpunit 已存在，终端仍可能报 command not found：
- 根本原因是系统
$PATH没包含该目录；临时解决：运行export PATH="./tools:$PATH" - 更可靠的方式是用
composer exec phpunit—— 它自动定位vendor/bin或你配的bin-dir下的对应文件，还能透传参数（如composer exec phpcs -- --standard=PSR12 src/） -
composer exec要求 Composer ≥ 2.2；它绕过了 shell 的 PATH 查找，也避免了 Windows 下.bat硬编码调用php导致的路径问题 - 别依赖
ls vendor/bin判断是否成功：先用composer show vendor/package-name看输出里有没有bin:行，再检查链接目标是否存在
常见失效场景和验证顺序
遇到 vendor/bin/xxx 找不到或执行失败，按这个顺序排查最省时间：
- 确认包是否真声明了
bin：查vendor/package-name/composer.json，不是你项目的 - 确认
vendor/bin/xxx（或你配的bin-dir目录）下是否有该文件，ls -l看链接是否指向有效路径 - 检查当前 shell 的
$PATH是否含该目录；which xxx或type xxx能快速验证 - Windows 上若报
'php' is not recognized，大概率是.bat脚本问题，改"bin-compat": "proxy"并用php vendor/bin/xxx显式调用
最易被忽略的一点：Composer 从不“复制”包里的二进制文件本身，它只做软链或生成包装脚本。真正的可执行文件始终在 vendor/vendor-name/package-name/ 子目录里——删了 vendor/bin 不影响功能，重装就回来；但删了源文件，链接就断了。
