镜像配置写错一个字符即静默回退官方源：必须用composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏-g、多s、少末尾/均失效；验证需输出完整JSON，且项目级repositories或用户权限错位会覆盖全局配置。
镜像配置写错一个字符，缓存就形同虚设
执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 是唯一推荐的全局配置方式。漏掉 -g、把 repo.packagist 写成 repos.packagist（多一个 s）、URL 少末尾斜杠，都会导致静默 fallback 到 https://packagist.org，而你完全感知不到。
验证是否生效只有一种方法：运行 composer config -g repo.packagist，输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或仍是原始地址，说明没写进去。
常见干扰项：
- 项目级
composer.json中存在"repositories"字段，会直接覆盖全局配置 - CI 或宝塔中以
www用户运行命令，但composer config -g是用root执行的，路径在/root/.composer/config.json，www根本读不到 - 旧版 Composer 1.x 兼容
repos.packagist，但当前主流是 2.9.6，只认单数repo.packagist
缓存目录和 vendor 必须同时挂载，缺一不可
~/.composer/cache/files/ 为空？说明 ZIP 包根本没进缓存——大概率是镜像未生效，Composer fallback 到 source 下载，而国内镜像几乎不缓存 source。
只缓存 vendor/ 目录，不缓存 ~/.composer/cache/，等于只存了“结果”却丢了“原材料”，下次 install 仍要重新下载；反之只缓存 cache 而不缓存 vendor，则每次都要解压重建，白费缓存。
CI/CD 中务必同步缓存两个路径：
- GitHub Actions：
cache: paths: [vendor/, ~/.composer/cache/] - GitLab CI：用
cache: key: $CI_COMMIT_REF_SLUG并显式列出两路径 - Docker 构建：把
COPY composer.json composer.lock ./放在COPY . .之前，利用分层缓存复用vendor/
安装命令必须带 --prefer-dist，否则缓存不生效
--prefer-dist 强制走 ZIP 包下载，跳过 git clone 流程。没加这个参数时，部分包会 fallback 到 git clone，触发 git init + git checkout + submodule 同步，耗时翻倍，且 ZIP 缓存完全不参与。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
生产部署建议固定三参数组合：
-
--no-dev：跳过开发依赖，少下 20+ 个包 -
--optimize-autoloader：生成静态 classmap，autoload 阶段提速 30%+ -
--no-interaction：避免交互阻塞 CI 流程
完整命令示例：composer install --no-interaction --prefer-dist --no-dev --optimize-autoloader
卡在 Resolving dependencies？换镜像没用
这个阶段完全不走网络，是 Composer 在本地穷举满足所有约束的版本组合。镜像再快也救不了它。
典型诱因：
-
composer.lock缺失或未提交到 Git —— 每次都得重解依赖树 -
"minimum-stability": "dev"或版本约束太宽，如"*"、"^1.0 || ^2.0"，求解器指数级爆炸 - 私有源已下线，Composer 逐个超时重试
- PHP CLI 模式下 OPcache 被禁用，解析开销陡增
临时验证：运行 php -d opcache.enable_cli=1 composer install，若明显变快，说明是 OPcache 问题。
最常被忽略的点：镜像只加速下载，不解决依赖解析；缓存只对 install 有效，update 会清掉旧缓存重来；composer.lock 文件的完整性、PHP 版本一致性、平台配置（platform.php）三者稍有偏差，缓存就会失效，重新拉包。
