O universo dos números de quatro dígitos
Quando você começa a trabalhar com numeração em sistemas, logs ou validação de dados, logo percebe que existem diferenças sutis entre o que a matemática diz e o que a prática pede. A pergunta simples que aparece com frequência em threads de programação é sobre os limites desse intervalo, e a resposta exata depende se você está falando de um valor numérico puro ou de uma string formatada. Vou explicar o raciocínio direto primeiro, antes de entrar nas definições formais, porque já vi muita gente confundir os dois casos e perder horas debugando validações que não faziam sentido.
A resposta para qual é o menor número de quatro algarismos
Matematicamente, o menor número de quatro algarismos é 1000. A contagem de algarismos segue a posição decimal: milhar, centena, dezena, unidade. O primeiro algarismo não pode ser zero — caso contrário, deixaria de ser um número de quatro dígitos e passaria a ter três, dois ou um. Por isso, a faixa completa vai de 1000 até 9999, totalizando 9000 valores possíveis. Já se a pergunta se refere a strings de exatamente quatro caracteres numéricos, aí entramos no território do que chamamos de código fixo, e a lógica muda. Um PIN de quatre digits pode começar com zero. Nesse caso, o menor seria 0000, mas não se trata mais de um número inteiro — trata-se de uma sequência de quatro posições, onde o zero à esquerda é significativo.
Eu passei por esse problema na prática uns três anos atrás, trabalhando em um sistema de autenticação legado. O banco de dados usava VARCHAR(4) para salvar PINs, mas o script de importação vinha de uma planilha que tratava os valores como inteiros. O resultado foi que registros com PINs começando com zero foram truncados: 0001 virou 1, 0012 virou 12, e a validação na tela de login começou a falhar para usuários que tinham PINs válidos. A correção foi simples — mudar o campo para CHAR(4) e tratar os valores como string desde a entrada —, mas levou um dia inteiro para identificar a causa raiz porque o log não mostrava erro algum, só inconsistência de dados.
Por que essa distinção importa na prática
Quando você lê documentação técnica ou resposta de forum, às vezes perde tempo porque não fica claro se estão falando de inteiros ou de strings. Vou detalhar os dois cenários.
Números de quatro dígitos como inteiros
O intervalo fechado é [1000, 9999]. Qualquer operação aritmética, comparação de magnitude ou geração aleatória de números reais segue essa regra. A primeira posição (mais significativa) varia de 1 a 9, as demais de 0 a 9. O cálculo é simples: 9 × 10 × 10 × 10 = 9000 combinações. Isso vale para CEPs numéricos brutos (quando tratados como número, embora no Brasil o CEP tenha 5 dígitos), códigos de produto quando a regra de negócio proíbeLeading Zero, ou qualquer campo numérico inteiro com validação de magnitude.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Números de quatro dígitos como strings ou códigos
Aqui a faixa é [0000, 9999], com 10000 combinações possíveis. Cada posição pode ser zero. É o padrão para PINs, senhas de quatro dígitos, códigos de segurança, e qualquer identificador fixo de quatro caracteres onde a ordem e a posição importam, não o valor numérico. Muita gente erra ao validar esse tipo de campo com expressões regulares que permitem apenas ^[0-9]{4}$ quando o sistema espera um inteiro, ou vice-versa. O correto é saber desde o início qual das duas naturezas o campo tem.
Erros comuns que eu já vi acontecendo
O primeiro erro frequente é assumir que zero à esquerda é sempre inválido. Em códigos, não é. Em inteiros, sim. A regra do menor número de quatro algarismos só se aplica ao segundo caso. O segundo erro é tratar a faixa como [0, 9999] quando deveria ser [1000, 9999] para inteiros, ou [0000, 9999] para strings. Em testes de fronteira, isso gera bugs que só aparecem em produção, porque os dados normais nunca tocam os extremos.
Um terceiro problema prático: ao gerar números aleatórios de quatro dígitos para testes, usar Math.floor(Math.random() * 9000) + 1000 funciona para inteiros, mas se o sistema espera strings com padding de zeros, o resultado precisa ser formatado com toString().padStart(4, '0'). Se pular essa etapa, gera dados que parecem válidos numericamente mas falham na comparação de strings.
Quando essa informação se torna crítica
Existem cenários onde não distinguir entre as duas interpretações gera falhas sérias. Sistemas financeiros que usam CPF, por exemplo, lidam com 11 dígitos, mas quando trabalham com subcódigos de quatro dígitos para segmentação de conta, a diferença entre tratar como inteiro ou como string define se um dígito inicial zero será preservado ou perdido. Em logs de sistema, timestamps parciais de quatro dígitos (como ano abreviado YY) podem causar problemas famosos de Y2K. O ano 2000 foi representado como 00 em muitos sistemas legados porque o campo era de dois dígitos, e o mesmo tipo de armadilha existe em campos de quatro dígitos quando alguém considera que 0001 é o mesmo que 1.
Para validar um campo de quatro dígitos de forma robusta, a abordagem que uso hoje é verificar a natureza primeiro: se precisa ser inteiro, usar validação numérica com faixa [1000, 9999]; se for código, validar comprimento fixo com regex e preservar zeros à esquerda com tipos de dados adequados. Não adianta só verificar se são quatro dígitos — tem que saber o contexto. A resposta curta continua sendo 1000 para inteiros e 0000 para strings. Mas o importante é saber quando cada um se aplica, porque na prática essa é a parte que mais causa dor de cabeça.
