- Navios
- 26 de agosto de 2026 às 02:30 UTC
- Autor
- kamo
- Enviar
- c36c532
getRequestConfig é executado por solicitação, e para qualquer membro não-inglês chamado mergeWithFallback sobre todo o catálogo de 23,252 chaves toda vez — reconstruindo um resultado que não pode mudar até à próxima implantação. Medido em uma CPU desktop: 8-25 ms dependendo na localidade, ~16 ms em média, de trabalho de fio simples sentado em frente ao resposta. Um pod é mais lento do que uma área de trabalho, e isso cai no TTFB para cada página de carga por todos os membros que não estão lendo inglês. Cache por local para a vida do processo. A senda inglesa está intocada, já devolveu o catálogo base sem fundir. Duas coisas fazem isto mais barato do que parece. Ele é limitado pela construção: isLocale() porta a chave antes de chegar ao mapa, então há no máximo uma entrada por suporte locale, 21 deles. E um catálogo em cache é na sua maioria gratuito — mergeWithFallback copys REFERÊNCIAS de strings em vez de strings, então o que é retido é uma coluna de objeto sobre strings que o cache de importação já mantém. Seis cópias fundidas não eram distinguíveis de zero em uma medição de heap em processos separados. O retorno em inglês para um arquivo local desaparecido também está em cache, deliberadamente. Localidade arquivos enviam dentro da imagem, então um que está ausente no primeiro pedido está ausente para toda a vida do processo; re-leitura do fracasso por solicitação nada comprou. Seguro para compartilhar porque nada muda: o único consumidor do getMessages() é app/layout.tsx, que lê e entrega para NextIntlClientProvider. Verificado: tsc --noEmit clean over i18n/ and app/layout.tsx com suas importações transitivas.