Gerar UUIDs

Se for uma chave primária de banco de dados, v7. Se precisar ser impossível de adivinhar — um link de redefinição de senha, um código de convite, um identificador de sessão — v4. Essa é toda a decisão, e a maioria das pessoas nem fica sabendo que havia uma, porque quase todo gerador oferece só v4.

Porque ele é completamente aleatório, e um índice de banco de dados é ordenado. Novas chaves aleatórias caem em lugares aleatórios do índice, então cada inserção atinge uma página diferente, o cache deixa de ajudar, e o índice se fragmenta e cresce. Em uma tabela grande e movimentada, isso causa uma lentidão mensurável que piora com o tempo. Não é uma preocupação teórica — é o motivo pelo qual a documentação do Postgres e do MySQL hoje trata do assunto.

Um UUID cujos primeiros 48 bits são um timestamp em milissegundos, seguidos de aleatoriedade. Ele continua globalmente único e continua tendo 128 bits, mas, como o tempo vem primeiro, UUIDs v7 ficam ordenados na ordem em que foram criados. Novas chaves são acrescentadas ao final do índice em vez de se espalharem por ele, que é exatamente como se comporta um inteiro autoincrementado — com a unicidade de um UUID. Ele foi padronizado na RFC 9562 em 2024 e é a recomendação atual para tabelas novas.

Sim, inclusive dentro do mesmo milissegundo, que é a parte que a maioria das implementações erra. Um timestamp só tem resolução de milissegundos, então gerar mil IDs em um loop termina dentro de um único milissegundo — e com bits finais puramente aleatórios esses mil NÃO ficam na ordem em que foram criados. Este gerador usa o contador monotônico descrito na RFC 9562, então um lote é estritamente crescente, sempre. Gere mil e ordene; eles voltam na ordem em que foram criados.

Com uma coisa em mente: ele revela quando foi criado, com precisão de milissegundos, por definição. Para uma chave de banco de dados, isso costuma ser inofensivo ou até útil. Mas se o momento da criação for sensível, ou se você precisar que o identificador seja impossível de adivinhar, use v4 — o v7 ainda tem 74 bits aleatórios, o que é muito, mas o timestamp dele pode ser lido por qualquer pessoa que tenha o ID.

Sim. A aleatoriedade vem de `crypto.getRandomValues`, o gerador criptograficamente seguro do navegador, e nunca de `Math.random`. Essa distinção já causou vulnerabilidades reais: `Math.random` é rápido, mas previsível, e tokens de sessão criados com ele já foram adivinhados na prática. Um UUID v4 tem 122 bits aleatórios, o suficiente para que colisões não sejam uma preocupação prática.

Sim, inteiramente, e para identificadores isso importa. Um UUID buscado no servidor de outra pessoa é um UUID que outra pessoa já viu — o que anula o propósito se você está gerando um segredo. Estes nunca saem do seu navegador. Depois que a página carregar, desligue o Wi-Fi e ela funciona exatamente igual. Essa é a forma mais simples de confirmar a promessa de privacidade por conta própria, em vez de confiar na nossa palavra.

Tudo zero: 00000000-0000-0000-0000-000000000000. É um UUID válido e reservado, usado para significar “nenhum” ou “não definido” onde um null não é possível. O oposto dele, o UUID max, todo formado por f, às vezes é usado como sentinela de ordenação. Os dois são oferecidos aqui porque às vezes são necessários e é chato digitá-los corretamente.