第三方库的 autoload 配置写在你自己的项目根目录下的 composer.json 里，不是第三方库自己的；composer 只读取当前项目的 autoload 字段，第三方库若未规范配置则需用 classmap 或 files 在本项目中手动补救。
第三方库的 autoload 配置写在谁的 composer.json 里
写在你自己的项目根目录下的 composer.json，不是第三方库自己的。Composer 只读取当前项目的 composer.json 中的 autoload 字段，来决定哪些类或文件该被自动加载。
常见误解是去改第三方库源码里的 composer.json —— 这毫无意义，因为 Composer 不会加载 vendor 目录下其他包的 autoload 配置（除非它被声明为你的依赖并已安装）。
- 你只需关心自己项目的
composer.json - 第三方库若本身遵循 PSR-4，它的 autoload 规则已在它自己的
composer.json中定义，并由 Composer 在安装时自动合并进你的加载器 - 只有当第三方库「没配 autoload」或「结构不规范」时，才需要你在自己的配置里手动补救
classmap 和 files 哪种更适合非标准第三方库
看第三方库的形态：如果它是一堆散装 PHP 类文件（无命名空间、文件名不等于类名），用 classmap；如果它只提供几个全局函数或一个初始化脚本（比如 init.php 或 helpers.php），用 files。
classmap 会扫描目录下所有 .php 文件，提取其中的 class、interface、trait 声明，生成硬映射；files 则是启动时无条件 require_once 每个路径。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
-
classmap示例："classmap": ["vendor/legacy-sdk/src/"]—— 适合老式 Zend Framework 1 风格的库 -
files示例："files": ["vendor/paypal/sdk/init.php"]—— 适合必须先执行初始化逻辑的 SDK - 两者不能混用同一用途：不要用
files去加载类文件，否则可能因加载顺序导致Class not found
为什么 dump-autoload 后还是找不到类或函数
最常踩的坑不是配置错，而是路径没生效或加载时机不对。运行 composer dump-autoload 只是生成映射文件，不保证运行时能访问到。
- 路径必须相对于
composer.json所在目录，不能以./开头，也不能写绝对路径 - 确保文件真实存在，且扩展名是
.php（init.inc或config.php5不会被识别） - 测试环境里，确认
phpunit.xml的bootstrap属性指向了vendor/autoload.php，而不是漏掉或指向了错误路径 - 如果第三方库依赖框架服务（如 Laravel 的
app()），而你把它塞进files，就会在容器初始化前就执行，报Call to function app() on null
PSR-4 映射第三方库目录时要注意什么
PSR-4 要求命名空间前缀与目录严格对应，且类文件名必须和类名一致。强行映射一个不守规的第三方库，只会让自动加载失效。
例如，你想把 vendor/aliyun/oss-sdk 映射成 Aliyun\Oss\，但它的实际类文件放在 src/OSS/OssClient.php，而类名是 OSSOssClient —— 这时你应该映射 "Aliyun\Oss\": "vendor/aliyun/oss-sdk/src/"，而不是试图“重命名”命名空间。
- 优先查第三方库文档：它是否声明了官方命名空间？有没有
autoload字段？ - 如果它没声明，别硬套 PSR-4；改用
classmap更稳妥 - 多个第三方库共用同一命名空间前缀时，Composer 会按
composer.json中定义的顺序合并，后定义的覆盖先定义的 —— 这点容易引发静默冲突
真正麻烦的从来不是写几行 JSON，而是第三方库本身没按规范组织代码，又不肯改。这时候 classmap 是兜底方案，files 是前置钩子，而 PSR-4 是理想状态 —— 选哪个，取决于你愿不愿意为兼容性多花十分钟排查路径和命名空间对不上。
