Composer通过psr-4多路径数组、classmap兜底及autoload-dev隔离实现灵活自动加载：psr-4允许多目录按序查找，classmap优先级更高且支持非标准类，autoload-dev专管测试路径，均需正确配置斜杠与结构并执行dump-autoload生效。
Composer 不能直接给一个命名空间“追加”路径，但能通过合法结构实现多路径查找——关键不是堆砌路径，而是选对 autoload 类型并按规则组织。
psr-4 中为同一命名空间配置多个源目录
这是最常用、也最符合直觉的方式：Composer 会按数组顺序依次尝试每个路径，找到第一个存在的文件就停止加载。
- 必须把路径写成数组形式：
"App": ["src/", "shared/src/", "stubs/"]，写成对象（"App": "src/"）只认最后一个 - 所有路径都需真实存在，
composer dump-autoload时会校验，缺失任一目录会报错退出 - 路径顺序决定优先级：开发主代码放前面，共享库或 stub 放后面，避免被意外覆盖
- 注意目录结构一致性：比如
AppFooBar在shared/src/下必须是shared/src/Foo/Bar.php，不是shared/src/App/Foo/Bar.php
classmap 作为 psr-4 的兜底补充
当某些类不守 PSR-4 规则（比如无命名空间、类名和文件名不一致、扁平目录），用 classmap 显式登记更可靠，且它比 psr-4 优先级高。
-
classmap值必须是路径数组，支持目录（递归扫描）或具体文件（如"legacy/helpers.php"） - 新增类后必须重新运行
composer dump-autoload，否则不会生效 - 可用来覆盖 psr-4 的模糊匹配：例如
AppLegacyHelper在legacy/下是LegacyHelper.php，而 psr-4 期望它是legacy/LegacyHelper.php—— 此时 classmap 能绕过结构限制 - 不要把整个
src/加进 classmap：它会破坏命名空间语义，且生成的映射表体积大、启动慢
autoload-dev 里放测试相关路径，别污染生产环境
测试类（如 TestsUnitFooTest）不该在生产环境被加载，也不该和主逻辑混在同一个 psr-4 规则里。
- 用
autoload-dev字段单独定义测试命名空间："Tests\": ["tests/", "vendor/myorg/test-helpers/src/"] - 运行
composer install --no-dev或composer dump-autoload --no-dev时，这些路径自动被排除 - 不要把
tests/加进主autoload.psr-4：否则TestsFoo可能在生产环境被意外实例化，引发未定义行为 - 如果测试工具（如 Pest）依赖特定函数文件，用
autoload-dev.files加载，而非autoload.files
验证是否生效：别只信 composer.json
改完配置不等于生效，必须检查实际生成的映射文件，尤其是遇到 Class not found 时。
- 运行
composer dump-autoload -o后，打开vendor/composer/autoload_psr4.php，确认App对应的是你预期的数组，不是单个字符串 - 如果用了
classmap，检查vendor/composer/autoload_classmap.php是否包含你要的类名 → 文件路径对 -
vendor/下包的 autoload 完全独立于你的配置，它们不会被你的 psr-4 覆盖，也不会影响你的路径查找顺序 - 最隐蔽的坑：路径末尾斜杠。写成
"src"和"src/"在部分系统下行为不一致，统一用带斜杠形式
