开发扩展包时Composer依赖如何配置-composer-PHP中文网

require必须仅包含运行时实际执行的依赖，判断标准是php是否new/use/include该包代码；版本约束优先用"^7.0"，禁用""和"dev-main"；ext-扩展名须写全，php版本必须显式声明。

开发扩展包时composer依赖如何配置

扩展包的 require 必须只写运行时真正被加载执行的依赖，否则下游项目 install 时会多装、白占空间、甚至引发冲突。

require 里该放什么：看类是否在运行期被 new/use/include

你写的扩展包（比如 myorg/http-client）如果在构造函数里 new 了 GuzzleHttpClient，或者在某个方法里 use GuzzleHttpRequestOptions，那 guzzlehttp/guzzle 就必须进 require。

反之，如果只是在 tests/ 里用 phpunit/phpunit 写测试，或在 bin/check-cs.php 里调用 php-cs-fixer，这些都属于开发时工具链，只能放 require-dev。

该放：psr/log（接口，你的 LoggerInterface 实现要运行）、symfony/polyfill-mbstring（补丁类，代码里真调用了 mb_strlen()）
不该放：phpstan/phpstan（静态分析不参与运行）、friendsofphp/php-cs-fixer（格式化命令行工具）、roave/security-advisories（CI 检查用）
特别注意：ext-* 扩展名要写对，比如 ext-json 不是 json，ext-openssl 不是 openssl —— 写错会导致 Composer 认为“满足”，但运行时报 Call to undefined function json_encode()

版本约束别贪大，优先用 ^，禁用 dev-main 和 *

扩展包的依赖版本必须兼顾向下兼容和可预测性。用 "^7.0" 表示允许 7.x 全系列，但不会升到 8.0；而 "7.*" 理论上也只走 7.x，但某些 patch 版本可能含破坏性变更（尤其非语义化版本的包），风险略高。

"*" 和 "dev-main" 是发布包的大忌：前者让下游项目每次 composer update 都可能拉到不兼容版本；后者在 --no-dev 场景下直接失败，且 Packagist 拒绝收录带 dev- 约束的稳定版。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

查真实版本：运行 composer show guzzlehttp/guzzle --all，别猜 ^7.0 能不能覆盖 7.5.1
PHP 版本必须显式声明："php": "^8.0"，不能省略——否则别人 PHP 7.4 上 composer require myorg/http-client 成功，一运行就 Fatal error: Typed property must not be accessed before initialization
避免写 "monolog/monolog": "2.0"：这是 exact 版本，Composer 会拒绝安装（因为 Packagist 上没有叫 2.0 的 tag，只有 2.0.0）

autoload 配置要精简，别把 tests/src 全扫进去

扩展包自身的自动加载规则，只应覆盖实际对外暴露的类路径。比如你提供的是 MyOrgHttpClientClient，那就只映射 "MyOrg\HttpClient\": "src/"；tests/、examples/、bin/ 这些目录绝不能出现在 autoload.psr-4 里。

否则下游项目 composer dump-autoload --optimize 时，会把你的测试类也编进 classmap，既增大 autoload 文件体积，又可能因命名冲突导致 Class MyOrgHttpClientTestHelper already exists。

推荐结构：

{
  "autoload": {
    "psr-4": {
      "MyOrg\HttpClient\": "src/"
    }
  },
  "autoload-dev": {
    "psr-4": {
      "MyOrg\HttpClient\Tests\": "tests/"
    }
  }
}

autoload-dev 不会被下游项目加载，只在你本地跑 composer install 时生效，不影响使用者
如果用了 classmap，确保路径不含 vendor/ 或 node_modules/ —— Composer 会静默跳过，但你可能以为它扫进去了

vendor-dir 改不了，别试图绕开 vendor/

扩展包的 composer.json 里写 "config": {"vendor-dir": "libs"} 是无效的。这个配置只在首次 composer install 且 vendor/ 不存在时起作用；一旦已有 vendor/ 目录，Composer 彻底忽略它。

更关键的是，所有生态工具（IDE、PHPStan、Psalm、Docker 构建脚本、CI 中的 phpunit 命令）都硬编码引用 vendor/autoload.php。你强行改路径，结果不是“找不到包”，而是 Class not found 或 Command not found，且错误信息完全不提示路径问题。

想验证？删掉 vendor/，改 composer.json 的 config.vendor-dir，再 composer install —— 你会发现 vendor/autoload.php 依然存在，只是内容指向了新路径下的 autoload 文件，但 IDE 仍去旧路径找
COMPOSER_VENDOR_DIR 环境变量在 CI 中常被忽略，尤其使用 GitHub Actions 的 setup-php action 时，它会重置该变量
唯一安全做法：接受 vendor/ 是事实标准，所有路径引用都基于它写死

最易被忽略的一点：扩展包的 require 里写了 illuminate/support，不代表下游 Laravel 项目就能直接用 —— 如果对方用的是 Laravel 10，而你锁了 "illuminate/support": "^9.0"，composer require 会直接失败。扩展包的依赖版本，本质是给下游划出一条兼容边界，不是“我用啥就写啥”。