如何在Composer中理解配置文件常用参数-composer-PHP中文网

config字段控制composer自身行为，如vendor目录位置、超时时间、安装方式、插件启用等，不管理依赖或自动加载；其与require、autoload同级，repositories是独立顶层字段而非config子项。

如何在composer中理解配置文件常用参数

composer.json 的 config 字段控制什么

它不管理依赖或自动加载，只影响 Composer 自身行为：比如安装路径、超时时间、缓存策略、是否启用插件等。这些参数写在 config 对象里，和 require、autoload 同级。

常见错误是把仓库源（repositories）也塞进 config 里——它不属于 config，而是一个独立顶层字段，且结构必须是对象（不是数组）。

vendor-dir：指定 vendor/ 目录位置，比如 "vendor-dir": "lib/vendor"；改完要删掉旧 vendor/ 再 composer install
process-timeout：默认 300 秒，国内网络建议设为 900 或更高，否则 composer update 容易中断
preferred-install：控制包是下载 zip（dist）还是克隆 git（source），"*": "dist" 是最常用写法
allow-plugins：Composer 2.2+ 强制要求显式声明可运行的插件，{"phpstan/extension-installer": true} 这类必须列出来，否则报错

repositories 字段为什么总配不对

因为它的结构在 Composer 2.0+ 被严格限定：必须是对象，键名必须是 packagist.org（不能是 packagist、repo.packagist 或其他变体），值必须是带 type 和 url 的对象。

错误示例："repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}] —— 数组写法在新版中完全被忽略，不报错也不生效。

Pandas 配置文件报告生成器

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

下载

正确写法："repositories": {"packagist.org": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}}
url 必须以 / 结尾，否则请求 /packages.json 会变成 /packages.json 拼接失败，返回 404 后静默回退官方源
项目级配置优先级高于全局，只要 composer.json 里有 repositories 字段，composer config -g repo.packagist 就完全不起作用
已有私有源？别用 composer config repo.packagist 覆盖整个 repositories，得手动合并 JSON，保留原有条目

autoload 中 psr-4 和 classmap 的实际优先级

classmap 条目在自动加载时优先于 psr-4，哪怕同一个类名同时存在于两个路径下，也会加载 classmap 指向的那个文件。

这容易导致“类明明改了却没生效”的问题——你以为改的是 PSR-4 映射的类，结果 autoloader 加载的是 classmap 缓存里的旧版本。

psr-4 映射必须以结尾，例如 "App\": "src/"，漏掉反斜杠会导致命名空间解析失败
classmap 可以指向目录或单个文件，但不会自动感知增删改，每次变动后必须手动运行 composer dump-autoload
混用时，PSR-4 匹配失败才会 fallback 到 classmap，所以 classmap 不是“兜底”，而是“抢跑”
验证是否生效，不要只看 composer install 成功与否，要用 composer dump-autoload -o 后实际 new 一个类来测

require-dev 导致 CI 构建失败的真实原因

不是因为 dev 包本身有问题，而是它可能间接拉入与 require 中同名但主版本冲突的依赖（比如 phpunit/phpunit 依赖 symfony/console:^6，而项目 require 了 symfony/console:^5）。锁文件里会残留这种冲突约束，CI 执行 composer install --no-dev 时反而无法满足。

这类问题在本地不暴露，因为开发时 --no-dev 没开，冲突被掩盖了。

排查命令：composer why-not symfony/console:6.0 看谁在阻止升级
CI 流水线必须加 --no-dev --prefer-dist，避免本地 vendor 状态污染构建结果
别在 require-dev 里放运行时敏感包（如 laravel/framework、doctrine/orm），它们可能改变核心行为
如果必须用，考虑用 config.platform 伪报 PHP 或扩展版本，让 Composer 解析时绕过某些不兼容路径

实际改配置时最容易被忽略的点：所有修改都必须配合对应操作才生效——改了 autoload 就得 dump-autoload，改了 repositories 就得 clear-cache && rm -rf vendor composer.lock && install，光改文件不触发重建，等于没改。