Composer原生不支持按操作系统条件安装，如“仅Linux装ext-inotify”；需通过config.platform声明目标环境（如ext-pcntl）并依赖上游包规范声明require扩展，使依赖解析时自动过滤不兼容包。
Composer 原生不支持「只在 Linux 安装 ext-inotify」这类条件安装逻辑，composer.json 里没有 os、platform-os 或类似字段。所谓“平台限定”，实际是靠组合 platform 配置 + 上游包的 require 声明（如 "ext-pcntl": "*"）来间接实现——本质是让 Composer 在解析依赖时“假装”运行在目标平台，而非真实检测当前系统。
platform 配置怎么写才生效
platform 必须放在 composer.json 的 config 对象下，不是根级字段；它只对声明了 ext-xxx 或 lib-xxx 依赖的包起作用——如果上游包没写 "require": {"ext-posix": "*"}，platform 就完全无效。
- 写法示例（模拟 Linux 环境）：
{ "config": { "platform": { "php": "8.2.12", "ext-posix": "8.2.12", "ext-pcntl": "8.2.12", "ext-sysvsem": "8.2.12" } } } - 版本号填
"0"或"*"都可以，Composer 只校验键是否存在，不验证值 - 不能写
"php": "^8.2"—— 模糊版本会被忽略，必须是具体版本或至少"8.2" - 该配置不影响实际运行环境，只是骗过依赖求解器：你在 Windows 上执行
composer install也不会报ext-pcntl缺失
为什么 post-install-cmd 删除 vendor 不可靠
有人想用脚本判断 PHP_OS 后 rm -rf vendor/some-linux-only-package，这会破坏自动加载机制。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
vendor/autoload.php已生成，PSR-4 映射可能仍包含被删包的命名空间，导致Class not found - 若该包被其他已安装包硬依赖（比如
A → B → linux-only-package），Composer 不会在install阶段校验其存在性，但运行时必崩 - 删除后无法保证
composer dump-autoload能自动清理残留映射，尤其当包用了 classmap 或 files 加载方式
conflict 和 replace 的适用边界
如果你真要阻止某个包出现在 vendor/ 下，conflict 和 replace 是更直接的选择，但它们和平台无关，只管包名与版本。
-
"conflict": {"ext-redis": "*"}：让 Composer 解析失败，适用于明确知道某扩展会导致冲突的场景 -
"replace": {"monolog/monolog": "*"}：静默跳过安装，但要求你确实提供了兼容接口，否则运行时报错 - 二者都不解决“仅限某 OS”的问题，只是排除手段；若目标包本身没声明
ext-xxx依赖，platform就无能为力，只能靠这些补救
真正需要按操作系统差异化安装时，说明设计已超出 Composer 的语义能力——此时应把平台判断下沉到代码层，用 extension_loaded() 或 function_exists() 运行时决策，而不是强求安装阶段就隔离。
