<b>Nuxt ломается не от SSR, а от плохой дисциплины вокруг данных</b>

<b>Nuxt ломается не от SSR, а от плохой дисциплины вокруг данных</b>

Чаще всего проблемы в Nuxt начинаются не в роутинге и не в компонентах, а в том, как тянут данные:
— один и тот же запрос вызывают и на сервере, и на клиенте;
— состояние кладут в локальные refs вместо общего слоя;
— забывают, что часть кода исполняется только при SSR.

У Nuxt сильная сторона — единый каркас для страницы, API и meta-данных. Но за это платят сложностью: если разнести логику по случайным composable без правил, проект быстро превращается в набор «магических» хуков, где нельзя понять, кто и когда меняет состояние.

Есть наблюдение которое стоит проверить: самые стабильные Nuxt-проекты держат три вещи отдельно — загрузку данных, отображение и side effects. Данные приходят через один очевидный путь, UI не знает, откуда они взялись, а эффекты типа аналитики, localStorage и фокуса живут вне SSR-ветки.

Ещё один рабочий чек-лист: не тащите в layout то, что относится к одной странице; не дублируйте SEO-мета вручную в десяти местах; не смешивайте server-only и client-only код в одном файле без причины. Чем меньше «скрытой магии», тем проще переехать на новые маршруты, формы и источники данных без переписывания половины приложения.

Если Nuxt начинает казаться тяжёлым, обычно виноват не фреймворк, а архитектура вокруг него: держите SSR-границы явными, а данные — предсказуемыми.