私有仓库需同时满足构建、声明、认证三步对齐：一要在项目根目录composer.json的repositories字段显式声明type和带尾斜杠的url；二要通过600权限的auth.json注入凭据或composer_auth环境变量；三要确保satis静态构建正确、nginx配置json mime类型及web路径严格匹配。
私有仓库不是加个 URL 就能用，必须同时满足构建、声明、认证三步对齐，缺一不可。否则 composer install 会静默跳过你的包，或报 Unable to load package list 却不提示具体哪一环断了。
私有源必须显式声明在项目 composer.json 的 repositories 字段
Composer 不会自动扫描你内网的 Git 服务器或本地目录，composer require vendor/package 报 Could not find package 的第一原因，就是项目根目录的 composer.json 没配 repositories 字段。
- 只改了私有包自己
composer.json里的name，却没在使用它的项目里加仓库声明 - 误以为
composer config --global就全局生效——它只影响插件和部分config项，repositories是纯项目级配置 - 把仓库地址写进子目录的
composer.json（比如packages/foo/composer.json），Composer 完全不读那里 - 正确写法：在项目根目录
composer.json顶层加"repositories"数组，且type必须是"composer"（对接 Satis）或"vcs"（直连 Git） -
url必须以/结尾（如https://satis.internal/packages.json/✅），否则 Satis 服务无法被识别 - 若混用多个源，私有源建议放
repositories数组首位；并显式禁用公共源：{"packagist.org": false}
认证凭据只能通过权限为 600 的 auth.json 注入
auth.json 是唯一合法的凭据载体，硬编码用户名密码、用 composer config http-basic 写进全局配置，都会导致泄露或权限失控。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 文件位置仅限两处：项目根目录（与
composer.json同级），或用户家目录（~/.composer/auth.json） - Linux/macOS 下必须运行
chmod 600 auth.json，否则 Composer 静默忽略，报错却是Authentication failed - HTTP Basic Auth 场景下，
http-basic的 key 必须和仓库域名完全一致（如"repo.internal.com"，不能写成"https://repo.internal.com"） - Git over HTTPS 需要
http-basic；SSH 方式则依赖系统ssh-agent，无需auth.json - CI 环境推荐用
COMPOSER_AUTH环境变量注入 JSON 字符串，避免挂载文件出错
Satis 构建不是实时同步，必须手动触发且路径严格匹配
Satis 不是代理服务，它生成的是静态文件。packages.json 不会随 Git 推送自动更新，必须手动运行 php bin/satis build satis.json web/。
- build 命令必须在 Satis 项目根目录执行，否则找不到
satis.json或因权限失败 - 输出路径（如
web/）必须和 Web 服务器（Nginx/Apache）的root完全一致，不能是子目录（如web/dist） - Nginx 必须显式支持 JSON MIME 类型：
add_header Content-Type application/json;要放在location ~ \.json$块里 - 别用
php -S跑开发服务器——它返回 200 但缺失Content-Type和重定向逻辑，composer install会直接放弃请求 -
require-all: true会让 Satis 尝试解析所有repositories下每个包的composer.json，只要其中一个缺失dist或分支信息，整个构建就中断
vcs 类型下版本号实际来自 Git tag，不是 composer.json 的 version 字段
Composer 解析 vcs 包时，完全忽略 composer.json 里的 version 值，只认 Git 的 tag 和分支名。
- 想用
"^1.0"，就必须打v1.0.0或1.0.0这样的语义化 tag；v1.0或1.0不被识别 - 分支名如
main对应虚拟版本dev-main，require时得写"dev-main"，且需"minimum-stability": "dev" - 没打任何 tag 时，
dev-main是唯一可用选项；写"1.0.0"会报Could not find package xxx at version 1.0.0 - 别用
package类型硬编码单个包——维护成本高，无法随 Git 更新 - 私有包自身的
composer.json必须含name（格式为vendor/name）、type、autoload，缺一不可
最容易被忽略的是 Nginx 的 JSON MIME 类型配置和 auth.json 的权限校验——这两处出问题时，错误现象往往和真实原因脱节，排查方向容易跑偏。
