不是没装，是没在 cli 模式下启用——composer 依赖 cli 的 php.ini，需执行 php --ini 确认实际加载路径，并检查该 ini 中是否启用 session 扩展（如 extension=session），docker 环境尤需注意 docker-php-ext-enable session 与配置覆盖顺序。
直接结论：不是没装，是没在 CLI 模式下启用——php -m 看到的扩展，不等于 composer install 能用的扩展。
确认当前 composer 使用的是哪个 PHP 和 php.ini
Composer 运行在 PHP CLI 模式下，它读的 php.ini 和 Web（比如 Apache 或 Nginx）用的不是同一个。报错里提到的路径如 /etc/php83/php.ini 就是线索——哪怕你镜像标称 PHP 8.2，实际运行 composer install 的 PHP 可能是系统里另一个版本或配置。
- 执行
php --ini，看输出的 “Loaded Configuration File” 是哪一份 —— 这才是 composer 真正依赖的 ini 文件 - 执行
which php和php -v，确认 CLI 使用的 PHP 版本是否与项目要求一致（比如 Laravel 10 要求 PHP >=8.1） - 如果用 Docker，别只看
Dockerfile里写的版本，还要进容器跑php --ini验证实际加载路径
session 扩展不是“默认开启”，需显式启用
PHP 的 ext-session 不像 ext-json 那样常驻启用；很多精简镜像（尤其是 Alpine 或自定义构建）会跳过它，即使 php -m 显示已安装，也可能只是 .so 文件存在但未被 ini 加载。
- 打开
php --ini输出的主php.ini，搜索session.save_handler—— 如果这行存在且没被注释，说明 session 模块大概率已启用；如果整段缺失，就还没启 - 检查该
php.ini同级目录下的conf.d/（如/etc/php8.2/cli/conf.d/），看是否有*session*.ini文件；没有就手动加一个，内容只需一行：extension=session - Alpine 用户注意：
apk add php82-session（版本号对齐）后，必须补上docker-php-ext-enable session，否则仅安装不启用
常见踩坑点：CLI 和 Web 的 php.ini 分离 + Docker 多层覆盖
最容易忽略的是：你改了 Web SAPI 的 php.ini（比如给 Apache 用的），但 composer install 根本不读它。Docker 构建时也容易出问题——RUN docker-php-ext-enable session 放错阶段，或被后续 COPY 覆盖掉 conf.d 里的启用文件。
- 在 Docker 中，确保
docker-php-ext-enable session在所有apk add/apt install之后、且在最终php.ini被 COPY 覆盖之前执行 - 验证是否生效：进容器执行
php -m | grep session（不是php -i | grep session，后者查的是配置项，前者查的是真实加载模块） - 如果用了
platform配置（如"php": "8.2.10"），而实际 CLI 是 8.3，Composer 会优先按 platform 判断扩展可用性，导致误报 —— 此时要么调低 platform 版本，要么统一 CLI PHP 版本
真正卡住人的从来不是“怎么开 session”，而是没意识到 CLI 和 Web 的配置完全隔离，以及 Docker 构建过程里那些看似无关的 COPY 或 ENV 操作，会悄悄覆盖掉前面 enable 的结果。
