Composer 不支持运行时动态替换依赖包，所有替换仅发生在 install/update 阶段；“中文插件”等需求应通过接口抽象+运行时加载器实现，而非依赖 Composer 的 replace 或 repositories。
Composer 本身不支持运行时动态替换依赖包——它没有插件系统、不参与运行时加载，所有“替换”都发生在 install/update 阶段的静态解析中。 你想要的“中文插件”“运行时切换”，本质是混淆了依赖管理与运行时插件机制的边界。真正能落地的方案，必须绕开 Composer 的限制，用它做“打包器”，而不是“调度器”。
composer.json 的 replace 不是运行时开关
很多人以为在 replace 字段里写上 {"old-package": "*"} 就能让旧包“自动消失”或“被新包接管”。事实是：
• 它只影响下一次 composer install 或 composer update 的依赖图计算
• 已安装的 old-package 不会自动卸载，必须手动 composer remove old-package
• 类加载路径不会继承，你得自己在自己的 composer.json 中完整复制原包的 autoload 规则
• 如果其他已安装包仍 require old-package，Composer 依然会把它拉回来——replace 不等于 conflict
所谓“中文插件”，其实是独立包 + 运行时加载器
如果你真要实现“按配置启用某套支付 SDK”“根据语言切换日志格式实现”，别碰 replace 或 repositories 做 hack。正确路径是：
• 抽出统一接口，比如 YourOrg\Payment\GatewayInterface
• 每个具体实现（微信、支付宝、银联）作为独立包发布，各自有 composer.json 和 autoload
• 主项目只 require 抽象契约和一个轻量加载器（如 your-org/middleware-loader）
• 运行时读取配置（如 config/payment.php），用反射或工厂类实例化对应实现
• Composer 只负责把所有实现包下载到 vendor/，不参与激活逻辑
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
想让不同环境装不同包？别改 composer.json，改安装命令
试图用环境变量注入版本号（如 "ext-xdebug": "${XDEBUG_VER}"）会直接导致 JSON 解析失败，报错信息通常是 Invalid argument supplied for foreach()。
可行做法只有：
• 用 --no-dev 精确控制 require-dev 是否安装（生产必须加）
• 用 COMPOSER_PLATFORM_CHECK=0 关闭扩展校验，配合 config.platform 在开发时“假装”有 xdebug 或 memcached
• 对于完全互斥的包（比如 dev 用 monolog/monolog，prod 用自研 SaaS 日志 SDK），拆成两个子项目（myapp/dev-deps 和 myapp/prod-deps），通过 repositories.type: path 引入，并由 CI 脚本决定用哪个
最容易被忽略的点：所有“动态”需求，最终都落在运行时代码里——不是靠 Composer 写几行 JSON 实现的。它生成的 vendor/autoload.php 是静态文件，一旦生成，就和安装时的 PHP 版本、扩展、平台配置强绑定。任何试图在部署后“热替换”依赖的行为，都会破坏 autoload 缓存、触发类未找到错误，或者让 composer.lock 失去可信性。
