Composer如何自动生成文档_Composer辅助工具应用建议

先说说这个让不少人容易误解的地方：Composer 本身并不是文档生成工具。所有“自动生成”文档的工作，实际上都是由外部工具完成的，比如 PHPDocumentor、Doctum 等。所谓 Composer 能自动生成文档，本质上是利用 composer.json 里的 scripts 字段，把这些工具的调用封装成一条命令，真正干活的是外部工具，Composer 只是负责把命令跑起来。

举个例子，很多人把 phpdocumentor/phpdocumentor 放进 require-dev 就以为完事了。其实它只是被下载到了 vendor/bin/phpdoc 里，你不主动运行，它不会自己干活。这跟 Composer 自己的生命周期是两回事。

那么，为什么 composer install 不会自动出文档？

因为 Composer 的核心职责只有三件：解析 composer.json、把依赖包下载到 vendor/ 目录、生成自动加载映射。它不会去扫描 PHPDoc 注释，不会分析类结构，也不会主动调用 phpdocumentor 或 doctum。因此，指望 composer install 自动生成文档，从一开始就找错了方向。

在实际项目中，还有几个常见的坑值得提醒一下：

• 如果直接在 post-install-cmd 或 post-autoload-dump 钩子里写生成命令，意味着每次运行 composer install 都会全量重建文档。这在 CI 构建时会显著增加耗时，本地开发也会感到卡顿。
• 真正意义上的“自动”，其实依赖 CI/CD 流水线，比如借助 GitHub Actions，监听 src/ 目录的变更，触发 composer run docs。而不是通过 Composer 的安装或更新钩子去实现。
• composer dump-autoload 也不会触发任何文档相关逻辑，它只刷新类的自动加载映射，和注释解析没有半点关系。

那么，composer.json 里的 scripts 到底该怎么配才可靠？

核心原则其实很简单：脚本只负责调用，不要把逻辑逻辑写在里面。路径、参数、模板这些，最好都配置在外部文件里，避免在 JSON 字符串里转义、调试时处处碰壁。

几个实践中的建议：

• 使用 "docs": "php vendor/bin/phpdoc --config=phpdoc.xml" 这种方式，而不是直接把目录和参数写在命令里。前者把规则集中在配置文件中，方便管理和修改；后者每次调整目录都要改命令，不够灵活。
• 如果项目里包含私有 SDK，且命名空间统一为 corp/*，可以在 phpdoc.xml 的 里加上 vendor/corp/internal-sdk/src。别指望通过 composer show 的输出来自动注入路径，文档工具读不了那个。
• 建议加上 --force 参数，比如写成 "docs": "php vendor/bin/phpdoc --config=phpdoc.xml --force"。否则缓存可能会让你看不到刚改好的 @param string $id 更新。
• 不要在 scripts 里写 exec() 或 shell_exec()。PHP CLI 环境与 shell 终端的行为常常不一致，容易在 CI 中静默失败，排查起来非常头疼。

phpdoc.xml 里最容易填错的三个地方

根据经验，90% 的生成失败或输出为空，都出在这三项配置上。它们不是可有可无的装饰，而是路径锚点，一旦设错，整个流程都跑不起来。

• src 这个路径，必须相对于 phpdoc.xml 文件本身所在的目录，而不是项目根目录。比如，如果 phpdoc.xml 在 docs/ 目录下，就需要写成 ../src，否则工具找不到源文件。
• src/Tests 要写完整的路径片段，只写 Tests 是不够的。漏掉这一行，phpdocumentor 就会去解析测试类里的 $this->mock() 这类代码，然后报 “Class not found” 警告，严重时可能导致整个命名空间被跳过。
• 设置为 * 时，工具会自动从 composer.json 的 version 字段取值。如果写死成 "1.2.0"，那每次版本更新都得手动改两处，很容易漏掉。

说到底，一次成功的文档生成并不难，难的是让它持续准确。每次修改了 public function sa ve(User $user): bool，就得同步更新 @param 和 @return。否则，phpdocumentor 输出的永远是过时的接口文档。工具链再顺畅，也救不了没人维护的注释。