Laravel 运行时修改 Config 值不能直接改 config/ 下 PHP 文件，因其配置在启动时已缓存或由 Repository 冻结；config() 辅助函数仅支持点号路径写入且不持久化，动态配置应使用数据库或 Redis 并通过 Service 层注入。
运行时修改 Config 值为什么不能直接改 config/ 下的 PHP 文件
因为 Laravel 的配置在启动时已通过 config:cache 编译进 bootstrap/cache/config.php，或在未缓存时由 Illuminate\Config\Repository 一次性加载并冻结。直接改 config/app.php 这类文件不会生效——它只是源文件，不是运行时实例。
真正起作用的是 Config 门面背后那个单例对象，它的底层是 Illuminate\Config\Repository 实例，内部用数组存储键值对，并默认禁止写入顶层键（如 'database'），只允许写入点号分隔的深层路径（如 'database.connections.mysql.host'）。
- 修改
config/app.php文件 → 无效（除非重跑php artisan config:clear+ 重启 FPM / Horizon / queue worker） - 调用
config(['app.name' => 'NewName'])→ 有效，且仅当前请求生命周期内生效 - 试图执行
config(['database' => [...]])→ 静默失败（不报错，但不覆盖整个database数组）
config() 辅助函数的两种用法及陷阱
config() 是最常用方式，但它有严格的行为边界：
- 读取：
config('app.debug')→ 返回当前值 - 写入单个键：
config(['app.debug' => true])→ ✅ 成功 - 写入嵌套键：
config(['logging.channels.stack.driver' => 'daily'])→ ✅ 成功（只要路径存在） - 写入不存在的顶层键：
config(['my_custom' => ['key' => 'val']])→ ❌ 不会创建新顶层项，返回null，且无提示 - 批量写多个顶层键：
config(['app.name' => 'A', 'app.url' => 'B'])→ ✅ 可以，但必须每个都是带点号的完整路径
注意：所有写入操作都不持久化，不会写回磁盘，也不会影响其他请求、队列任务或 Artisan 命令——除非你在这些上下文中也显式调用 config()。
队列任务里 config() 修改无效？原因和绕过方式
Artisan 命令、队列 worker、HTTP 请求是三个独立的进程（或协程）生命周期。你在 Web 请求中执行 config(['mail.from.address' => 'new@example.com'])，对正在运行的 queue:work 进程完全没影响。
- 队列任务启动时，
config已初始化完毕，后续 Web 层的修改对其不可见 - 解决思路不是“让队列去监听配置变化”，而是把动态值作为参数传进去
- 例如：不写
Mail::to(...)->send(new WelcomeMail())，而写SendWelcomeEmail::dispatch($user, $fromAddress)，在 job 的handle()中用传入的$fromAddress覆盖配置或直接构造Message - 如果必须复用原有 Mail 配置逻辑，可在 job 中手动调用
config(['mail.from.address' => $fromAddress])—— 此时修改只对该 job 实例生效
需要持久化动态配置？别硬改 Laravel config，换存储层
真要实现“后台修改 SMTP 主机，所有后续邮件立刻走新地址”，靠 config() 是反模式。正确做法是把可变部分抽离到数据库或 Redis：
- 建表
settings，字段如key（'mail.smtp.host'）、value、updated_at - 写一个
Setting服务类，提供get($key, $default = null)方法，在内部 fallback 到config($key) - 在
config/mail.php中这样写：'host' => \App\Services\Setting::get('mail.smtp.host', env('MAIL_HOST', 'smtp.mailgun.org'))—— 注意：这要求该文件返回的是运行时计算值，不能用于config:cache（因为闭包无法序列化） - 更稳妥的做法是：在
AppServiceProvider::boot()中用config(['mail.host' => Setting::get('mail.smtp.host')])动态注入，此时config:cache仍可用（只要不把动态值写死在 config/*.php 里）
绕过 Laravel config 系统本身不是缺陷，而是设计使然：它本就面向静态部署配置。动态场景下，你得自己管好“变量”的来源和传播范围——这点很容易被忽略，直到某天发现后台改了设置，但队列发的邮件还是旧 SMTP。
