name字段是包的唯一标识，必须为全小写、短横线分隔的vendor/name格式（如laravel/framework），含大写、下划线、点号或缺斜杠均导致composer install报错中断。
composer.json 里 name 字段为什么不能随便写
它不是“项目名”或“显示名”，而是 Composer 识别和发布包的唯一标识，必须严格满足 vendor/name 格式：全小写、用短横线（-）分隔单词、中间一个斜杠。比如 laravel/framework 或 myorg/my-cli-tool。
常见错误包括：MyPackage（含大写）、my_package（含下划线）、123app（数字开头）、my.org（含点号）。一旦写错，composer install 会直接报 Invalid package name 并中断。
本地测试也得守规则——哪怕不发包，composer validate 通不过，很多命令（如 create-project）就跑不起来。
autoload 中 psr-4 和 classmap 混用时谁优先
classmap 条目在自动加载链中优先级更高。Composer 生成的 autoload_classmap.php 会把所有 classmap 扫描结果提前固化，运行时先查这张表；查不到才 fallback 到 psr-4 映射路径去文件系统找。
这意味着：如果同一个类名既出现在 classmap 扫描目录里，又符合 psr-4 规则，最终加载的是 classmap 对应的那个文件。
注意事项：
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
-
psr-4的命名空间映射末尾必须带反斜杠，例如"App\": "src/"，漏掉就解析失败 -
classmap指向目录后，新增或删改 PHP 文件不会自动更新映射，必须手动执行composer dump-autoload - 改完 autoload 配置不跑
dump-autoload，等于没改——install或update不触发重生成
config 节点里哪些参数影响生产环境性能
真正对线上性能起作用的不是“看起来高级”的选项，而是三个常被忽略的硬开关：
-
"process-timeout": 900：防止网络抖动导致命令卡死，默认 300 秒太短，CI 或低带宽环境容易失败 -
"optimize-autoloader": true：生成vendor/composer/autoload_classmap.php，跳过运行时遍历目录 -
"classmap-authoritative": true：让 autoloader 完全信任 classmap，不再调用file_exists()去 PSR-4 路径试探——这对挂载 volume 的 Docker 容器尤其关键
这两个 autoloader 参数必须配合使用才生效，且要求项目中所有类都能被扫描到（不能靠 require_once 动态加载）。验证方式：检查 autoload_classmap.php 是否非空，并确认 autoload_real.php 里有 $classMapAuthoritative = true。
repositories 和全局镜像配置谁管用
优先级是硬编码的：repositories（项目级） > 全局 repo.packagist > 默认源。只要 composer.json 里存在 "repositories" 字段（哪怕值是空对象 {} 或空数组 []），全局镜像就完全失效。
典型踩坑场景：
- 执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（漏-g）→ 实际写进"config": { "repo.packagist": ... }，但该字段对源无效，Composer 直接无视 - 项目已有私有源，再用项目级命令配镜像 → 整个
repositories字段被覆盖，私有源丢失 - CI 环境（如 GitHub Actions）或宝塔后台（www 用户）默认走项目级配置更可靠，因为全局配置路径可能因用户权限或
$COMPOSER_HOME设置而不可靠
验证全局镜像是否真生效，只认这一条命令输出：composer config -g repo.packagist 必须返回完整 JSON，如 {"type":"composer","url":"https://mirrors.aliyun.com/composer/"}；输出空、null 或报错，说明根本没写进去。
