结论：composer安装慢主因是本地cpu密集型操作而非网络，如解析lock文件、生成autoload；正确使用install/update、配置镜像、优化autoload才是关键。
直接说结论：依赖安装慢，八成不是网络问题，而是composer install在解析composer.lock、校验哈希、生成autoload时卡住；用错命令（比如该install却跑update）、镜像配错、autoload配置不合理，才是真瓶颈。
为什么composer install卡在 Resolving dependencies 或 Generating autoload files
这个阶段完全不走网络，和镜像源无关。卡住说明 Composer 正在 CPU 密集型地解析 JSON、构建依赖图、遍历 PSR-4 目录——尤其当composer.lock超 5MB 或 vendor 有 200+ 包时，PHP 解析和写文件会明显拖慢。
-
--no-interaction必须加：跳过所有交互提示（比如脚本执行确认），CI/CD 中漏掉会导致命令挂起 -
--no-progress建议加：禁用 ANSI 进度条，减少日志 I/O，实测可省几百毫秒 -
--optimize-autoloader要慎用：它把 PSR-4 转成 classmap，类加载快了，但vendor/autoload.php体积变大，首次 require 略慢；如果项目里有动态拼接类名（如new $className），可能直接报Class not found - 别信“老插件加速”：像
hirak/prestissimo已停止维护，Composer 2.9.6 原生支持并行下载，强行启用反而引发内存溢出
composer config repo.packagist 配镜像总不生效的三个硬条件
配完还是慢？大概率是命令根本没写对，且 Composer 静默失败，不报错也不提示。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 键名必须是
repo.packagist（单数、全小写），写成repos.packagist或Repo.Packagist都无效 -
type值必须显式写composer，漏掉它，Composer 2.0+ 会 fallback 到官方源 - URL 必须以
https://开头，且末尾带斜杠，例如https://mirrors.aliyun.com/composer/；少斜杠会导致请求路径拼成/composerpackages.json直接 404 - 验证是否成功：
composer config -g repo.packagist输出应为完整 JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；返回空或报错，说明没写入
什么时候该用 composer install，什么时候必须用 composer update
这不是习惯问题，是语义边界问题：一个装锁文件里记死的版本，一个重算整个依赖树。
-
composer install：新环境拉代码、CI 构建、线上部署——只读composer.lock，装里面记录的**确切版本号**，比如"monolog/monolog": "2.10.0"；若无 lock 文件，它会悄悄 fallback 到update，等于绕过团队共识 -
composer update：本地主动升级依赖、调兼容性、加新包——忽略 lock，按composer.json重算依赖树，并**改写** lock 文件；CI 脚本里出现它，等于把版本控制权交给 Packagist 状态或某包作者刚发的 breaking change - 只想更新单个包？用
composer update guzzlehttp/guzzle，避免连带升级其他包引发意外 break - CI 流水线里必须加检查：
ls -la composer.lock，确保 lock 已提交且未被.gitignore排除；否则缓存可能命中旧 lock，装出和本地不一致的依赖
autoload 为啥不生效，Class not found 却总怪命名空间
90% 的 Class not found 不是路径或命名空间写错，而是 autoloader 没刷新，或者 PSR-4 配置本身埋了坑。
- 改了
composer.json的autoload段后，必须跑composer dump-autoload，否则不会生效 - 别把非类文件塞进 PSR-4 路径：比如
"App\": "src/"下混着config/、migrations/，autoloader 仍会扫描整个目录树；应拆成"App\": "src/App/"+"classmap": ["src/Helpers/Str.php"] -
--classmap-authoritative是双刃剑：它让 autoloader 完全跳过文件系统查找，只查 classmap——但要求所有类都已被收录进 map，否则必报错；生产环境用它前，先确认composer dump-autoload -a没漏类 - 开发时加
"optimize-autoloader": true到composer.json的config段，比每次手动加参数更可控
最常被忽略的一点：依赖解析慢和 autoload 加载慢，是两个独立问题。前者靠收紧版本约束、清理 require-dev、压缩 composer.lock；后者靠合理拆分 autoload 配置、避免动态类名滥用。混在一起调，只会越调越乱。
