Из-за чего возникают коллизии стилей между микрофронтендами?

Микрофронтенды собираются из независимых приложений, которые в итоге рендерятся в одном документе браузера. CSS по своей природе глобальный: селектор .button из одного приложения применится ко всем элементам с этим классом на странице, включая элементы другого микрофронтенда. Именно это и порождает коллизии.

Основные причины

• Глобальная область видимости CSS: одинаковые имена классов, тегов и id пересекаются между командами.
• Глобальные сбросы и базовые стили: один микрофронтенд подключает reset.css или normalize.css, который ломает вёрстку соседей.
• Сторонние библиотеки: два приложения тянут разные версии Bootstrap или Ant Design с конфликтующими правилами.
• CSS-переменные и темы: одинаковые имена --primary-color переопределяют значения друг друга.
• Специфичность и порядок подключения: побеждает не «правильный» стиль, а тот, что загрузился позже или имеет больший вес селектора.

Пример коллизии

/* Микрофронтенд A */
.button { background: blue; color: white; }

/* Микрофронтенд B */
.button { background: red; padding: 20px; }

/* В DOM оба класса .button — стили перемешиваются */
<button class="button">Кнопка</button>

В результате кнопка получит фон из одного приложения, а отступы из другого, что непредсказуемо для обеих команд.

Способы изоляции

1. Shadow DOM: стили внутри теневого дерева не протекают наружу и не затрагиваются снаружи.
2. CSS Modules: классы хешируются на этапе сборки, например .button__a1b2c.
3. Scoped CSS (Vue) и styled-components: уникальные атрибуты или сгенерированные имена классов.
4. БЭМ и префиксы: договорённость об именовании appA-button снижает риск пересечений.
5. Изоляция через iframe: полная изоляция, но сложнее обмен состоянием и роутингом.

Итог: коллизии стилей — следствие глобальной природы CSS при совместном рендеринге независимых приложений. Изоляцию стоит применять всегда, когда несколько команд пишут CSS в одном документе, выбирая Shadow DOM, CSS Modules или строгие соглашения об именовании в зависимости от требований к совместимости и гибкости.