1. Transient lifestyle — A new instance is created every time the dependency is requested. This is the simplest and safest default — no shared state, no threading concerns. The cost is object allocation overhead, which is negligible for most services but can matter for expensive-to-create objects like database connections.

1. Scoped lifestyle — One instance is created per logical scope, typically an HTTP request or a unit of work. All classes within that scope share the same instance, enabling patterns like sharing a database context across multiple repositories within a single request. The scope is explicitly created and disposed, ensuring cleanup of resources like database connections.

1. Singleton lifestyle — One instance exists for the application's entire lifetime. All consumers across all threads and requests share the same object. This demands thread safety and is appropriate only for stateless services or carefully synchronized shared resources.

1. Captive dependency bug — The most critical lifetime mistake: a Singleton service depends on a Scoped or Transient service, "capturing" it and extending its lifetime indefinitely. Example: a Singleton OrderService injected with a Scoped DbContext — the DbContext outlives its intended request scope, accumulating stale entities and eventually corrupting data or exhausting connections.

Lifetime compatibility (safe → unsafe):

Singleton → Singleton ✅

Scoped → Scoped or Singleton ✅

Transient → Transient, Scoped, or Singleton ✅

Singleton → Scoped ❌ CAPTIVE DEPENDENCY

Singleton → Transient ❌ CAPTIVE DEPENDENCY

Scoped → Transient ⚠️ (often okay, but the Transient lives longer than expected)

1. Lifestyle mismatch detection — Some containers (Simple Injector) detect captive dependencies at configuration time and throw diagnostic warnings. Microsoft.Extensions.DependencyInjection does this only when ValidateScopes is enabled (default in Development). Always enable scope validation in development environments.