Composer本身不生成API文档，所有生成均依赖外部工具（如phpDocumentor）和显式配置scripts；需在composer.json中定义语义化命令、确保require-dev已安装工具、路径正确且环境兼容。
Composer 本身不生成 API 文档，你在项目里执行 composer install 或 composer dump-autoload 不会产出任何 HTML、Markdown 或交互式接口页——它只管装包和写自动加载映射。
为什么 vendor/bin/phpdoc 执行后没文档？
常见现象是命令看似跑完，但 docs/api 目录为空或只有骨架；或者报错 Could not locate any files to parse。
-
phpdoc.xml中的<fileset>必须包裹<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> - 本地预览：PHP 自带服务器足够用，
php -S localhost:8000 -t docs/api，比配 Nginx 更快验证结构 - 别忽略
exclude：漏掉Tests/或Fixtures/，文档索引会混入大量测试辅助类，影响开发者查找真实 API
最常被忽略的点是：文档生成依赖代码注释质量。哪怕配置全对、路径全准，如果 src/ 下的方法没写 @param 或 @return，生成的页面就只剩函数名和空参数列表——工具不会猜逻辑，它只忠实反映你写的注释。
