There is a principle in engineering that is often referred to as "managing complexity." This is the idea that, for any given analysis (designing an aircraft, working out a chemical process, working out how much storage space is required at a container port, etc.) one of the main goals is to manage the complexity of the problem. This is so that the analyst can understand the solution and be confident of it. And so that the result can be presented to a client or a government regulator in a way that is transparently convincing.
This is usually accomplished using, among many methods, breaking down the analysis into small components with simple relationships. Then building up the full analysis using compound objects and ideas that, though compound, have simple relationships. For a straightforward example: A single container requires a certain amount of space in the storage area. So 1000 similar containers require more space, but not simply 1000 times as much. You need to know the means of stacking, the maximum height, the size of the alleyways between, and other stuff. Once you build the ability to make stacks, then the ability to store multiple stacks should be a comparatively simple relationship. (Nearly but not precisely linear.)
So the idea is, at each step and at each level of abstraction, you build the analysis in a way that the concepts, relationships, and behviors, are all simple enough that you can "hold them in your head."
So also with proofs of math theorems. The idea is to build the proof using layers of abstraction. At each level, the concepts and relationships are kept such that you can "do it in your head." This is done, among other methods, by using symbols to carry around collections of information. An example of such a symbol might be "triangle" or "point" or "line segment." Or, for theorems about primes "prime number" or "prime factor." These symbols allow you to concentrate on specific details, putting the other details into the background. You concentrate on the properties required for purposes of the proof, avoiding being innundated with detail of all of the other properies of a number.
The result is, you build up the proof step-by-step, and layer-of-abstraction by layer-of-abstraction. At each point in the proof, the information and concepts you need to hold "in your head" is relatively small and so, hopefully, achievable. Thus, the parts of the theorem you need to verify are relatively small and relatively easy to verify. This-tiny-part and that-tiny-part have this-simple-relationship. And so you can treat the two of them as yet-another-simple-part.
The goal is, you never have to hold the entire proof in your head at one time, only small digestible bits. So, you don't need to be comprehend the proof-as-a-whole but only each tiny step and the (hopefully very local) implications of that step.
If such a built-from-simple-parts type approach is possible, then to doubt the proof amounts to doubting your own ability to think clearly at a nearly-trivial level. And, if you are having those type of problems, then you are having them before you get to Euclid's proofs.
This is, of course, very different from the original creation of the proof in the first place. That often requires some unuaully clever thinking that leaps around to multiple abstraction levels and uncovers relationships not previously well understood.