直接删 bootstrap/cache/config.php 并执行 php artisan config:cache 是最快恢复服务的操作；因缓存文件为纯 PHP 数组，若含语法错误、null 值、未定义常量或非法路径，将导致框架启动时 fatal error。
直接删掉 bootstrap/cache/config.php，再跑 php artisan config:cache —— 这是最快恢复服务的操作，别在报错堆栈里反复打转。
为什么 config 缓存后项目突然异常
缓存后的 config.php 是一个纯 PHP 数组文件，Laravel 启动时会直接 require 它，跳过所有 config/*.php 的动态加载逻辑。一旦这个文件里存在语法错误、非法值（比如 null 被 var_export 导出为 NULL 但又被当成常量引用）、或依赖未初始化的环境变量（如 env('MISSING_VAR') 返回 null 后被硬塞进数组），就会在框架启动早期直接 fatal error。
常见触发点包括：
-
.env文件里漏写关键配置（如APP_KEY、DB_HOST），导致config/database.php中的env('DB_HOST')返回null，而该值又被用于拼接 DSN 字符串 - 自定义配置文件中用了未定义的函数或类（例如误写
Str::slug()但没 use 相关命名空间） - 配置值含非法字符（如密码里有未转义的单引号，导致生成的 PHP 数组字符串截断）
- 多环境部署时，
config:cache在开发机执行后把本地路径（如/Users/xxx/storage）写死进了缓存，上线后路径不存在
怎么定位 config 缓存里的具体问题
不要靠猜。打开 bootstrap/cache/config.php，用 PHP CLI 直接验证语法是否合法：
php -l bootstrap/cache/config.php
如果报错，看提示行号；如果通过，再试运行：
php -r "require 'bootstrap/cache/config.php';"
这时会真实暴露运行时错误，比如 Undefined constant NULL 或 Call to undefined function Str::slug()。注意：这个测试必须在项目根目录下执行，否则相对路径会失效。
关键点：
-
config:cache命令内部调用的是var_export()，它不支持闭包、资源、对象，只导出标量和数组 —— 所以任何配置项里写了匿名函数或实例，都会让缓存文件变砖 - 所有
env()调用必须在缓存前已解析完毕；缓存文件里不会保留env()调用，只保留其返回值 - 若你改过
config/app.php里的'providers'数组并加了未安装的包，缓存时会尝试 autoload 类，失败即中断
生产环境不能随便删缓存怎么办
线上不能停服务，也不能手动删文件？那就绕过缓存临时加载原始配置：
- 临时注释掉
bootstrap/app.php中这行：$app->loadEnvironmentFrom('.env');（防止 .env 读取干扰） - 在
public/index.php顶部加一行：putenv('APP_DEBUG=true'); - 然后访问任意路由，错误页会显示真实异常位置 —— 因为此时
config:cache被跳过，框架走原始配置加载流程
找到问题后，修复源配置文件，再重新执行 php artisan config:cache。切记：这个“绕行”只是诊断手段，不可长期启用，否则会丢失缓存带来的性能收益。
最易被忽略的一点：config:cache 不校验配置值的业务合法性，只做语法和结构导出。比如数据库密码写错，缓存能成功生成，但后续 DB 连接时才爆错 —— 这类问题得靠 php artisan tinker 里手动测 config('database.connections.mysql.password') 是否符合预期。
