unknown vs any en TypeScript: ¿qué elegir en 2025?

Introducción: ¿por qué este tema explotó en Stack Overflow?

\n

Si alguna vez has escrito en TypeScript, seguro te has enfrentado al dilema: unknown o any? Esta pregunta, que ha acumulado miles de visitas en Stack Overflow, no pierde vigencia ni en 2025. Parece que ambos tipos permiten almacenar cualquier cosa, entonces, ¿cuál es la diferencia?

\n\n

Imagina que estás construyendo una casa. any es una puerta abierta de par en par para todos, incluidos los ladrones. unknown es una puerta con cerradura y mirilla: primero verificas quién llega y luego dejas pasar. En este artículo, entenderemos por qué unknown se ha convertido en el estándar de seguridad en TypeScript, y any en el mal que a veces está justificado.

\n\n

No solo resumiremos la documentación. Mostraremos casos reales de la práctica en 2025, analizaremos las mejores prácticas y daremos un algoritmo claro de elección. ¡Allá vamos!

\n\n

¿Qué es any y por qué todos le temen?

\n\n

any es el tipo más "flexible" en TypeScript. Literalmente le dice al compilador: "Desactiva el sistema de tipos, sé lo que hago". Suena como un superpoder, pero en realidad es una bomba de tiempo.

\n\n

Ejemplo: cómo any rompe los tipos

\n

function processUser(user: any) {\n    console.log(user.name.toUpperCase()); // Error en tiempo de ejecución si user es null\n}\n\nprocessUser(null); // TypeError: Cannot read property 'toUpperCase' of null

\n\n

¡El compilador de TypeScript ni siquiera te advertirá sobre esto! any desactiva todas las comprobaciones y el error solo aparecerá en producción. En 2025, cuando los proyectos son más complejos, este enfoque es el camino al caos.

\n\n

¿Cuándo es útil any?

\n

\n
• Migración desde JavaScript: cuando reescribes un proyecto antiguo, any es un parche temporal.
\n
• Datos dinámicos: por ejemplo, respuestas de APIs externas cuya estructura cambia.
\n
• Pruebas: en mocks a veces es más fácil usar any que describir tipos complejos.
\n

\n\n

Pero recuerda: any es como una tarjeta de crédito con límite infinito. Es cómodo, hasta que llega la factura.

\n\n

Unknown: un guardia estricto en la entrada

\n\n

unknown apareció en TypeScript 3.0 como una alternativa segura a any. También puede contener cualquier valor, pero prohíbe trabajar con él sin una verificación explícita. Es un tipo contenedor que requiere verificación.

\n\n

Ejemplo: unknown en acción

\n

function processUser(user: unknown) {\n    // ¡Error de compilación! La propiedad 'name' no existe en el tipo 'unknown'\n    // console.log(user.name.toUpperCase()); \n    \n    // Se necesita una verificación\n    if (user && typeof user === 'object' && 'name' in user) {\n        const typedUser = user as { name: string };\n        console.log(typedUser.name.toUpperCase()); // Todo bien\n    }\n}\n\nprocessUser({ name: "Alice" }); // ALICE\nprocessUser(null); // No fallará nada

\n\n

¿Notaste la diferencia? unknown no te deja dispararte en el pie. Estás obligado a verificar el tipo antes de usarlo. Esto es tipado seguro.

\n\n

Comparación any vs unknown en tabla

\n\n

Para consolidar el material, veamos las diferencias clave:

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Criterio	any	unknown
Asignación de cualquier valor	✅ Sí	✅ Sí
Acceso a propiedades sin verificación	✅ Sí	❌ No
Asignación a otro tipo	✅ A cualquiera	❌ Solo any o unknown
Protección contra errores en tiempo de ejecución	❌ No	✅ Sí (requiere verificación)

\n\n

Como ves, unknown gana