We have seen that Dependency Injection can be achieved by implementing the right constructor and binding the dependencies at the start of the app, without using a third-party framework.
However, sometimes using one of these containers could help to ensure a uniform architecture, which is helpful when you have a really big development team. If the container you choose is used in several apps, you can be sure that it's often more robust than an internally-developed one.
If the dependencies are fixed and don't change during the life of the app, injecting manually is probably better, but if the dependencies are dynamic and change for different reasons, a DI container should permit to have a more flexible code capable to handle this situation.
Another advantage of a container is that it can control the life cycle of its service: a service can a be a static, a singleton, it can be recreated for every request, or it can have a scoped lifetime. A scoped lifetime means the instance is instantiated at the beginning of the scope, or session, and all calls in the same session are done to the same instance; a session could be defined as a transaction flow, buying a flight ticket from the search bar to check out, or from login to checkout.