Composer使用之如何在项目中使用Composer生成的API文档-composer-PHP中文网

composer本身不生成api文档，所有生成均依赖外部工具（如phpdocumentor）和显式配置scripts；需在composer.json中定义语义化命令、确保require-dev已安装工具、路径正确且环境兼容。

composer使用之如何在项目中使用composer生成的api文档

Composer 本身不生成 API 文档，你在项目里执行 composer install 或 composer dump-autoload 不会产出任何 HTML、Markdown 或交互式接口页——它只管装包和写自动加载映射。

为什么 vendor/bin/phpdoc 执行后没文档？

常见现象是命令看似跑完，但 docs/api 目录为空或只有骨架；或者报错 Could not locate any files to parse。

phpdoc.xml 中的 <fileset></fileset> 必须包裹 <directory></directory>，不能直接写 <directory></directory> ——v3 版本严格校验 XML 结构
路径是相对于 phpdoc.xml 所在位置，不是项目根目录；比如配置 <directory>src</directory>，而 phpdoc.xml 在 docs/ 下，就会去扫描 docs/src
默认跳过 vendor/，想包含第三方类（如 monolog/monolog 的公共接口），得显式加 <directory>vendor/monolog/monolog/src</directory>，且确保该路径下有完整 PHPDoc 注释（很多包发布时删了注释）
Windows 用户注意：vendor/bin/phpdoc 实际可能是 phpdoc.bat，脚本中建议写全路径 php vendor/bin/phpdoc 避免调用失败

如何让 composer run docs 真正可用？

关键不是起个名字，而是命令能稳定执行、路径可复现、结果可预期。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

脚本值推荐用数组而非字符串，尤其涉及清理 + 生成两步： "docs": ["rm -rf docs/api", "php -d memory_limit=-1 vendor/bin/phpdoc --config=phpdoc.xml"]
必须提前在 require-dev 里声明工具："phpdocumentor/phpdocumentor": "^3.0"，否则 vendor/bin/phpdoc 根本不存在
CI 环境（如 GitHub Actions）中，memory_limit 常被限制，不加 -d memory_limit=-1 容易在扫描大项目时 OOM 中断
若用 phpdoc.dist.xml，需显式传参 --config=phpdoc.dist.xml，否则 phpDocumentor 默认找 phpdoc.xml

生成的文档怎么接入开发流程？

静态文件生成出来只是第一步，真正有用的是让它活在日常协作中。

加到 Git Hooks：用 composer run docs 绑定 pre-commit，强制提交前更新文档（注意别把 docs/ 提交进主分支，应部署到 gh-pages 分支）
CI 自动部署：GitHub Actions 中配置 on: [push, pull_request]，生成后用 peaceiris/actions-gh-pages 推送到 gh-pages 分支，地址变成 https://<user>.github.io/<repo></repo></user>
本地预览：PHP 自带服务器足够用，php -S localhost:8000 -t docs/api，比配 Nginx 更快验证结构
别忽略 exclude：漏掉 Tests/ 或 Fixtures/，文档索引会混入大量测试辅助类，影响开发者查找真实 API