PSR-4是PHP现行自动加载标准，通过命名空间前缀映射文件路径，取代已废弃的PSR-0；Composer自1.0起仅支持PSR-4，配置需在composer.json中正确书写"psr-4"并执行dump-autoload生效。
PSR-0 已废弃，项目中必须用 PSR-4；Composer 默认只支持 PSR-4，强行配 PSR-0 会触发警告且未来彻底失效。
PSR-4 是什么，为什么现在只能用它
PSR-4 是 PHP 自动加载的现行标准，它把命名空间（namespace）和文件路径做**前缀映射**，不依赖类名中的下划线或固定层级。而 PSR-0 要求类名中每段下划线都对应目录分隔符（比如 Vendor_Lib_Class → Vendor/Lib/Class.php），早已被 PHP-FIG 在 2014 年正式弃用。
Composer 自 1.0 起就默认只读取 psr-4 配置；如果你在 composer.json 里写 psr-0，执行 composer dump-autoload 时会看到：Warning: The "psr-0" autoloading specification is deprecated and will be removed in a future Composer version.
- PSR-4 映射更灵活：允许一个命名空间前缀对应多个物理路径
- 类文件名不再强制首字母大写（PSR-0 要求
Foo_Bar类必须叫Foo_Bar.php） - 没有“空子命名空间”歧义问题（PSR-0 对
根命名空间处理模糊）
如何正确配置 composer.json 的 psr-4
核心是写对 "autoload": { "psr-4": { ... } } 这一段。键是命名空间前缀（含结尾反斜杠），值是相对于项目根目录的源码路径（可为数组）。
常见错误配置：
- 漏掉命名空间末尾的
：写成"App": "src/"是错的，必须是"App\": "src/"（JSON 中双反斜杠表示单个） - 路径没加引号或用了绝对路径：
"App\": /var/www/src/会解析失败 - 多个命名空间共用同一路径时，没用数组：应写
"App\": ["src/", "tests/fixtures/"]
正确示例：
{
"autoload": {
"psr-4": {
"App\": "src/",
"Tests\": "tests/"
}
}
}
之后运行 composer dump-autoload 生效。注意：修改后不执行这步，自动加载不会更新。
PSR-4 和文件结构的对应关系
命名空间前缀 + 剩余部分 = 相对路径。比如配置了 "App\": "src/"，那么：
-
AppFooBar→src/Foo/Bar.php -
AppModelsUser→src/Models/User.php -
App（无后续）→src/下的App.php（极少用，不推荐）
关键点：
- 路径中不区分大小写，但类文件名必须严格匹配类名（PHP 区分大小写）
- 子命名空间层级必须与目录层级完全一致，不能跳级或错位
-
src/下不能有App/子目录——那会导致重复嵌套（src/App/Foo/Bar.php对应的是AppAppFooBar）
什么时候要手动调用 dump-autoload，以及 autoload_static.php 的作用
只要改了 composer.json 中的 autoload 配置，或新增/删减了类文件但没跑 composer install/update，就必须手动执行 composer dump-autoload。否则新类找不到。
执行后，Composer 会生成 vendor/composer/autoload_static.php，它是一个预编译的静态映射表，比动态扫描快得多。这个文件内容由配置实时生成，不可手改。
容易忽略的细节：
- 开发中启用了
classmap或files加载方式，也要一起重新 dump - 如果项目用了
optimize-autoloader（如生产环境加-o参数），生成的是更紧凑的autoload_classmap.php，此时 PSR-4 映射会被扁平化，调试时反而难追踪路径 - IDE（如 PhpStorm）可能缓存旧的命名空间映射，改完配置后需重启索引
最常出问题的地方不是写错语法，而是路径和命名空间的层级对不齐，或者忘了执行 dump-autoload —— 这两个动作必须成对出现。
