Laravel 11在Kamatera的AlmaLinux 9+宝塔环境中安装失败，直接原因是PHP的disable_functions硬性禁用了putenv、proc_open、proc_get_status及exec等函数；需手动编辑php.ini删除这些函数并重启PHP-FPM，或改用composer create-project避免exec调用。
直接原因：Kamatera 默认 AlmaLinux 9 环境中，PHP 的 disable_functions 配置禁用了 Laravel 11 安装链路必需的底层函数，不是版本不兼容，也不是网络或权限问题——是宝塔（或手动配置）PHP-FPM 池里硬性屏蔽了关键系统调用。
为什么 putenv 和 proc_open 必须启用
Composer（尤其是 v3.x）在安装 Laravel 11 时依赖 composer/xdebug-handler 和 symfony/process 组件，它们需要：
-
putenv：用于临时关闭 Xdebug（避免内存溢出），否则 Composer 启动阶段直接Fatal error: Call to undefined function putenv() -
proc_open：用于执行子进程（如运行git clone、解压 ZIP、生成 autoload）、检测扩展、甚至 Laravel Installer 自带的软链接创建 -
proc_get_status：symfony/process在 v6+ 中默认调用它检查进程状态，禁用后会报Call to undefined function proc_get_status()
AlmaLinux 9 + 宝塔面板默认 PHP 配置中这三项全在 disable_functions 列表里，且不会在 phpinfo() 页面显式标红提示，容易被忽略。
怎么快速验证并修复
在 Kamatera 实例中执行以下命令确认问题根源：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
php -r "echo ini_get('disable_functions');"
若输出包含 putenv,proc_open,proc_get_status，就坐实了。修复方式（以宝塔为例）：
- 进入宝塔 → 软件商店 → 找到当前使用的 PHP 版本 → 设置 → 配置修改
- 搜索
disable_functions行，删掉putenv、proc_open、proc_get_status（保留其他如exec、system等无关项） - 保存 → 重启对应 PHP-FPM 服务（不是 Nginx/Apache）
- 再运行
php -r "echo function_exists('putenv') ? 'ok' : 'fail';"验证三者均已可用
后续仍卡在 exec() 报错？那是 Laravel Installer 的软链步骤
即使 Composer 装好了，运行 laravel new myapp 仍可能失败于：
Error: Call to undefined function Illuminate\Filesystem\exec()
这是因为 Laravel Installer v4+ 在项目初始化末尾尝试用 exec('ln -sf ...') 创建 storage 软链接，而 exec 也在默认禁用列表中。但注意：不建议直接放开 exec（安全风险高），正确做法是：
- 改用
composer create-project laravel/laravel myapp --no-interaction（跳过 Installer 的软链逻辑） - 进项目后手动执行
php artisan storage:link（该命令走的是 PHP 原生symlink()，不依赖exec）
真正麻烦的从来不是“哪里报错”，而是禁用函数列表像一张静态快照，改完一个，下一个在深层依赖里等着——putenv→proc_open→proc_get_status→exec，环环相扣。Kamatera 的 AlmaLinux 9 镜像本身干净，但宝塔套件加的这层安全限制，恰恰卡在 Laravel 11 最新工具链的命门上。
