PSR-4生效需严格匹配命名空间前缀与目录路径，如"App\": "src/"对应AppHttpController→src/Http/Controller.php，注意大小写、反斜杠、相对路径及执行dump-autoload。
composer.json 里 autoload 的 psr-4 怎么写才生效
PSR-4 自动加载不是“写了就跑”，关键在命名空间前缀和目录路径的对应关系必须严格匹配。Composer 不会帮你猜路径，它只按规则机械地把 NamespaceSubClass 转成 vendor/dir/namespace/sub/class.php（小写+斜杠替换+末尾加 .php）。
实操建议：
-
"App\": "src/"表示所有以App开头的类，都去src/目录下找，比如AppHttpController→src/Http/Controller.php（注意：不是src/Http/Controller/Controller.php） - 命名空间末尾的反斜杠
必须写全，"App": "src/"和"App\": "src/"效果完全不同——前者会匹配AppSomething这种非标准命名空间，极容易误加载 - 路径必须是相对于
composer.json所在位置的相对路径，不能写成./src/或绝对路径，否则composer dump-autoload会静默失败
为什么 new AppHttpController() 报错 Class not found
最常见的原因是类文件没放在预期路径，或者文件名大小写不一致。PSR-4 对大小写敏感，Linux 下尤其致命。
常见错误现象：
- 类定义为
class UserController，但文件叫usercontroller.php→ 应该是UserController.php - 命名空间写成
appHttp（小写 a），但 autoload 配的是"App\": "src/"→ 命名空间必须完全一致，包括大小写 -
src/Http/Controller.php文件里没写namespace AppHttp;，或写了namespace AppHttpController;（多了一级）→ 类文件的 namespace 必须和 autoload 前缀 + 目录结构推导出的一致
composer dump-autoload --no-dev 有什么实际影响
这个命令只重新生成生产环境的自动加载映射，跳过 autoload-dev 里的配置。如果你把测试工具类（比如 TestsUnitExampleTest）写进了主 autoload，它就会进生产包；反之，如果误塞进 autoload-dev，生产环境 new 就直接报错。
使用场景：
- 部署时用
composer install --no-dev+composer dump-autoload --no-dev，确保 autoloader 不含任何开发专用类 -
autoload-dev只应放 PHPUnit、Mockery 等测试相关命名空间，且路径通常为tests/，别和src/混用 - 执行后检查
vendor/composer/autoload_psr4.php，确认数组里没有不该出现的键 —— 这是验证是否生效最直接的方式
PSR-4 和 classmap 混用时谁优先
PSR-4 优先级高于 classmap。Composer 查找类时，先按 PSR-4 规则尝试定位文件，找不到再查 classmap，最后 fallback 到 files。
容易踩的坑：
- 同一命名空间既配了 PSR-4 又被 classmap 扫描到（比如
"App\": ["src/", "legacy/"]配了两次），会导致类被加载两次，PHP 报Fatal error: Cannot declare class - 想临时加一个老项目里的单文件类，别往 PSR-4 里硬塞，用
"files": ["lib/old_helper.php"]更安全 —— 它只在 Composer 启动时 require 一次，不参与类查找逻辑 - PSR-4 映射路径末尾带斜杠（如
"App\": "src/"）和不带斜杠（"App\": "src"）行为不同：后者会让 Composer 在src目录本身找App.php，而不是进子目录，非常反直觉
真正麻烦的永远不是怎么配，而是改完不 dump-autoload，或者改了代码没同步更新 namespace —— 这些地方一卡就是半小时。
