Middle: питання на співбесіді з теми «Конфігурація»

Коротка відповідь: після php artisan config:cache функція env() поза конфігами повертає null.

Чому. Кешування конфігурації зберігає підсумковий масив у один PHP-файл. Файл .env після цього взагалі не читається - у проді його може й не бути. Значення, зчитані під час збирання кешу, всередині конфігів залишаються; будь-який виклик env() в іншому місці виконується вже без завантаженого середовища.

Як ламається:

class WeatherClient
{
    public function __construct()
    {
        // У проді після config:cache тут null.
        $this->key = env('WEATHER_KEY');
    }
}

Найгірше, що локально все працює - кеш конфігурації зазвичай збирають лише в проді.

Правильно: env() живе тільки у файлах config/, а код читає конфіг.

// config/services.php
'weather' => [
    'key' => env('WEATHER_KEY'),
],

// будь-де в застосунку
$this->key = config('services.weather.key');

Побічна вигода: конфіг можна підмінити в тестах, а .env - ні.

config(['services.weather.key' => 'test-key']);

Виняток - файли, що виконуються до завантаження застосунку (bootstrap/), і сам AppServiceProvider тут не виняток: у ньому теж потрібен config().

Докладніше в документації: Конфігурація

php artisan optimize виконує пакет кешувань, які прибирають повторну роботу з кожного запиту:

php artisan config:cache    # усі config/*.php в один масив
php artisan route:cache     # маршрути в серіалізований вигляд
php artisan view:cache      # прекомпіляція Blade
php artisan event:cache     # мапа подій і слухачів

Зворотна дія - php artisan optimize:clear.

Що це дає: застосунок перестає на кожному запиті обходити десятки файлів конфігурації, парсити маршрути й компілювати шаблони. На середньому проєкті це десятки мілісекунд, які видно на кожному запиті.

Коли шкодить:

• Локально під час розробки. Закешований конфіг не помічає змін у .env, а закешовані маршрути - нових маршрутів. Півгодини пошуку помилки, якої немає.
• route:cache не працює із замиканнями в маршрутах: команда впаде з помилкою. Маршрути мають вказувати на контролери.
• env() поза конфігами перестає працювати - див. окреме питання про це.
• Якщо конфіг залежить від запиту. Кеш збирається один раз під час деплою, тож щось на кшталт мультитенантності за доменом у конфігу зафіксується у стані збирання.

Порядок під час деплою має значення: спершу викласти новий код, потім кешувати. Якщо кешувати до оновлення файлів, у кеш потрапить попередня версія.

Докладніше в документації: Розгортання

Перед завантаженням змінних Laravel дивиться, чи задано APP_ENV (змінною оточення процесу) або опцію --env у команді Artisan. Якщо так, і поруч є .env.{APP_ENV}, береться він замість .env.

APP_ENV=staging php artisan migrate          # прочитає .env.staging, якщо він є
php artisan test                             # phpunit.xml ставить APP_ENV=testing -> .env.testing

Типова схема:

• .env - локальна розробка, у .gitignore;
• .env.example - шаблон з усіма змінними без секретів, у репозиторії;
• .env.testing - окрема база й драйвери для тестів (QUEUE_CONNECTION=sync, MAIL_MAILER=array);
• продакшен - змінні оточення платформи чи секрет-менеджера, а не файл у репозиторії.

Пріоритет: справжні змінні оточення процесу важливіші за значення з .env - так платформа перекриває налаштування без зміни файлів.

Пастка: config:cache, виконаний з одним оточенням, «заморожує» його значення. Закешована конфігурація з продакшену на машині розробника чи навпаки - класична причина «тести пишуть у робочу базу». Тому кеш конфігурації будують лише там, де він буде використаний.

Перевірити, яке оточення активне: app()->environment(), php artisan about.

Докладніше в документації: Додаткові файли оточення

Коли «на сервері працює не так», перше питання - які насправді значення бачить застосунок.

php artisan about                      # версії, оточення, драйвери, стан кешів
php artisan about --only=environment
php artisan config:show database       # увесь файл конфігурації з поточними значеннями
php artisan config:show cache.default

Що показує about:

• версії Laravel, PHP, Composer;
• оточення, режим налагодження, URL, мовні налаштування;
• драйвери кешу, черги, сесії, пошти, бази;
• чи закешовані конфігурація, маршрути, події, шаблони.

Пакети можуть додавати свої секції через AboutCommand::add().

Типові знахідки:

• Config: CACHED після зміни .env - нові значення не діють, потрібен config:cache чи config:clear;
• Debug Mode: ENABLED на продакшені;
• черга sync замість redis - завдання виконуються в запиті;
• неправильний APP_URL - посилання в листах ведуть не туди.

Обережно: config:show виводить і секрети (паролі бази, ключі), тож результат не вставляють у чати й тікети без очищення.

Докладніше в документації: Команда about