Composer 的 bin 字段仅注册可执行脚本路径到 vendor/bin/，不自动运行示例；需手动编写带 shebang 和权限的脚本（如 bin/example-runner），通过 DIR 定位并加载 examples/ 下独立可运行的 PHP 文件。
Composer 的 bin 字段本身不提供“自动化示例代码”，它只负责把可执行脚本注册进 vendor/bin/，真正起作用的是你写的那个脚本文件——但这个组合确实能成为文档利器，关键在怎么搭。
bin 字段到底绑定什么？
它绑定的是包根目录下某个可执行文件的路径（相对路径），不是命令名，也不是 PHP 类。Composer 会把这个文件软链接或复制到 vendor/bin/ 下，用户才能直接运行。
-
bin值必须是包内真实存在的文件，比如"bin/example-runner"或"scripts/demo.php" - 该文件必须有可执行权限（Linux/macOS）或带 shebang（如
#!/usr/bin/env php），Windows 用户依赖.bat或 Composer 自动包装 - 如果写成
"bin": ["example-runner"]（数组形式），支持多个入口，适合提供 CLI 工具 + 示例执行器分离的场景
如何让 example-runner 真正跑起示例代码？
别指望 bin 自己解析示例目录或自动加载 —— 它只是一个转发器。典型做法是：用一个轻量 PHP 脚本读取 examples/ 下的特定文件并执行（或展示）。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
例如 bin/example-runner 内容：
#!/usr/bin/env php
<?php
if (!isset($argv[1])) {
echo "Usage: example-runner <name>\n";
exit(1);
}
$example = __DIR__ . '/../examples/' . $argv[1] . '.php';
if (!file_exists($example)) {
echo "Example not found: {$argv[1]}\n";
exit(1);
}
require $example;
- 用户执行
./vendor/bin/example-runner http-client就会加载并运行examples/http-client.php - 示例文件本身应保持独立、可直接运行（含自动引入 autoload、初始化等），不要依赖外部 CLI 参数传递环境
- 避免在示例里写
exit()以外的终止逻辑，否则后续调试难追踪
为什么有些包的 bin 示例不生效？常见坑点
最常卡在权限、路径、加载顺序这三处，和 Composer 版本关系不大，但和本地开发环境强相关。
- macOS/Linux 下忘记
chmod +x bin/example-runner，导致Permission denied错误 -
bin指向的文件用了相对 require（如require '../src/Helper.php'），但实际执行时工作目录是项目根，不是包根 —— 应统一用__DIR__定位 - 示例中直接 new 了未声明依赖的类，而包的
autoload没覆盖examples/目录（autoload.files或autoload.ps4需显式包含） - 使用了
symfony/console等组件但没在require-dev里声明，导致用户全局安装时找不到类（建议把示例依赖收进require-dev并加autoload-dev）
真正让示例“活起来”的，是你对执行上下文的控制，而不是 bin 字段本身有多智能。最容易被忽略的一点：示例文件不该假设用户已配置好 .env 或数据库连接 —— 它要么自带内存 mock，要么明确报错并提示“请先复制 .env.example”。
