Two beans, `A` and `B`, each need the other. With constructor injection, Spring fails at startup and says so. With field injection, the exact same cycle can start successfully. What's the actual mechanism behind that difference, and is the field-injection version actually fine?

With constructors, there's genuinely no order that works: building A needs a finished B, and building B needs a finished A, so neither can go first — the container reports BeanCurrentlyInCreationException before either is done. With field or setter injection, the container has an extra move: it can construct A with its no-argument constructor (fields aren't set yet), put that half-built reference into an early-exposure cache, finish building B using that half-built A, and then go back and finish populating A. It genuinely starts. But — and this is the lesson's own point — that isn't the cycle being fixed. A and B still need each other; one of them was just handed a reference to an object that wasn't finished yet, and Spring Boot 2.6 made resolving cycles this way an opt-in rather than a default specifically because it's a workaround, not a solution.