需在 composer.json 的 autoload 字段中按类型配置：PSR- 4 映射命名空间到目录（如 ”App\”: “app/”），classmap 扫描无命名空间文件（推荐指定 ”lib/”, “legacy/” 等路径），files 引入全局函数文件；注意排除 vendor/tests 等目录，修改后执行 composer dump-autoload - o 并验证。
composer.json 里怎么写 autoload 配置才能支持非标准目录
Composer 默认只认 src/ 下的 PSR-4 类，但你项目里可能有 app/Models、lib/Utils 或甚至 legacy/ 这种老结构。这时候不能硬改目录，得靠 autoload 字段灵活映射。
关键不是“能不能”，而是选对类型：psr-4 适合命名空间明确的现代代码；psr-0 已废弃，别碰；classmap 适合无命名空间的老代码；files 适合全局函数或常量文件。
-
psr-4：映射命名空间到目录，路径末尾必须带/，比如"App\": "app/"表示AppUser对应app/User.php -
classmap：指定目录或文件列表，Composer 会静态扫描并生成类名 → 文件路径的映射表，适合legacy/或includes/这类无命名空间的 PHP 文件 -
files：列出需每次加载的 PHP 文件，比如helpers.php或constants.php，它们不定义类，只执行逻辑
classmap 扫描时忽略 vendor 和测试目录的正确写法
用 classmap 时如果直接写 "classmap": ["."]，Composer 会把 vendor/、tests/ 全扫进去，导致 autoload_classmap.php 膨胀、加载变慢，甚至引发命名冲突。
必须显式排除无关路径，且注意：classmap 不支持通配符，只能列具体路径或文件。
- 推荐写法是分目录声明：
"classmap": ["lib/", "legacy/", "config/"]，不扫根目录 - 若必须扫整个项目但排除某些目录，得用
exclude-from-classmap字段，例如：{"autoload": { "classmap": ["."] }, "exclude-from-classmap": ["vendor/", "tests/", "node_modules/"] } - 运行
composer dump-autoload -o后检查vendor/composer/autoload_classmap.php，确认没混入意外路径
PSR-4 映射多个命名空间到同一目录的坑
有人想让 AppModels 和 AppControllers 都指向 app/，于是写成："AppModels": "app/", "AppControllers": "app/" —— 这会导致 AppModelsUser 去找 app/Models/User.php，但实际文件可能在 app/User.php，结果找不到。
根本问题在于 PSR-4 是“命名空间前缀 → 目录”的严格映射，不是“目录 → 多个命名空间”。要解决这类情况：
- 要么拆目录，按标准结构放：
app/Models/User.php对应AppModelsUser - 要么改用
classmap，直接扫描app/下所有 PHP 文件，不依赖命名空间路径 - 或者用
files+ 手动require，适合极少量核心类（不推荐大规模用）
修改 autoload 后 composer dump-autoload 不生效？检查这三点
改完 composer.json 的 autoload 配置后，composer dump-autoload 没反应，或新类还是报 Class not found，大概率是以下原因：
- 忘记加
-o（optimize）参数：非优化模式下，PSR-4 映射不会写入autoload_static.php，开发时可能凑合，但部署或 CLI 环境容易失效 - 缓存没清干净：删掉
vendor/composer/autoload_*.php文件，再重跑composer dump-autoload -o - 命名空间声明和文件路径不匹配：比如文件
app/User.php里写了namespace App;，但 autoload 写的是"App\Models\": "app/"，那new User()就会失败——因为类名全称是AppUser，不是AppModelsUser
最稳妥的验证方式：在终端运行 composer show -s，看输出里是否列出你新增的映射；再用 composer dump-autoload -vvv 观察扫描过程有没有报错或跳过目录。
