生产环境报“could not find package xxx”是因本地path仓库被误带入——composer不fallback且路径必不存在，必须从composer.json彻底移除；推荐用独立composer.prod.json或构建时动态合并，ci仅允许install而非update，并严格校验installed.json中source字段。
生产环境部署时直接报 Could not find package xxx at any version，基本可以断定是本地 path 仓库配置被带进了生产环境——Composer 不会自动忽略或 fallback，它只认路径存在与否。
path 仓库必须从生产环境的 composer.json 中彻底移除
本地开发用 "type": "path" 很方便，但它的路径（比如 "../my-package"）在生产服务器上必然不存在。Composer 遇到缺失路径时不会退回到 Packagist 或其他仓库，而是直接中断安装。
- 绝对不要把含
path仓库的composer.json提交到主干分支或用于构建镜像 - 推荐做法：把
path配置放在composer.json的extra字段或独立的composer.local.json中，再通过构建脚本合并（如jq+cat），而非硬编码进主配置 - 更稳妥的方式：用
COMPOSER=composer.prod.json composer install --no-dev显式指定不含 path 的配置文件，避免任何误用可能
CI/CD 流程中必须区分 install 和 update 行为
composer install 依赖 composer.lock，而 composer update 会重写 lock 文件并尝试解析所有仓库——包括已失效的 path。CI 环境一旦执行了 update，就可能因路径缺失失败，或更糟：悄悄跳过该包、导致 lock 文件漏掉真实版本。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 脚本里只允许用
composer install --no-dev --prefer-dist，禁用update - 确保 CI 缓存键包含
composer.lock的哈希值，防止不同 commit 复用错误缓存 - 若需更新依赖，应在本地完成
composer update+ 提交新composer.lock，CI 只负责“还原”而非“决策”
本地开发与线上行为不一致的典型陷阱
最隐蔽的问题不是部署失败，而是部署“成功”但行为异常：比如本地用 path 仓库覆盖了某个包的 dev-main 分支，而线上装的是 Packagist 上的 v2.1.0，两者接口或返回值不兼容，却没报错。
- 检查
vendor/composer/installed.json中对应包的source字段：本地应为"type": "path"，线上应为"type": "package"或"type": "vcs" - 避免在
require中使用"*"或"dev-*"这类模糊约束，它们在 path 模式下会被忽略版本规则，上线后却触发远程解析，结果不可控 -
composer show vendor/package在本地和线上分别运行，对比versions和source输出，这是验证是否真正在用同一份代码的最快方式
真正难的不是让 path 仓库在本地跑起来，而是确保它在任何自动化流程中都「不可见」——它不该出现在 Git 历史、CI 日志、Docker 构建上下文或线上 vendor/ 的元数据里。越早把它从主配置中剥离，越少遇到凌晨三点排查“为什么线上少了一个方法”的情况。
