根本原因是ovh centos stream 9镜像预装精简，php 8.1+扩展缺失、openssl 3.x tls策略过严、selinux残留策略或apache重写未启用导致环境链路中断。
Laravel 10 在 OVH 的 CentOS Stream 9 上报错，根本原因不是 Laravel 本身有问题，而是 PHP 版本、扩展缺失、SELinux 或 OpenSSL 3.x 兼容性这四类底层环境不匹配导致的。OVH 默认提供的 CentOS Stream 9 镜像虽新，但预装配置偏精简，且未针对 PHP 应用栈做适配。
PHP 8.1+ 与 Laravel 10 的扩展依赖没装全
Laravel 10 要求 PHP ≥ 8.1，并强制依赖以下扩展：
-
mbstring -
xml -
ctype -
json -
openssl（注意：CentOS Stream 9 默认用 OpenSSL 3.x，部分旧扩展需重新编译） -
pdo+pdo_mysql或pdo_pgsql
OVH 的最小化安装镜像通常只带 php-cli，其余全靠手动补。
运行 php -v 和 php -m 可快速确认是否缺失。
常见报错现象：
-
Class 'Illuminate\Foundation\Application' not found（phar或zip扩展未启用） -
Call to undefined function mb_strlen()（mbstring缺失） -
Failed to load extension 'xml'（php-xml包未装）
解决方法：
-
dnf install -y php-mbstring php-xml php-json php-opcache php-pdo php-pdo_mysql php-zip php-gd php-bcmath php-curl - 若提示
No match for argument: php-xml，说明仓库未启用 AppStream：先执行dnf config-manager --set-enabled crb（CentOS Stream 9 中 CRB 替代了 PowerTools）
Composer 安装时卡在 openssl / zip 扩展校验失败
OVH VPS 默认关闭 SELinux，但部分镜像仍保留其策略残留；更常见的是 OpenSSL 3.x 的默认安全级别过高，导致 Composer 下载包时 SSL 握手失败：
- 报错示例：
cURL error 60: SSL certificate problem: unable to get local issuer certificate - 或：
file could not be downloaded: SSL operation failed
这不是证书路径问题，而是 OpenSSL 3.x 默认禁用 TLS 1.0/1.1 和部分弱 cipher，而某些 Composer 镜像源（如 packagist.org 的 CDN 节点）尚未完全适配。
临时绕过（仅限开发/测试环境）：
- 在运行
composer create-project laravel/laravel前，加环境变量：export COMPOSER_DISABLE_TLS=1 - 更稳妥做法：更新 CA 证书并降级 OpenSSL 安全策略（不推荐生产）：
-
update-ca-trust - 编辑
/etc/pki/tls/openssl.cnf，在[default_conf]下添加：openssl_conf = default_conf，再追加段落定义 cipher 强度
-
但最省事且安全的做法是换国内镜像源：
-
composer config -g repo.packagist composer @#@#@#@#@#@#@#@#@#@0（已停用） - 改用：
composer config -g repo.packagist composer @#@#@#@#@#@#@#@#@#@1
SELinux 残留策略拦截 storage/logs 写入或 .env 加载
OVH 镜像虽常设 SELINUX=disabled，但若你手动启用了它（或使用了未清理的模板），就会触发静默拒绝：
-
laravel.log无法写入，但无明确错误，只有tail -f storage/logs/laravel.log空白 -
.env文件存在却读不到，php artisan tinker中env('APP_NAME')返回null - Apache/Nginx 日志里出现
avc: denied { write } for ... comm="httpd" name="logs"
验证是否 SELinux 干扰：
-
sestatus查状态 -
ausearch -m avc -ts recent | grep httpd看最近拒绝记录
修复方式（二选一）：
- 彻底关闭：
setenforce 0+ 修改/etc/selinux/config中SELINUX=disabled，再重启 - 或仅放行 Laravel 目录：
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html(/.*)?"，然后restorecon -Rv /var/www/html
Apache mod_rewrite 未启用或 AllowOverride 被禁用
OVH 的 Apache 默认配置极度保守，.htaccess 几乎一定失效，导致访问 / 显示目录列表、API 路由 404、重定向循环。
检查点：
-
a2enmod rewrite在 CentOS Stream 9 上无效（无此命令），应改用：dnf install -y httpd-mod_ssl后确认/etc/httpd/conf.modules.d/00-base.conf中LoadModule rewrite_module modules/mod_rewrite.so未被注释 - 主机配置中必须显式允许覆盖：
<directory> AllowOverride All </directory> - 若用虚拟主机，还需确保
Options FollowSymLinks已启用，否则 Laravel 的符号链接逻辑（如storage:link）会失败
典型症状：
- 访问
@#@#@#@#@#@#@#@#@#@2正常，但@#@#@#@#@#@#@#@#@#@3返回 Apache 404（非 Laravel 404） -
php artisan serve能跑通，但 Apache 下所有路由都 fallback 到首页或 403
关键点在于：OVH 提供的是“干净但裸”的系统镜像，它不预设 Web 开发栈。Laravel 10 的报错几乎全是环境链路上某处断开所致——不是代码写错了，而是你还没把 PHP、Composer、Web 服务器、SELinux 这几环对齐。最容易被忽略的是 OpenSSL 3.x 的 TLS 策略和 CRB 仓库未启用这两项，它们不会直接报错，但会让后续每一步都变得不可预测。
