私有包源地址变更后，必须同步更新主项目 composer.json 的 repositories 配置（含 type、URL、认证等），并执行 composer update --lock 刷新 composer.lock 中的源字段；若不可删 lock 文件，则需先验证新源可用，再清理缓存、检查版本约束与 Satis 构建或 Git 推送是否完成。
私有包发布后源地址变更，composer.json 的 repositories 怎么改
源地址变了，但项目里还用着旧的 Git URL 或私有仓库域名，composer update 会直接失败或拉错代码。必须同步更新主项目的 repositories 配置，且不能只改 URL —— type、认证方式、协议细节都要对齐。
常见场景包括：Git 仓库从 Bitbucket 迁到 Gitee、私有 Satis 服务换域名、内部 GitLab 实例升级导致 SSH 端口/路径变化。
- 如果原来是 SSH 地址（如
git@git.example.com:org/pkg.git），新地址改成了 HTTPS，得同时确认是否需要加认证（https://token:x-oauth-basic@git.example.com/org/pkg.git） - 如果是私有 Satis 仓库，
type必须保持"type": "composer"，URL 要指向新服务的packages.json入口（如https://new-satis.example.com/packages.json），不是 HTML 页面 - 若旧配置用了
packagist.org的镜像代理转发私有包（不推荐），新环境没配镜像，就得删掉repo.packagist相关 config，否则 Composer 仍会优先查镜像并 404
composer.lock 里还存着旧源信息，怎么清理干净
composer.lock 不会自动感知 repositories 变更，它只记录上次成功安装时实际下载的 dist source 和 commit hash。如果源地址已失效，composer install 会卡在 “Resolving packages…” 或报 Failed to download vendor/package: The 'https://old-url.com/...' file could not be downloaded。
最稳妥的做法是：删掉 vendor/ 和 composer.lock，再跑 composer install。但线上项目通常不能删 lock 文件 —— 此时要用 composer update --lock 强制重写 lock 中的源字段，前提是 repositories 已正确更新且新源可访问。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行前先验证新源可用：
curl -I https://new-satis.example.com/packages.json或git ls-remote https://new-git.example.com/org/pkg.git HEAD -
composer update --lock不会改动已安装包的版本，只刷新 lock 文件里的dist.url和source.url字段 - 如果包是通过
path类型引入的，源地址变更不适用——path本身不涉及远程 URL，但要注意本地路径是否还存在、权限是否 OK
私有包自己 composer.json 里的 source 和 dist 字段要不要同步改
不用动。这些字段只在你把包发到 Packagist 或 Satis 生成索引时被读取，对下游项目无直接影响。下游项目依赖的是你声明的包名（vendor/name）和版本约束，不是私有包自身 composer.json 里的 source 地址。
真正要改的是：该包在 Satis 配置文件（satis.json）中对应的 archive 路径、Git 仓库 URL，或者你在主项目 repositories 里写的那个入口地址。
- 如果你用的是自建 Satis，
satis.json里的"repositories"数组必须指向新 Git 地址，否则php bin/satis build会 clone 失败 - 如果你用的是 vcs 类型直连 Git，主项目
repositories的url改了，就足够；私有包自己的composer.json可以完全不管 - 唯一例外：你把私有包同时发布到了多个源（比如 Satis + GitHub Packages），且不同源用不同 URL，那得确保各源的元数据一致，否则
composer show vendor/name可能显示混乱的 source 信息
更新后 composer update vendor/name 还拉不到最新版？检查这三点
源地址改对了，composer.lock 也刷新了，但 composer update vendor/name 仍装旧版，大概率是版本约束或缓存问题。
- 检查主项目
composer.json中require的版本号是否锁死了（如"vendor/name": "1.2.0"），改成"^1.2"或"dev-main"才可能升级 - 运行
composer clear-cache—— Composer 会缓存包元数据（尤其是 vcs 类型），旧缓存可能还在返回老 commit - 确认新源里该包确实发布了新 tag 或 dev 分支有新 commit；
composer show vendor/name输出的sourceURL 应该是新地址，versions列表里要有你想升的版本
私有源更新最容易被忽略的点：Satis 构建命令没重跑，或 Git 仓库没 push 新 tag，导致新版本根本没进索引 —— 此时改再多配置也没用。
