Composer支持多命名空间自动加载，需区分PSR-4（按命名空间前缀绑定目录，路径须以/结尾且真实存在）和classmap（显式映射类与文件，优先级低于PSR-4）；autoload-dev专用于测试代码，生产环境不加载；修改配置后必须运行composer dump-autoload生效。
Composer 支持在 composer.json 中为不同命名空间配置多个自动加载规则，但必须注意 PSR-4 和 classmap 的语义差异，否则类文件根本不会被找到。
PSR-4 映射：按命名空间前缀绑定目录路径
PSR-4 是最常用的方式，每个 "namespace\\": "path/" 条目表示：以该命名空间开头的类，应从对应目录下按子命名空间结构查找文件。路径必须以 / 结尾（或用 ./ 表示当前项目根）。
- 多个 PSR-4 规则可以共存，Composer 会按顺序匹配，但不支持重叠前缀（如
"App\\"和"App\\Controller\\"同时存在时，后者会被前者覆盖） - 路径必须真实存在，且目录内 PHP 文件需严格遵循命名约定（
App\Controller\HomeController→src/Controller/HomeController.php） - 不要在 namespace 值末尾加
\，Composer 会自动处理；但路径值末尾必须有/
{
"autoload": {
"psr-4": {
"App\\": "src/",
"Tests\\": "tests/",
"Vendor\\Package\\": "lib/vendor-package/"
}
}
}
Classmap 映射：显式声明类文件路径（无视命名空间结构）
当类不遵循 PSR-4 规范（比如旧代码、全局函数文件、或命名空间与路径不一致），用 classmap 更可靠。它只做“类名 → 文件路径”的静态映射，Composer 会扫描指定目录或列出具体文件。
- 支持数组形式列出文件路径，也支持字符串形式指定目录（Composer 会递归扫描其中所有
.php文件并建立映射） - classmap 和 psr-4 可同时存在，Composer 会合并所有映射；但 classmap 优先级低于 PSR-4 —— 如果一个类既匹配 PSR-4 规则又被 classmap 包含，仍走 PSR-4 加载逻辑
- 运行
composer dump-autoload才能更新 classmap 缓存，新增文件不会自动生效
{
"autoload": {
"psr-4": {
"App\\": "src/"
},
"classmap": [
"legacy/functions.php",
"old-lib/"
]
}
}
Autoload-dev 专用于测试代码，不影响生产环境
测试类（如 PHPUnit 测试用例）不应进入生产 autoload，否则增加内存开销且可能暴露敏感路径。用 autoload-dev 单独定义开发依赖的映射。
-
autoload-dev的结构和语法与autoload完全一致，支持psr-4、classmap、甚至files - 只有执行
composer install --dev或默认安装时才会启用；生产部署加--no-dev后，这些映射完全不加载 - 常见错误：把
Tests\\放在主autoload下，导致测试类被生产代码意外引用
{
"autoload": {
"psr-4": {
"App\\": "src/"
}
},
"autoload-dev": {
"psr-4": {
"Tests\\": "tests/"
}
}
}
运行时冲突与调试技巧
类找不到（Class not found）往往不是配置写错，而是路径未生效或缓存未更新。Composer 不会在每次请求时重新解析 composer.json，所有映射都固化在 vendor/autoload.php 和 vendor/composer/autoload_*.php 中。
- 修改
composer.json后必须运行composer dump-autoload（或composer install/update）才能使新规则生效 - 用
composer show -p查看当前已加载的 autoloader 映射列表 - 如果某个类始终不加载，检查是否被
exclude-from-classmap排除，或是否在autoload-dev里却试图在生产环境使用 - PSR-4 路径若指向软链接目录，某些系统（尤其是 Windows + WSL 混合环境）可能出现路径解析失败
多个命名空间映射本身很简单，真正容易出问题的是路径真实性、缓存状态、以及 dev 与 prod 环境的加载边界——这些细节不验证，光写对 JSON 格式也没用。
