require必须仅包含运行时实际执行的依赖，判断标准是PHP是否new/use/include该包代码；版本约束优先用"^7.0"，禁用""和"dev-main"；ext-扩展名须写全，PHP版本必须显式声明。
扩展包的 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）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “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-phpaction 时，它会重置该变量 - 唯一安全做法：接受
vendor/是事实标准，所有路径引用都基于它写死
最易被忽略的一点：扩展包的 require 里写了 illuminate/support，不代表下游 Laravel 项目就能直接用 —— 如果对方用的是 Laravel 10，而你锁了 "illuminate/support": "^9.0"，composer require 会直接失败。扩展包的依赖版本，本质是给下游划出一条兼容边界，不是“我用啥就写啥”。
