根本原因是未显式禁用packagist.org，默认源优先导致私有包不被匹配；必须在repositories同级添加"packagist.org": false，仓库type须为composer，url末尾斜杠不可省略。
私有仓库本身不“搭建商城系统”，它只解决模块复用与依赖隔离问题；真正要搭商城，得先拆出订单、支付、商品、用户等可独立发布的包，再通过 composer.json 的 require 显式声明依赖关系——否则所有模块仍会耦合在单体项目里。
为什么 composer install 后 vendor 里没出现你的私有包
根本不是 Git 地址写错或权限没配好，而是 Composer 根本没去你配的私有源查包。默认行为是：先连 packagist.org，404 后才 fallback 到 repositories 列表。哪怕你写了 Artifactory 或 Satis 地址，只要没关掉默认源，私有包就永远不会被匹配。
- 必须在项目级
composer.json中添加"packagist.org": false这一行，放在repositories同级（不是里面） -
repositories数组中每个源的type必须是"composer"，VCS 类型（如"vcs"）只用于源发现，不能当仓库用 - Satis 生成的仓库 URL 必须以
/结尾，比如https://packages.internal/，少斜杠会返回 404，Composer 静默回退到 packagist - 若用 Artifactory，仓库类型必须选
composer（不是 Generic 或 Remote），且虚拟仓库后端至少挂一个type: composer的本地/远程源
如何让订单模块和支付模块真正解耦
解耦的关键不在代码分目录，而在包声明与依赖收敛。每个模块必须发布为独立包，并在自己的 composer.json 中只声明最小必要依赖，比如订单模块不应 require 支付 SDK，而应 require 抽象的 payment-gateway-interface 包。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 订单模块的
composer.json中require只写"mycompany/payment-interface": "^1.0"，不写具体实现 - 支付网关实现（如微信、支付宝）各自发布为独立包，
require对应 SDK，但provide字段声明实现了mycompany/payment-interface - 主商城项目
composer.json中同时require订单包 + 微信支付实现包，Composer 自动满足接口契约 - 避免循环依赖：商品模块不能
require订单模块，反之亦然；共用逻辑抽成shared-utils包单独发布
使用 Satis 构建时 packages.json 为空的三个检查点
Satis 不报错但生成空仓库，90% 是配置链路断在源头。它不会主动告诉你 Git 仓库里没有有效的 composer.json，只会跳过。
- curl -I https://git.internal/order-module.git/composer.json 返回 404？说明 Git 仓库根目录下压根没提交
composer.json，或路径不对 - 目标 Git 仓库的
composer.json中name字段格式错误，比如含大写字母或下划线（mycompany/OrderModule非法，应为mycompany/order-module） -
satis.json中repositories的type写成了"git"或漏写，正确值只能是"vcs"；Satis 不识别"git"类型 - 执行
php bin/satis build时未加--no-interaction，卡在交互式提示上，看起来像“没反应”
最易被忽略的是：Satis 生成的是静态文件，不提供 API；一旦 Nginx/Apache 配置了 deny all 或未启用 index.php fallback，packages.json 就无法被访问，Composer 直接静默 fallback 到 packagist —— 连错误都不会抛。
