Composer不管理配置文件依赖，仅通过config.platform声明PHP环境约束（如版本、扩展），无法校验memory_limit等ini值；实际配置校验需在代码中手动实现。
composer.json 中的 config 字段不管理配置文件依赖
Composer 本身不支持“配置文件作为依赖”这种概念。你无法用 require 声明一个 php.ini、.env 或 config/database.php 文件为“依赖包”。所谓“配置文件依赖”，实际是指项目运行时**依赖某些特定配置值或结构**，而这些配置往往来自外部文件。Composer 只管 PHP 包，不管文件内容。
用 platform 配置模拟 PHP 环境约束
当某个包（如 ext-gd 或 memory_limit=512M）要求特定 PHP 运行时配置时，config.platform 是唯一能被 Composer 解析并用于依赖解析的机制。它不修改环境，只告诉 Composer：“我部署的目标环境长这样”。
-
config.platform.php：声明目标 PHP 版本，影响php依赖解析 -
config.platform.ext-xxx：声明扩展存在（如ext-opcache），但不会检查 ini 值 - 对
memory_limit、upload_max_filesize等 ini 值，platform完全无能为力——Composer 不解析它们
如何让配置变更触发安装失败或警告
Composer 不校验 ini 值，但你可以把校验逻辑下沉到项目启动时。常见做法是写一个轻量检查脚本，在 index.php 或 CLI 入口处调用：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
if (ini_get('memory_limit') !== '-1' && intval(ini_get('memory_limit')) < 256 * 1024 * 1024) {
throw new RuntimeException('PHP memory_limit must be >= 256M');
}
- 这个检查不会阻止
composer install，但能防止应用在错误配置下静默失败 - 配合
composer.json的scripts字段，可加到post-install-cmd或post-update-cmd中自动运行 - 注意：
ini_get()返回的是字符串（如'128M'），需转换处理，不能直接比较数值
第三方配置包应视为普通 PHP 包，而非“配置依赖”
如果你看到类似 laravel/framework 提供 config/ 目录，或 symfony/config 提供配置加载能力，它们本质是 PHP 类库，不是“配置文件本身被依赖”。真正被 Composer 管理的是这些包里的类和接口。
- 不要试图用
composer require安装一个纯.yml配置文件仓库——它不会自动复制到你的config/目录 - 若真需共享配置结构，应封装为 PHP 包，提供
ConfigProvider接口或预设数组，由应用主动合并 - 环境配置（如
.env）必须靠部署流程管理（Docker COPY、CI 变量注入、Ansible 模板），不在 Composer 职责范围内
最易被忽略的一点：很多人以为 config.platform 能强制生效 php.ini 设置，其实它只是个“声明开关”。真正起作用的永远是运行时环境本身——Composer 不改 ini，不启扩展，不读 .env。所有配置校验必须在代码里做，且得在 autoload 加载之后、业务逻辑之前执行。
