php pod实现秒级扩容的关键是彻底分离composer构建与运行阶段：使用多阶段构建将vendor固化进镜像，启用--optimize-autoloader和--no-dev，节点预热oci层，并调低hpa stabilizationwindowseconds至15秒。
PHP Pod 要实现“近零延迟”启动，关键不是让 Composer 在运行时快，而是让它根本不用在 Pod 启动时跑 composer install —— 所有依赖必须提前固化进镜像或节点缓存中。本地节点缓存本身不加速 Composer 运行，只加速镜像拉取；真正消灭延迟的，是把 Composer 构建阶段和运行阶段彻底分离。
多阶段构建必须剥离 composer install 运行时
很多团队误以为“加个 composer install 就完事”，结果每个新 Pod 启动都卡在解析 composer.lock、下载包、生成 autoloader 上。这不是慢，是设计错误。
- 最终镜像里只保留
vendor/目录和代码，不带composer二进制、不执行任何 install 命令 - 构建阶段用
FROM composer/composer:2-bin AS composer，运行阶段用FROM php:8.2-fpm-alpine -
RUN composer install --no-dev --no-scripts --optimize-autoloader必须出现在构建阶段，且composer.lock必须已提交 - 如果漏掉
--optimize-autoloader，autoloader 会变成 classmap 模式 fallback，类加载变慢；漏掉--no-dev，vendor 体积翻倍，拉镜像时间直接+3~5s
节点级预热比集群内 registry 更适合 PHP 场景
在 ACK 或 EKS 等托管集群中，用数据盘快照预装镜像层（含 PHP 基础镜像 + vendor 层）比部署一个集群内 registry 更有效：前者让新节点开机即有镜像，后者仍需 pull-through cache 的首次拉取开销。
- 预热对象不是完整镜像，而是 OCI 层：基础镜像层（如
php:8.2-fpm-alpine）、vendor 层（由多阶段构建生成）、应用代码层 - ACK 支持通过
node-image-snapshot自动将这些层注入新节点的数据盘，避免冷节点从 registry 重新拉取 - 若用自建 registry，需改 kubelet 的
--image-pull-progress-deadline和 containerd 的registry.mirrors配置，维护成本高且对 PHP 镜像源支持不稳定（如registry.cn-hangzhou.aliyuncs.com/google_containers不含 PHP 官方镜像）
HPA 扩容行为必须匹配“秒级”预期
即使镜像秒级就位，HPA 默认的 stabilizationWindowSeconds: 300 会让扩容决策滞后 5 分钟——这和“秒级”完全矛盾。
- 必须显式设置
stabilizationWindowSeconds: 15，否则新 Pod 启动后指标上报再稳定，HPA 才开始下一轮判断 - 配合
behavior.scaleUp.stabilizationWindowSeconds: 15和behavior.scaleUp.policies[0].periodSeconds: 10，才能实现“10 秒内连续触发两次扩容” - 注意：
scaleDown不建议设得太激进，PHP-FPM 进程回收有延迟，过早缩容会导致请求 502
真正卡住“秒级”的从来不是 HPA 或调度器，而是镜像拉取路径上任意一个未固化的环节：没预热的节点、没剥离的 Composer、没锁死的 composer.lock、没启用 --optimize-autoloader 的构建。四个环节里只要一个没做到，所谓“近零延迟”就只是幻觉。
