env()函数仅在config/*.php中安全可用，运行时须用config()读取；生产环境禁用getenv()和$_ENV，直接调用env()会返回null；布尔/数字类型需手动转换，改.env后必须config:clear再config:cache。
env() 函数只在 config/*.php 里安全可用
你在 AppServiceProvider、控制器或命令行类里写 env('APP_DEBUG')，本地能跑，上线就返回 null 或字符串 "false"——这不是 bug，是 Laravel 启动机制决定的。框架只在加载 config/ 目录下所有 PHP 文件时，临时启用 env()，并把结果固化进配置系统；之后再调用，实际走的是被禁用的 getenv() 或空 $_ENV。
所以别试图在容器绑定、服务提供者注册逻辑里用 env() 做条件判断或构造参数。比如下面这段代码注定不可靠：
public function register()
{
if (env('ENABLE_CACHE_LAYER')) {
$this->app->singleton('cache.wrapper', CacheWrapper::class);
}
}
正确做法是：把开关挪到 config/cache.php 里定义，再用 config('cache.enable_layer') 判断。
容器注入要用 config()，不是 env()
Laravel 容器不认原始环境变量，它依赖已解析、已合并、已缓存的配置项。你往容器里 bind 或 singleton 一个服务时，如果依赖环境值，必须从 config() 取，否则缓存后失效。
常见错误场景包括：
- 在
register()中用env('API_BASE_URL')构造 HTTP 客户端实例 - 用
env('STRIPE_KEY')直接 new StripeClient()，没做类型转换 - 在
boot()里读env('LOG_LEVEL')动态改日志通道，但生产环境已缓存配置
应改为：
$this->app->singleton('payment.client', function ($app) {
return new StripeClient(config('services.stripe.key'));
});
而 config/services.php 里保持：'stripe' => ['key' => env('STRIPE_KEY')] —— 这样既满足加载阶段调用 env() 的规则，又保证运行时用 config() 安全取值。
布尔值和数字类型必须手动转换
env() 返回的永远是字符串，哪怕你在 .env 里写 ENABLE_FEATURE=true，env('ENABLE_FEATURE') 得到的也是 "true"，不是布尔 true。直接用于 if 判断会出错：
if (env('ENABLE_FEATURE')) { // 字符串 "false" 也是 true！
// 永远执行
}
解决方式只有两种：
- 在
config/*.php里用filter_var(env('ENABLE_FEATURE'), FILTER_VALIDATE_BOOLEAN) - 用
config('feature.enabled')，并在配置文件中写'enabled' => filter_var(env('ENABLE_FEATURE', 'false'), FILTER_VALIDATE_BOOLEAN)
数字同理：MAX_RETRY_COUNT=3 → (int) env('MAX_RETRY_COUNT')，不能靠自动类型转换。
部署后改 .env 为什么没反应
因为 php artisan config:cache 把所有 config/*.php 的执行结果（含 env() 调用结果）写死进了 bootstrap/cache/config.php。此后 .env 文件彻底被忽略。
所以部署流程必须严格按顺序：
- 上传新
.env（或通过 CI 注入环境变量） - 运行
php artisan config:clear（删掉旧缓存） - 再运行
php artisan config:cache（重新固化）
漏掉任何一步，或者在缓存存在时直接改 .env，都不会生效。更关键的是：PHP-FPM 进程不重启的话，$_ENV 和 getenv() 也不会更新——所以 Nginx + PHP-FPM 环境下，改完还得 reload php-fpm。
真正容易被忽略的点是：APP_ENV 值非法（比如设成 dev 而非 local）会导致整个 .env 加载被跳过，连第一次 env() 都不会触发。这个错误不会报异常，只会静默失败。
