根本原因是vendor目录混入tests/.git/docs/examples等非运行时文件，且未在目标环境docker中执行composer install --no-dev --optimize-autoloader --classmap-authoritative --prefer-dist并清理冗余路径，导致解压后超限及autoload失效。
vendor目录压缩后仍超250MB，根本原因不是zip没压好
Serverless平台（如AWS Lambda、阿里云FC）限制的是解压后体积，不是ZIP大小。很多团队用zip -r打包完发现上传失败，以为是压缩率不够——其实问题出在vendor/里混进了大量非运行时文件：tests/、.git/、docs/、examples/、CHANGELOG.md，单个包（比如monolog/monolog）就能贡献10MB+冗余。
必须在composer install之后立即清理，不能靠ZIP压缩“掩盖”：
find vendor -name "*.md" -o -name "tests" -o -name ".git" -o -name "docs" -o -name "examples" | xargs rm -rf- 在
composer.json的autoload段加"exclude-from-classmap": ["tests/", "Tests/", "test/", "Test/", "docs/", "examples/"]，防止dump-autoload扫描这些路径 - 配
.gitattributes：写vendor/** export-ignore，让git archive或CI源码拉取时直接跳过
composer install --no-dev不等于部署就安全
--no-dev只排除require-dev里的包，但很多“开发依赖”其实藏在require里：比如symfony/var-dumper、laravel/pint、phpunit/phpunit（被某些工具间接require）。它们不会报错，但会悄悄进vendor，占空间、拖慢autoload。
实操要分两步验证：
- 运行
composer show --dev，确认require-dev里没漏掉任何运行时不需要的包 - 运行
composer depends --tree your/production-package，查有没有意外拉入的调试类库 - 检查
vendor/bin/下是否存在phpunit、phpcs等二进制——它们不进autoloader，但解压后占几MB，Serverless里纯属冗余
classmap-authoritative没生效，冷启动还是慢
冷启动卡在autoload初始化，90%是因为classmap-authoritative没真正起效。常见现象是日志里看不到Class not found，但首次调用耗时>600ms——说明fallback机制还在工作，没强制走classmap。
关键判断点是看vendor/composer/autoload_static.php里有没有public static $classMap = array(...)。如果没有，说明：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只跑了
composer install --no-dev --optimize-autoloader，漏了dump-autoload --classmap-authoritative - 或者
composer install后没重新dump-autoload，而直接打包——install本身不生成权威classmap，它只负责下载和解压 -
composer.json里config.platform.php没设对，比如本地是PHP 8.3但Lambda跑8.2，导致autoload_static.php生成路径错乱
正确顺序必须是：composer install --no-dev --optimize-autoloader --prefer-dist → composer dump-autoload --optimize --classmap-authoritative → 清理 → 打包。
Docker构建镜像选错，vendor路径错位或扩展加载失败
本地macOS或Windows执行composer install，生成的autoload_static.php里路径带C:\或/Users/xxx，Lambda一require就Class not found。这不是权限问题，是ABI和路径语义不一致。
必须用目标环境一致的Docker镜像构建：
- AWS Lambda PHP 8.2 → 用
public.ecr.aws/sam/build-php82（官方）或bref/php-82-fpm（社区精简版） - 阿里云FC PHP 8.2 → 用
registry.cn-hangzhou.aliyuncs.com/aliyunfc/runtime-php82:latest - 别用
php:8.2-cli，它含大量调试工具，基础层400MB+，且glibc版本常与Lambda不兼容
构建命令要挂载当前目录并显式指定工作路径：docker run --rm -v $(pwd):/var/task public.ecr.aws/sam/build-php82 sh -c "cd /var/task && composer install --no-dev --optimize-autoloader --classmap-authoritative --prefer-dist"。漏掉--prefer-dist，某些包会用git clone方式拉取，多出.git目录和未压缩源码。
真正难的不是怎么删文件，而是删完之后autoload还能对上路径——classmap里每一条映射都得指向解压后真实存在的.php文件，错一个，函数就挂。这需要构建环境、清理逻辑、autoload生成三者严格咬合，缺一不可。
