扩展包的composer.json中require字段仅声明运行时必需的外部依赖，如illuminate/support，不可包含宿主框架（如laravel/framework）或开发工具（如phpunit/phpunit），应使用require-dev；需明确php及第三方库版本约束，避免*或dev-master，并优先选用轻量组件。
扩展包的composer.json里怎么写require
扩展包不是应用项目，它的require字段只声明「运行时必需的外部依赖」，不包含开发工具或测试框架。比如你写一个 Laravel 宏扩展包，它依赖illuminate/support，就必须写进require；但phpunit/phpunit只能放require-dev。
常见错误是把宿主框架（如laravel/framework）也塞进require——这会导致安装冲突，因为宿主项目已经提供该包。正确做法是用conflict或replace字段声明兼容范围，或在require中只写真正需要调用的组件（如illuminate/contracts）。
-
"require": { "php": "^8.1", "monolog/monolog": "^3.0" }—— PHP 版本和第三方库必须明确约束 - 避免使用
*或dev-master，它们会让下游用户无法锁定版本 - 如果依赖某个包的特定功能（如仅需 PSR-4 加载器），优先选轻量组件（如
psr/log而非monolog/monolog）
为什么不能在扩展包里执行composer install
扩展包本身不运行，它是被其他项目加载的。执行composer install在扩展包目录下会生成vendor，但这对宿主项目完全无效——Composer 只认项目根目录下的vendor和autoload.php。
真正起作用的是宿主项目执行composer require your-vendor/your-package时，Composer 解析你的扩展包的composer.json，把其中require声明的依赖一并拉进来，统一装进宿主项目的vendor目录。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 扩展包的
vendor是冗余的，CI 流程里应加.gitignore忽略 - 本地开发调试时，可用
composer link或path仓库方式让宿主项目直接加载未发布代码 - 测试用例里需要
autoload-dev映射，但这些路径不会被宿主项目自动识别，需手动require或靠composer dump-autoload --dev生成
autoload配置影响下游项目的类加载
扩展包的autoload字段决定它的类能否被宿主项目自动找到。PSR-4 是唯一推荐方式，且命名空间必须与包名逻辑一致。例如包名为acme/logger，就该配"Acme\Logger\": "src/"，而不是"App\"这种通用前缀。
如果用了files autoload（比如导出全局函数），要格外小心：这些文件会在宿主项目每次加载autoload.php时无条件执行，可能引发重复定义或副作用。
- 不要在
autoload.files里放有执行逻辑的脚本，只放纯函数声明 -
autoload-dev里的映射对宿主项目不可见，仅用于扩展包自身测试 - 修改
autoload后必须运行composer dump-autoload，否则新类路径不会生效
发布前必须验证require是否最小化
扩展包每多一个require，都会增加宿主项目安装失败的概率。冲突常发生在版本约束太宽（如"guzzlehttp/guzzle": "^7.0 || ^8.0"）或间接依赖爆炸（如引入symfony/console却只用了一个InputInterface）。
最有效的检查方式是新建空项目，执行composer require your-vendor/your-package，再跑composer why-not some-conflicting-package:2.0确认无硬性阻断。
- 用
composer show --tree your-vendor/your-package看实际引入了哪些传递依赖 - 生产环境部署时，宿主项目若用了
--no-dev，你的扩展包里所有require-dev都自动被跳过，这点必须提前验证 - 如果你的扩展包本身要跑测试，
require-dev里可以放心加phpunit/phpunit，但别让它泄漏到require
composer.json本质是一份契约：它告诉世界「我需要什么才能活下来」，而不是「我想装点啥」。任何多余的require、模糊的版本约束、错位的autoload，都会在别人composer require你的时候暴露出来——而且往往是在 CI 失败之后。
