В чем разница между использованием 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()
является абстракцией всего. И на мой взгляд преимущество даже в этом. Абстракция
Я не знаю, есть ли другие различия, такие как уровень производительности или безопасности
Ответы
Ответ 1
Короче говоря & до 2019 года:
- использовать env() только в конфигурационных файлах
- используйте App :: environment() для проверки среды (APP_ENV в .env).
- использовать config ('app.var') для всех остальных переменных env, например конфигурации ( 'app.debug')
- создать собственные файлы конфигурации для ваших собственных переменных ENV. Пример:
В вашем .env:
MY_VALUE=foo
пример конфигурации приложения /myconfig.php
return [
'myvalue' => env('MY_VALUE', 'bar'), // 'bar' is default if MY_VALUE is missing in .env
];
Доступ к вашему коду:
config('myconfig.myvalue') // will result in 'foo'
Объяснение & История:
Я просто почувствовал это. Когда вы кешируете свой конфигурационный файл, env() будет (иногда?) Работать неправильно. Итак, что я узнал:
- Laravel рекомендует использовать только env() в файлах конфигурации. Используйте помощник config() в вашем коде вместо env(). Например, вы можете вызвать config ('app.env') в своем коде.
- При использовании php artisan config: cache все строки конфигурации кэшируются платформой, и любые изменения, внесенные в файл .env, не будут активны, пока вы снова не запустите команду php artisan config: cache.
Отсюда:
https://laracasts.com/discuss/channels/general-discussion/env-not-reading-variables-sometimes
UPDATE:
Вызов env() работает до тех пор, пока вы не используете php artisan config: cache. Так что это очень опасно, потому что оно часто будет работать во время разработки , но не будет работать на производстве. Смотрите руководство по обновлению: https://laravel.com/docs/5.2/upgrade#upgrade-5.2.0
ОБНОВЛЕНИЕ Laravel 5.6:
Laravel теперь рекомендует в своей документации использовать
$environment = App::environment();
и описывают, что env() предназначен только для извлечения значений из .env в файлах конфигурации, таких как config ('app.env') или config ('app.debug').
Ответ 2
Одна вещь, которую следует учитывать, - это, пожалуй, фактор удобства передачи строки 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!");
}
Ответ 3
Если вы используете команду config:cache
во время развертывания, вы должны убедиться, что вы вызываете функцию env
только из ваших файлов конфигурации, а не из любого места в вашем приложении.
Если вы вызываете env из своего приложения, настоятельно рекомендуется добавлять правильные значения конфигурации в свои файлы конфигурации и вместо этого вызывать env из этого места, что позволяет конвертировать вызовы env
в вызовы конфигурации.
Добавьте параметр конфигурации env в конфигурационный файл app.php
, который выглядит следующим образом:
'env' => env('APP_ENV', 'production'),
Подробнее: https://laravel.com/docs/5.2/upgrade#upgrade-5.2.0
Ответ 4
У вас есть два одинаково хороших варианта
if (\App::environment('production')) {...}
или
if (app()->environment('production')) {...}
app() → environment() фактически используется Bugsnag, посмотрите в документации здесь он говорит
По умолчанию хорошо автоматически обнаруживает среду приложения, вызывая функцию environment() на экземпляре приложения Laravels.
Ответ 5
В методологии 12factor приложение содержит два типа значений конфигурации:
- внутренние, которые не меняются между развертываниями и хранятся в папке laravel
./config/
. В этом типе мы обычно храним некоторые технические оптимальные/хорошие значения, используемые в приложении, которые не должны изменяться пользователями с течением времени, например, оптимальный уровень сжатия изображения, время ожидания соединения, время истечения сеанса и т.д. - external, который варьируется между развертываниями и хранится в файле
.env
(но не должен храниться в git repo, однако .env.example
с примерами значений с подробной информацией может быть сохранен в repo). В этом типе мы обычно храним некоторые важные/защищенные значения, которые зависят от локальной среды, например, пароли, режим отладки, адрес БД и т.д.
Laravel предлагает удобный подход для этого
- в обычном коде мы используем только помощник
config(...)
(поэтому на этом уровне программисту не нужно знать, какое значение конфигурации является внутренним, а какое - внешним) - в конфигурационном коде внешние значения конфигурации должны быть установлены с помощью помощника
env(...)
например, в config/app.php 'debug' => env('APP_DEBUG', false)