Composer 的 bin 字段：如何为包提供自动化的示例代码？
先明确一个核心概念：Composer 的 bin 字段本身并不直接提供“自动化示例代码”的功能。它的职责很单纯，就是把你包里的可执行脚本路径注册到 vendor/bin/ 目录下。真正让示例代码“跑起来”的，是你精心编写的那个脚本文件。不过，这个组合拳用好了，确实是提升文档体验的利器，关键在于怎么搭建。
bin 字段到底绑定什么？
这里有个常见的误解：bin 字段绑定的既不是命令名，也不是某个 PHP 类。它绑定的是你包根目录下某个可执行文件的相对路径。Composer 会把这个文件软链接（或复制）到全局的 vendor/bin/ 目录，用户才能直接调用。
bin的值必须是包内真实存在的文件路径，比如"bin/example-runner"或者"scripts/demo.php"。- 这个目标文件本身必须有可执行权限（在 Linux/macOS 下），并且通常需要包含 shebang 行（例如
#!/usr/bin/env php）。对于 Windows 用户，Composer 会自动生成对应的.bat包装器。 - 如果写成数组形式，比如
"bin": ["example-runner", "my-tool"]，意味着支持多个入口。这很适合需要将 CLI 工具和示例执行器分离的场景。
如何让 example-runner 真正跑起示例代码？
别指望 bin 字段自己会去解析示例目录或者自动加载代码——它本质上只是一个“转发器”。标准的做法是：编写一个轻量的 PHP 脚本，让它去读取并执行 examples/ 目录下的特定文件。
来看一个典型的 bin/example-runner 脚本内容：
#!/usr/bin/env php
\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。 - 关键在于，
examples/目录下的每个文件本身都应该是独立、可直接运行的。这意味着它们内部需要处理好自动加载（require vendor/autoload.php）和必要的初始化。 - 另外，在示例文件里，除了使用
exit()，应避免其他终止脚本执行的逻辑，否则会给后续的调试和追踪带来麻烦。
为什么有些包的 bin 示例不生效？常见坑点
问题通常出在三个地方：权限、路径和加载顺序。这和 Composer 版本关系不大，但和具体的本地开发环境强相关。
- 权限问题：在 macOS 或 Linux 系统下，如果忘记给
bin/example-runner文件添加执行权限（chmod +x），运行时会直接报Permission denied错误。 - 路径错误：脚本中如果使用了相对路径来引入文件（比如
require '../src/Helper.php'），但实际执行时的工作目录是用户项目的根目录，而不是包的根目录，就会导致文件找不到。正确的做法是统一使用__DIR__常量来定位。 - 自动加载缺失：示例代码中直接实例化了某个类，但包的
autoload配置可能没有覆盖到examples/目录。这时，需要在composer.json中通过autoload.files或autoload.psr-4显式包含这个目录。 - 依赖未声明：示例中使用了
symfony/console这类组件，但只在开发时本地存在，没有在require-dev里声明。当用户全局安装你的包时，就会因为找不到类而失败。稳妥的做法是把示例所需的依赖都收进require-dev，并配置好autoload-dev。
说到底，真正让示例“活起来”的，是你对执行上下文的精细控制，而不是指望 bin 字段本身有多智能。这里还有一个极易被忽略的要点：示例文件不应该假设用户已经配置好了 .env 环境变量或者数据库连接。它要么自带一套内存模拟（Mock）数据，要么在运行时明确报错并给出清晰的提示，比如“请先复制 .env.example 文件并进行配置”。
