config() 修改仅当前请求生效，不持久化、不影响其他请求或进程；持久化需用数据库/redis+服务提供者重载，且需处理服务单例刷新。
config() 函数能改配置，但只在当前请求生命周期生效
直接调用 config(['app.name' => 'New Name']) 确实能覆盖配置值，但它只是把新值写进 Laravel 内部的配置缓存数组里，不会触碰 config/app.php 文件，也不会影响其他请求。这是最常被误以为“已持久化”的地方。
常见错误现象：config('app.name') 在当前请求里返回新值，但刷新页面或发新请求就恢复原样；队列任务、命令行脚本、WebSocket 连接都看不到这个修改。
- 适用场景：临时切换调试开关、按用户角色动态调整日志级别、灰度发布时绕过某中间件
- 不适用场景：需要全局生效的运维参数（如数据库连接池大小）、多进程共享的状态（如限流阈值）
- 性能影响极小，本质是数组赋值；但频繁调用可能掩盖配置管理混乱的问题
想持久化？别碰 config/ 目录，用外部存储 + 重载逻辑
Laravel 的 config:cache 命令会把所有配置编译成静态 PHP 数组，硬编码进 bootstrap/cache/config.php。运行时直接改文件内容不仅危险，还会被下次 config:cache 覆盖。
真正可行的做法是：把可变配置抽出来，存在数据库、Redis 或环境变量里，然后在 ConfigServiceProvider 或 AppServiceProvider 的 boot() 方法中主动读取并合并进去。
- 示例：在
AppServiceProvider@boot中加config(['cache.default' => Cache::get('active_cache_driver', 'redis')]) - Redis 更适合高频读写场景（比如实时开关），数据库更适合带结构或审计需求的配置项
- 注意缓存穿透：首次读取失败时要有 fallback，默认值必须明确，不能依赖
config()原始返回
env() 函数在运行时完全失效，别试图用它动态改配置
env('APP_DEBUG') 只在应用启动阶段（bootstrap/app.php 和配置加载时）有效。一旦容器构建完成，.env 文件就被丢弃了，后续任何地方调用 env() 都只会返回 null 或默认值（取决于是否传第二个参数）。
错误写法：putenv('APP_MAINTENANCE=true'); env('APP_MAINTENANCE') —— 这个 env() 调用永远得不到更新后的值。
- 根本原因：Laravel 启动后不再解析
.env，env()底层只是查一个静态数组 - 替代方案：用
$_ENV或getenv()直接读系统环境变量（但需确保 Web 服务器/PHP-FPM 正确透传） - 兼容性风险：某些 SaaS 平台（如 Laravel Vapor）禁用
putenv()，这类写法直接报错
配置热更新要小心服务容器绑定和单例生命周期
即使你用 Redis 动态读取了新值并调用 config() 更新，已经实例化的服务（比如 MailManager、QueueManager）并不会自动感知变化。它们在容器里是单例，构造时读的配置早已固化。
典型问题：改了 mail.from.address，但已发出的邮件还是旧地址；改了 queue.connections.redis.queue，老的队列监听器仍在消费旧队列名。
- 解决方案分两步：先改
config()，再手动刷新对应服务（如$this->app->forgetInstance('mailer')） - 更稳妥的做法是避免在服务构造函数里读配置，改用运行时 lazy 获取（例如在
send()方法里调用config('mail.from')） - 注意内存泄漏：频繁
forgetInstance()可能导致对象重建开销上升，尤其在高并发请求中
