Composer在Serverless场景下通过极致精简Vendor包压缩延迟-composer-PHP中文网

serverless 冷启动慢主因是 vendor/autoload.php 反复扫描目录，--classmap-authoritative 因 classmap 过大反而更慢；需用 exclude-from-classmap 精准排除 tests/、docs/ 等无用路径，并验证 classmap 行数下降 30%–60%。

composer在serverless场景下通过极致精简vendor包压缩延迟

Serverless 冷启动慢，90% 问题出在 vendor/autoload.php 每次都要扫描整个 vendor/ 目录——不是代码写得慢，是 autoload 初始化阶段反复调用 file_exists() 和 stat() 导致单次耗时轻松破 600ms。真正有效的精简不是删文件，而是让 classmap 小、准、快。

为什么 --classmap-authoritative 反而让冷启动更慢？

很多人加了 --classmap-authoritative 却发现启动更卡，核心原因是 classmap 文件本身太大：PHP 7.4+ 下，每次冷启动都要 require 整个 autoload_classmap.php 进内存，而单次请求通常只用到其中不到 5% 的类。

classmap 越大，解析越慢；一旦超过 2MB，加载时间会非线性增长
--classmap-authoritative 是“查不到就报错”，不会 fallback，所以 classmap 必须覆盖所有运行时真实用到的类——漏一个就 Class not found
第三方包里混着 tests/、examples/、docs/，它们被默认纳入 autoload 扫描范围，却从不被调用，纯属拖累

exclude-from-classmap 不是可选，是必须显式声明

composer.json 中的 autoload.exclude-from-classmap 是唯一能精准收缩 classmap 范围的配置项。它不是“建议”，而是防止 classmap 膨胀失控的第一道防线。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

必须写全路径前缀："exclude-from-classmap": ["tests/", "docs/", "examples/", "stubs/", "fixtures/"]
注意结尾斜杠——"tests" 不生效，"tests/" 才匹配目录
某些包（如 laravel/framework）把 stubs/ 打进 dist zip，删了会导致 php artisan vendor:publish 失败，这类要保留或 fork 后清理
验证是否生效：grep -c '=>' vendor/composer/autoload_classmap.php，优化前后应下降 30%–60%

vendor 里的 .git 目录和 installed.json 能不能删？

能删，但有前提：必须确认当前全是 --prefer-dist 安装，否则删掉 .git 会导致下次 composer update 重 clone。

检查命令：grep -r '"source"' vendor/*/composer/installers.json 2>/dev/null || echo "ok"，无输出才安全
删 .git：find vendor -name ".git" -type d -prune -exec rm -rf {} +
vendor/composer/installed.json 必须保留——它是 composer install 确定性的依据；但 vendor/composer/ClassLoader.php、autoload_static.php 等生成文件可删，dump-autoload 会重建
别碰 composer.lock：它是安装确定性的唯一凭证，删了就等于放弃版本控制

CI/CD 中漏掉 --no-dev 会偷偷引入 dev 依赖

很多项目在 require-dev 里塞了实际运行时依赖，比如 symfony/var-dumper 被日志组件间接引用，删掉就报 Class not found。

先跑 composer install --no-dev，再执行 composer dump-autoload -a 触发一次完整 autoload 检查
报错时用 composer depends （需 Composer 2.5+）查谁在偷偷依赖它
临时方案：把真需要的包从 require-dev 移到 require，哪怕只是“运行时可选”
CI 中加一行 php -d display_errors=1 -m | grep opcache，确认没因扩展缺失导致 autoload 失败

最易被忽略的点：classmap 权威模式下，任何未被静态推导的 autoload 规则（比如大小写不一致的 PSR-4 路径、files 类型加载）都会直接失效，且错误不提示——它只会静默跳过，直到某次实例化突然报错。所以精简不是删得越多越好，而是让 classmap 覆盖面刚好够用、不多不少。