composer test只是composer run-script test的简写，能否执行取决于脚本名严格为小写test、位于composer.json顶层scripts字段、且自动加载配置正确；常见失败原因是"test": "phpunit"未适配环境路径，应改用"test": "vendor/bin/phpunit"。
composer test 不是魔法命令，它只是 composer run-script test 的简写；脚本能否跑通，取决于名字拼对、位置放对、autoload 引对——三者缺一不可。
为什么 composer test 没反应？
最常见的情况是：你写了 "test": "phpunit"，但没确认 phpunit 是否真在当前环境可执行。
-
phpunit命令默认走系统 PATH，CI 容器或 Windows CMD 下大概率找不到 → 改用"test": "vendor/bin/phpunit" - 脚本名写成
"Test"、"php:test"或"pre-test"→ Composer 只认严格小写的test，其他全静默跳过 -
scripts被误塞进extra或config字段 → 必须在composer.json顶层，和require同级 - 本地改完没运行
composer validate→ JSON 格式错误会导致整个scripts被忽略
post-install-cmd 和 post-update-cmd 能不能自动跑测试？
可以，但得明白它们的触发边界——不是“每次 install/update 都跑”，而是“真正发生依赖变更时才跑”。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
post-install-cmd：只在vendor/为空或composer.lock与composer.json冲突需重建时触发；已有依赖且 lock 没变 → 直接跳过 -
post-update-cmd：每次composer update都稳定触发，包括composer require xxx，更适合做测试兜底 - 想“装完就测”，推荐统一配到
post-update-cmd，并加--no-interaction避免卡住 - 测试失败默认让整个命令返回非零码 → 若不希望中断安装流程，得在命令末尾加
|| true，例如："@php vendor/bin/phpunit || true"
PHP 脚本里调用项目类为啥报 Class not found？
因为 Composer 执行 scripts 时不会自动加载项目 autoloader，这不是 bug，是设计如此。
- 必须在 PHP 脚本第一行显式引入：
require __DIR__ . '/vendor/autoload.php'; - 如果脚本放在
scripts/目录下，__DIR__指向的是该目录，不是项目根目录 → 路径要写成dirname(__DIR__) . '/vendor/autoload.php' - 别用
include_once 'vendor/autoload.php'—— 相对路径在不同工作目录下会崩 - 回调写法如
"post-install-cmd": "MyTestRunner::run"同样需要确保MyTestRunner已被 autoload 映射，且方法是public static
CI 环境下测试脚本常失败的真实原因
不是脚本写错了，而是环境和权限没对齐。
-
sh: 1: vendor/bin/phpunit: Permission denied→ Linux/macOS 下vendor/bin/phpunit缺少可执行位，应改用php vendor/bin/phpunit -
Command 'npm' not found→ CI 镜像没装 Node.js，不能只看本地有就认为线上也有 -
--no-scripts被默认启用（尤其 GitHub Actions 的某些基础镜像）→ 显式加--no-interaction不等于禁用脚本，但--no-scripts会彻底关闭所有钩子 - 测试依赖（如
phpunit）只在require-dev里 → 若 CI 运行composer install --no-dev，vendor/bin/phpunit根本不存在
真正容易被忽略的点是：脚本执行时的当前工作目录是 composer.json 所在目录，但 getcwd() 可能被 symlink、Docker volume 或 shell 封装器篡改；任何基于相对路径的操作（比如读取 phpunit.xml）都建议先用 chdir(dirname(__FILE__)) 锚定，再操作。
