name字段必须为小写vendor/name格式，否则composer install直接失败；它决定vendor目录结构、PSR-4命名空间映射及依赖解析，填错将导致类无法加载。

composer.json 的 name 字段为什么不能随便写

它不是“项目名”那么简单，而是 Composer 依赖解析和自动加载的锚点。填错直接导致 composer install 失败，或类根本加载不了。

• name 必须是 vendor/name 格式，全部小写，只允许短横线（-）和数字，比如 acme/http-client；ACME/HttpClient、acme_http_client、myapp 全部非法
• vendor 名实际决定了 vendor/ 下的首级目录名：填 acme/http-client，包就解压到 vendor/acme/http-client，大小写错一个字母，路径就断了
• 如果只是本地项目不发包，也得按规则填，否则 composer validate 过不去，IDE 和 PHPStan 也无法正确识别命名空间根

autoload 配置写错，为什么 new 类时还报 Class not found

PSR-4 映射不是“写了就生效”，它和目录结构、命名空间声明三者必须严丝合缝，缺一不可。

Pandas 配置文件报告生成器

使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。

下载

• "App\": "src/" 表示：所有以 App 开头的类，都从 src/ 下找；那么 src/Service/Logger.php 里必须声明 namespace AppService;，而不是 namespace App; 或 namespace Service;
• 漏掉命名空间末尾的反斜杠——写成 "App": "src/" ——会导致 Composer 完全忽略这条映射
• 改了 autoload 后不运行 composer dump-autoload，旧的映射还在 vendor/composer/autoload_psr4.php 里，类当然找不到
• 验证是否生效：执行 composer show -s，看输出里有没有你配的前缀；再手动 new AppServiceLogger() 测试

require 和 require-dev 混用会出什么问题

边界不清最常在 CI 环境暴雷，不是报错，而是行为不一致——线上跑着跑着突然 Class not found 或方法不存在。

• require 是运行时必需：只要代码里 new MonologLogger() 或 use 了某个类，它就必须在这里
• require-dev 只用于开发链路：测试（phpunit）、静态分析（phpstan）、代码格式化（php-cs-fixer）——它们不该出现在生产环境
• 陷阱：某个 require-dev 包（比如 symfony/var-dumper）间接拉入了新版 symfony/polyfill，而 require 里锁的老版本不兼容，composer install --no-dev 时可能因锁文件冲突失败
• 排查方式：CI 中加一步 composer install --no-dev --dry-run，提前暴露冲突；线上部署后用 composer show 确认没多装 dev 包

vendor-dir 改了为什么很多工具都失效

不是配置没生效，而是整个生态默认绑死了 vendor/ 这个路径——改它等于动 ABI。

• "config": {"vendor-dir": "libs"} 只在 vendor/ 目录**不存在时**才起作用；已有 vendor/，Composer 就彻底无视这个配置
• IDE、PHPStan、Psalm、Dockerfile、vendor/bin/phpunit 内部脚本……全都硬编码引用 vendor/autoload.php 或 vendor/bin/，路径一变，Class not found 或 Command not found 接踵而至，错误信息却不提示“路径错了”
• 真要换路径？先 rm -rf vendor，再改 composer.json，再 composer install；但 CI 中用 COMPOSER_VENDOR_DIR 环境变量大概率静默失败，尤其容器环境

真正卡住人的，从来不是字段名记不住，而是 name 和 autoload 这两个字段如何联动落地——它们共同决定了类文件在磁盘上怎么放、运行时怎么找。路径和命名空间之间那条线，稍有偏移，报错就来得又快又沉默。