Правка PHP не видна на сервере, и дело не в opcache

Классика: залил правку, обновил страницу — старое поведение. Рука сама тянется сбросить opcache, потому что все знают: на проде validate_timestamps=0, кэш байткода держит старую версию.

Сбросил. Не помогло. Перезапустил PHP-FPM. Тоже.

Причина

Проверять надо не кэш, а две вещи попроще.

Владелец файла. Если правка залита от другого пользователя, чем тот, под которым работает PHP-FPM, файл может быть просто не прочитан — а веб-сервер отдаст то, что успел закэшировать раньше, либо свалится в ошибку, которую вы не видите, потому что смотрите не в тот лог.

ls -la path/to/file.php
ps aux | grep php-fpm | head -2   # под кем крутится пул

Расхождение владельца — самая частая причина «правка не применилась» после деплоя из-под root или из-под личного пользователя.

Синтаксис. Файл с ошибкой парсинга не применяется целиком. Если display_errors выключен (а на проде он выключен), внешне это выглядит ровно как «изменения не подхватились».

php -l path/to/file.php

Две команды закрывают большую часть случаев. Кэш байткода стоит трогать после них, а не до.

Почему первым подозревают opcache

Потому что про него все читали. Это доступное объяснение, оно требует ровно одного действия — сбросить — и создаёт ощущение работы. Владелец файла скучнее и в статьях про производительность не упоминается.

Отдельная ловушка на Битриксе: там кэшей несколько слоёв — байткод, управляемый кэш, кэш компонентов. Легко потратить час, обходя их по очереди, и не проверить ls -la.

Как не наступить снова

Деплой должен ставить владельца явно, а не наследовать от того, кто запустил команду. Если выкат идёт скриптом — chown в самом скрипте, а не в голове у дежурного.

Проверка после выката формулируется не как «сайт открывается», а как «конкретный изменённый сценарий отработал по-новому». Первое зелёное при полностью непринятой правке.