Браузер и фронтенд-рантайм
Воркеры: тест на свободное припоминание
Припоминание сильнее перечитывания. Для каждого промпта проговори или запиши полный ответ по памяти, прежде чем открыть модельный — усилие реконструкции механизма и закрепляет его.
Восстанови костяк юнита, не подглядывая — границу DOM, стоимость clone против transfer, жизненный цикл service worker и его ловушку waiting, гейт COOP/COEP на SharedArrayBuffer и правила размера и формы пула воркеров.
- 01Почему ни один тип воркера не может трогать DOM и какое единственное исключение?
- 02Сравни structured clone и transfer: чего стоит каждый и когда вместо них SharedArrayBuffer.
- 03Пройди жизненный цикл service worker от register() до fetch и объясни состояние waiting.
- 04Перечисли всё, что нужно для существования SharedArrayBuffer, и цену включения.
- 05Как выбрать размер пула воркеров и какие два контроля держат его безопасным под нагрузкой?
- 06В чём проблема task-hop у Comlink и как проектировать интерфейсы воркера вокруг неё?
Если ты смог восстановить каждый ответ по памяти — ты держишь костяк юнита: воркеры никогда не трогают DOM (OffscreenCanvas — единственное исключение), postMessage клонирует со скоростью ~1 мс/МБ, тогда как transfer передаёт за O(1), а SharedArrayBuffer разделяет конкурентно за COOP+COEP, жизненный цикл service worker ждёт перед активацией, чтобы избежать version skew, SAB требует кросс-доменной изоляции и аудита каждого кросс-доменного ассета, а пул размером hardwareConcurrency − 1 безопасен лишь с backpressure, приоритетной маршрутизацией и грубыми (учитывающими task-hop) интерфейсами.