autoload-dev 应配置测试代码路径（如"tests/"）到命名空间（如"tests"）的psr-4映射，不可用于加载源码；需确保路径相对composer.json、命名空间与文件一致，避免与autoload冲突，且ci中禁用--no-dev。
autoload-dev 里该写什么路径
它只负责把测试代码（比如 tests/ 或 src/Tests/）映射到命名空间，不加载源码。常见错误是把它当 autoload 用，结果跑测试时类找不到，或者生产环境意外加载了测试类。
- 路径必须是相对于
composer.json所在目录的，比如"tests/"表示项目根目录下的tests/文件夹 - 命名空间要和实际 PHP 文件里的
namespace严格一致，末尾加不加都行，但推荐不加（"Tests"而非"Tests\"） - 如果测试类用了和 src 相同的命名空间（比如
AppFeatureTest），别硬塞进autoload-dev—— 这会导致命名冲突或覆盖，应该统一用 PSR-4 + 独立目录
示例：
"autoload-dev": {
"psr-4": {
"Tests\": "tests/"
}
}
为什么 vendor/bin/phpunit 找不到测试类
根本原因是 composer install 默认不执行 autoload-dev 的生成逻辑，除非显式启用开发依赖。这跟是否运行 phpunit 本身无关，而是 autoloader 文件压根没包含那些映射。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 本地开发必须用
composer install --dev或直接composer install（因为默认开启--dev） - CI/CD 流水线里如果用了
composer install --no-dev，那autoload-dev就完全被忽略，phpunit必然失败 - 检查是否生效：运行
composer dump-autoload --dev后，打开vendor/autoload.php，搜索Tests\看是否存在对应注册
classmap 和 psr-4 在 autoload-dev 里混用的风险
可以混，但容易引发隐性问题：classmap 是文件级扫描，psr-4 是路径+命名空间推导，两者规则不同，一旦路径重叠，classmap 会优先命中并跳过后续查找。
- 比如同时配置了
"Tests\": "tests/"（psr-4）和"tests/Helper.php"（classmap），那么Helper.php里的类即使没声明namespace Tests，也会被载入，且无法被其他命名空间引用 - classmap 不支持动态文件增删，每次加新测试文件都得重新运行
composer dump-autoload --dev - 绝大多数情况只用 psr-4 就够了；classmap 更适合 legacy 测试脚本或无命名空间的
.php文件
测试类里 use 语句报错：Class not found
不是 Composer 配置错了，而是 PHP 解析器根本没走到 autoloader 那步——常见于测试文件本身语法错误、或用了错误的命名空间前缀。
- 检查测试文件顶部
namespace是否和autoload-dev中定义的一致，例如配置了"Tests\": "tests/"，那tests/Unit/ExampleTest.php就必须以namespace TestsUnit;开头 - 确保测试文件是
.php后缀，且没有 BOM 头（Windows 编辑器易产生） - 运行
php -l tests/Unit/ExampleTest.php确认语法无误；再用composer show --platform确认当前 PHP 版本满足测试依赖要求
autoload-dev 不是魔法开关，它只是告诉 Composer：“这些路径下的类，在开发时允许被自动加载”。真正起作用的前提，是你的测试运行器（如 phpunit）确实触发了 Composer 的 autoloader，而这个链条里任何一环断开，都会表现为“Class not found”。
