Composer如何为包提供自动化的示例代码_配置 bin 字段执行示例【文档利器】

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 文件并进行配置”。