冷启动慢的根源是 vendor/autoload.php 每次都重新扫描文件系统，而非用了 Composer；必须同时使用 --optimize-autoloader 和 --classmap-authoritative 才能跳过扫描、强制走 classmap 查找，实测 P95 冷启动从 920ms 降至 310ms。
冷启动慢，不是因为用了 Composer，而是 vendor/autoload.php 每次都重新扫描文件系统——加 --optimize-autoloader 和 --classmap-authoritative 才能跳过扫描、强制走 classmap 查找，实测 P95 冷启动从 920ms 降到 310ms。
为什么 composer install --no-dev 不等于冷启动优化
很多人在 Dockerfile 里只写 composer install --no-dev，就以为 vendor 已优化，结果冷启动仍卡在 autoload 初始化。根本原因是：该命令默认只生成 PSR-4 动态映射，每次请求都要遍历 vendor/ 下成百上千个目录找类文件；而 Serverless 每次冷启动都重来一遍。
-
--optimize-autoloader会生成扁平的$classMap = array()，把所有类路径硬编码进数组 -
--classmap-authoritative强制关闭动态查找逻辑，只认这个数组，彻底跳过文件系统 I/O - 两个参数必须一起用，单独用
--optimize-autoloader仍会 fallback 到 PSR-4 查找 - 检查是否生效：grep
class ClassLoader { public static $classMap = array()vendor/autoload_static.php
composer dump-autoload 必须显式执行，且顺序不能错
composer install 只负责下载依赖并调用一次 autoload 生成逻辑；它不感知代码结构变化（比如新增类、改命名空间）。如果依赖没变但代码变了，install 不会重建 classmap。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确构建流程：
composer install --no-dev --prefer-dist→ 紧接着composer dump-autoload --optimize --classmap-authoritative - 漏掉第二步，
vendor/autoload.php加载的仍是未优化版本，冷启动照慢 - CI 构建阶段必须显式调用，函数运行时没有 PHP CLI，根本跑不了这条命令
- 阿里云 FC 或 AWS Lambda 日志里出现
Class not found，八成是这一步漏了，导致autoload_static.php没生成
构建镜像时容易踩的坑：PHP 版本、扩展和缓存路径
本地开发环境和 Serverless 运行时稍有差异，就会导致 classmap 路径错乱或扩展加载失败，冷启动直接报错。
-
"config": { "platform": { "php": "8.2" } }必须显式声明，否则 Composer 可能按你本地 PHP 版本解析依赖，生成错误的 classmap 路径 - 禁用无用扩展（如
mysqli、pdo_pgsql），它们在初始化阶段白占内存和时间；gd扩展带 freetype 支持会增加 80–150ms 启动延迟 -
--prefer-dist要加上：用压缩包而非 git clone，减少 vendor 目录体积和文件数量 - CI 阶段需显式复制
/root/.composer/cache并上传至对象存储，避免每次重建时重复下载
真正拖慢冷启动的，从来不是 Composer 本身，而是 vendor 目录的自动加载机制和 PHP 运行时初始化过程；哪怕你打包了一个含 composer install 结果的镜像，若没加那两个参数、没做扩展裁剪、没对齐 PHP 平台版本，冷启动仍可能卡在 vendor/autoload.php 的遍历注册上，耗时 600ms 以上。
