PHP Laravel 配置缓存后环境变量为什么不变

Laravel 执行配置缓存后，修改 .env 不会让已缓存的配置自动变化。更准确地说：框架在后续请求和 Artisan 启动中不再加载该环境文件，业务通过 config() 读取的是缓存中的配置值；已经启动的队列或 Octane worker，还可能持有内存里的旧配置。不要把这三件事合并成“环境变量坏了”。

官方配置文档：https://laravel.com/framework/docs/configuration

配置缓存保存的是配置结果，不是环境文件监听器

config:cache 把应用配置汇总为一个可快速加载的文件，减少启动时逐个读取配置文件的工作。它适合部署阶段的配置准备，不是对环境文件的实时订阅机制。开发中频繁调整配置时，通常不需要保留这份缓存。

缓存建立时，配置文件里的 env() 表达式已经求值。例如配置项当时得到 preview，缓存保存的就是这个结果。以后只改 .env，并不会重新执行那些表达式。

缓存存在后，env() 仍可取得外部系统级环境变量；不能据此推断它一定返回空，也不能把它当作 .env 的读取接口。外部变量、默认值和配置快照可能产生不同结果。

先分清文件、启动环境和应用配置

本文使用六个实体说明边界：.env 文件与系统环境属于配置来源；config 文件、配置缓存和配置仓库属于应用配置；业务代码读取配置仓库。未缓存时，启动阶段可以加载环境文件，再解析配置；使用缓存时，仓库装入缓存结果，而不是逐项重读环境文件。

Laravel 文档说明，外部服务器或系统环境变量可以覆盖环境文件中的同名值。因此，命令行看到的新值，并不能直接证明 Web 服务获得了同样的启动环境。发布目录、运行用户、容器和进程管理器定义都应区分。

最小写法：在配置文件用 env，在业务里用 config

以下示例只使用无敏感信息的演示模式和修订标记，不发送邮件、不连接支付服务。新建 config/demo_delivery.php：

 env('DEMO_DELIVERY_MODE', 'preview'),
    'revision' => env('DEMO_CONFIG_REVISION', 'demo-a'),
];

在环境文件中设置演示值：

# 仅供演示，不填写密钥或真实业务接收地址。
DEMO_DELIVERY_MODE=preview
DEMO_CONFIG_REVISION=demo-a

业务服务中读取配置项，不在控制器、任务或服务类里直接调用 env('DEMO_DELIVERY_MODE')：

info('演示配置修订', ['revision' => $revision]);

demo_delivery 对应配置文件名，点号后面对应数组键。即使系统环境发生变化，已经缓存的 demo_delivery.mode 也不会被这个读取动作重新计算。若缓存建立前没有注入目标变量，默认值同样可能被保存进缓存。

开发清除配置缓存，部署在目标环境重建

开发环境需要重新解析配置时，使用范围明确的配置缓存清除命令：

# 在应用根目录执行，只清除配置缓存。
php artisan config:clear

下一次应用启动会重新解析配置；已经运行的长驻进程另行处理。不要为了一个配置问题默认清空业务缓存，也不必把 cache:clear 当成配置缓存的同义命令。

部署时，先让目标发布环境获得正确变量，再建立配置缓存：

# 在目标发布目录、目标环境已注入配置后执行。
php artisan config:cache

不要在没有生产变量的构建环境生成配置快照，再误以为运行容器注入变量就能改写里面的值。若采用预生成缓存的交付方式，必须明确缓存属于哪个环境，以及重新生成的责任方。多实例部署也要确保各实例的发布版本与配置修订一致。

这里给出的是读者执行用法，并非某台服务器的运行记录。命令结束不代表所有入口已经使用新配置，更不代表业务行为已完成回归。

队列和 Octane 还保留了一份运行中的应用

把发布目录、配置缓存文件放在发布资源边界，把Web 新启动、队列 worker、Octane worker放在应用实例边界，把进程管理器放在进程边界。新启动的应用可以装入新的缓存文件，而原有 worker 内存不因磁盘文件替换而自动更新。

Laravel 队列文档提供部署时的平滑退出信号：

# 完成当前任务后退出，由已配置的进程管理器重新拉起。
php artisan queue:restart

该机制依赖缓存中的重启信号和正确的进程管理配置。发送命令的一侧与 worker 必须能够看到对应信号；若项目关闭了 worker 的中断信号轮询，也不能假定该命令仍然有效。任务阻塞、进程管理器未自动拉起或使用另一套缓存配置，都可能使更新不完整。

已经使用 Octane 的项目，可按自身部署方式重载应用 worker：

# 仅用于已安装并运行 Octane 的应用。
php artisan octane:reload

这不是普通 PHP-FPM 项目的通用命令，也不意味着 Octane 所有服务器级设置都只需重载 worker。例如官方文档单独要求修改最大执行时间配置后重启 Octane 服务器。若变更的是进程管理器或容器注入的系统环境，还应依照部署平台更新启动定义和相关进程，不能承诺 worker 重载会刷新父进程环境。

队列官方文档：https://laravel.com/framework/docs/queues
Octane 官方文档：https://laravel.com/framework/docs/octane

用修订标记定位，不要公开打印配置

可以让受控日志带上非敏感修订标记和发布版本，比较不同入口与实例。不要开放公共调试路由输出整个 config()、$_ENV 或 $_SERVER；也不要把配置缓存作为不含秘密的普通静态资源发布，它可能包含已求值的连接信息和密钥。

两个容易误解的问题

修改 APP_ENV 能自动重建缓存吗？不能。环境名称参与应用环境的判断，不是配置缓存的失效开关。选用哪个环境文件，还需结合项目启动方式；现有缓存不会因为名称变更自动重新求值。

每个请求前都执行 config:cache 可以解决吗？不应这样做。配置生成应属于受控部署，不应让业务请求承担文件写入和环境快照生成。频繁重建既模糊责任，也可能把错误入口的环境写进缓存。

处理这类问题的核心是：env() 留在配置文件，业务使用 config()；在正确目标环境准备配置缓存，再让需要更新的应用实例加载它。缓存文件、系统环境和运行进程分别处理，才不会出现“命令成功了，部分请求还是旧值”的困惑。