微服务公共组件必须打包为独立 Composer 包，不能直接 require 本地目录
微服务之间共享的 DTO、接口、Client 等代码，如果还放在主项目 src/ 下或用相对路径 require，上线后必然报错——CI/CD 构建时 vendor 是从远程拉的，不是软链接。你改了 src/common/Contract.php，对 user-service 容器里的运行时毫无影响。
- 每个公共组件必须有自己独立的
composer.json，name全局唯一（如"myorg/contracts"），type设为"library" -
autoload.psr-4命名空间必须与name严格对齐："MyOrg\Contracts\": "src/"（注意末尾无斜杠） - 不能在包里
require框架全量依赖（如laravel/framework），只留psr/http-message这类最小契约 - 所有版本必须打语义化 tag（
v2.3.1），禁止用dev-main或宽泛约束（如"^2.0"）
私有仓库配置错一个字段，composer require 就直接报 “Could not find package”
主项目或网关的 composer.json 里，repositories 字段是私有包能被识别的唯一入口。写错位置、类型或 URL，Composer 就当它不存在。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
repositories必须是根级数组，不能嵌套在config或extra里 - Git 类型写法：
{"type": "vcs", "url": "https://git.example.com/myorg/contracts"}；Satis 类型才用"type": "package" - 若同时用 packagist.org 和私有源，必须显式加
"packagist.org": false，否则 Composer 会先公网查一遍，超时或缓存导致装错旧版 - 顺序影响解析优先级：私有源应放在
repositories数组前面
生产环境部署必须用 composer install --no-dev -o，且 composer.lock 必须提交
微服务上线后行为突变，90% 出在依赖没锁死。CI 构建时若执行 composer update，可能拉到不兼容的新版 myorg/contracts，而本地开发却一切正常。
-
composer.lock必须提交进 Git，它是可重复构建的唯一依据 - 部署命令必须是
composer install --no-dev -o：跳过composer.json解析，直接按 lock 文件安装；-o启用优化自动加载 - 禁止在生产环境执行
composer update或require，这会绕过 lock 文件 - 多阶段 Docker 构建中，依赖安装阶段必须复用同一份
composer.lock，不能让每层都重新 resolve
autoload 冲突会导致类加载失败，且错误不报具体原因
多个微服务包共用 App\ 命名空间，或 autoload 路径重叠（比如都映射到 "src/"），composer dump-autoload -o 会覆盖彼此，最终只有最后一个生效。PHP 报 Class not found，但你查遍 vendor/ 都找不到问题在哪。
- 子包绝不能写
"App\": "src/"—— 这会污染主项目和其他包的加载规则 - 每个包的命名空间必须专属：
"myorg/auth"→"MyOrg\Auth\"，大小写、下划线、分隔符全部逐字匹配 - Linux 文件系统区分大小写，PSR-4 映射却不区分，混用
MyOrg和myorg极易导致类找不到 - 验证方式：运行
composer dump-autoload -vvv，看输出里是否有多条Adding class map...覆盖同一路径
name 和 autoload.psr-4 的命名空间必须字符级一致，差一个反斜杠、多一个空格、大小写不对，都会让类加载器在运行时静默跳过——它不会报错，只是默默不加载。
