В чем разница между использованием env('APP_ENV'), config('app.env') или App::environment() для получения среды приложения?

В чем разница между использованием env('APP_ENV'), config('app.env') или же App::environment() получить среду приложения?

Я знаю что env('APP_ENV') воля к $_ENV, config('app.env') читает конфигурацию и App::environment() это абстракция всего. И на мой взгляд преимущество даже в этом. Абстракция

Я не знаю, есть ли другие различия, такие как уровень производительности или безопасности

Источник

6 ответов

Я просто почувствовал это. Когда вы кешируете свой конфигурационный файл, env() будет (иногда?) Работать неправильно. Итак, что я узнал:

  1. Laravel рекомендует использовать только env () в файлах конфигурации. Используйте помощник config() в вашем коде вместо env(). Например, вы можете вызвать config('app.env') в вашем коде.
  2. При использовании php artisan config:cache все строки конфигурации кэшируются платформой, и любые изменения, внесенные в файл.env, не будут активны до тех пор, пока вы снова не запустите команду php artisan config:cache.

Отсюда: https://laracasts.com/discuss/channels/general-discussion/env-not-reading-variables-sometimes

ОБНОВИТЬ:
Вызов env () работает до тех пор, пока вы не используете php artisan config:cache. Так что это очень опасно, потому что оно часто будет работать во время разработки, но не сможет работать. См. Руководство по обновлению: https://laravel.com/docs/5.2/upgrade.

ОБНОВЛЕНИЕ Laravel 5.6:
Laravel теперь рекомендует в своей документации использовать

$environment = App::environment();

и описывает, что env () просто для извлечения значений из.env в конфигурационных файлах. Но это только для config('app.env') и не работает для других переменных, таких как config('app.debug').

Источник

У вас есть два одинаково хороших варианта

if (\App::environment('production')) {...}

или же

if (app()->environment('production')) {...}

app()->environment() фактически используется Bugsnag, посмотрите в документации здесь

По умолчанию мы автоматически определяем среду приложения, вызывая функцию environment () в экземпляре приложения Laravel.

Источник

Одна вещь, чтобы рассмотреть, возможно, фактор удобства передачи строки в app()->environment() для того, чтобы проверить вашу текущую среду.

// or App:: whichever you prefer.
if (app()->environment('local', 'staging')) {
    logger("We are not live yet!");
    Seeder::seedThemAll();
} else {
    logger("We are LIVE!");
}
Источник

2023 Обновленный ответ

помощник работает, когда нет внутриbootstrap/cacheкаталог

помощник работает как в случае, если файлconfig.phpприсутствует или нет. Если файла нет, тогда if будет анализировать переменные во время выполнения, но если он их найдет; вместо этого он использует кешированную версию.

В производственной средеartisanкоманды, которые мы запускаем для добавления/удаления конфигурационного файла.php приобретает первостепенное значение в контексте того, какenv()и вести себя.

Рассмотрим следующий пример, чтобы понять концепцию:

      Route::get('/', function () {
  // to experiment: set APP_ENV=production in your .env file
  echo 'Via env(): ' . env('APP_ENV') . '<br/>'; // production
  echo 'Via config(): ' . config('app.env'); // production

  /*
  |--------------------------------------------------------------------------
  | run: php artisan config:cache
  |--------------------------------------------------------------------------
  |
  | The config:cache command will generate a configuration cache file (config.php) in the bootstrap/cache directory.
  | At this point, the env() helper will no longer work as all ENV variables will be flushed in favor of the cached config.php file.
  |
  */

  echo '<hr/>';

  echo 'Via env(): ' . env('APP_ENV') . '<br/>'; // null
  echo 'Via config(): ' . config('app.env'); // production

  /*
  |--------------------------------------------------------------------------
  | run: php artisan config:clear
  |--------------------------------------------------------------------------
  |
  | The config:clear command will remove (config.php) configuration cache file from the bootstrap/cache directory.
  | At this point, the env() helper will work again as framework doesn't find a cached configuration file.
  |
  */
  echo '<hr/>';

  echo 'Via env(): ' . env('APP_ENV') . '<br/>'; // production
  echo 'Via config(): ' . config('app.env'); // production
});

Таким образом, общее эмпирическое правило заключается в том, чтобы всегда использоватьconfig()помощник внутри ваших файлов кода; таким образом, ваш код не взрывается, если кешированный файл конфигурации доступен или нет.

Теперь получаюenvironmentтак важно и распространено; Laravel дает нам несколько способов сделать то же самое:

      // APP_ENV=production inside .env file

App::environment(); // production
app()->environment(); // production


App::environment('production'); // returns boolean: true
app()->environment('production'); // return boolean: true

Имейте в виду, что вы используетеAppфасад илиapp()помощник, которым они все будут пользоватьсяconfigпомощник под капотом.

Источник

Если вы используете config:cache Во время развертывания необходимо убедиться, что вы вызываете только env функционировать из ваших файлов конфигурации, а не из другого места в вашем приложении.

Если вы вызываете env из своего приложения, настоятельно рекомендуется добавить правильные значения конфигурации в файлы конфигурации и вместо этого вызвать env из этого расположения, что позволит вам преобразовать env звонки на конфиг звонки.

Добавьте опцию конфигурации env к вашему app.php файл конфигурации, который выглядит следующим образом:

'env' => env('APP_ENV', 'production'),

Подробнее: https://laravel.com/docs/5.2/upgrade

Источник

В 12- факторной методологии приложение содержит два типа значений конфигурации:

  • внутренние, которые не различаются между развертываниями и хранятся в laravel ./config/папка. В этом типе мы обычно храним некоторые технические оптимальные / хорошие значения, используемые в приложении, которые не должны изменяться пользователями с течением времени, например, оптимальный уровень сжатия изображения, тайм-аут соединения, время истечения сеанса и т. Д.
  • внешние, которые различаются между развертываниями и хранятся в .env файл (но не должен храниться в репозитории git, однако .env.exampleс примерными значениями с подробной информацией можно сохранить в репо). В этом типе мы обычно храним некоторые важные / защищенные значения, которые зависят от локальной среды, например пароли, режим отладки, адрес базы данных и т. Д.

Laravel предлагает удобный подход для этого

  • в обычном коде мы используем только config(...) помощник (поэтому на этом уровне программисту не нужно знать, какое значение конфигурации является внутренним, а какое внешним)
  • в коде конфигурации внешние значения конфигурации должны быть установлены с помощью env(...) помощник, например, в config / app.php 'debug' => env('APP_DEBUG', false)
Источник
Другие вопросы по тегам