I at least:

Use CI results to control quality, no nitpicking style means easier review

Review tests one by one, to make sure I understand what the submitter is trying to test and if they actually did so

Check files off one-by-one, compartmentalizing understanding as I go

Complain loudly when PRs try to change too many subsystems or different functionality, especially if less related changes are not separated into standalone commits

I often have Claude make code walks specifically to present walls of code more sanely, add diagrams, bring in code context outside the diff, etc. This is one manifestation I made but I think there are many ways people are solving this (or roll your own tool!) https://github.com/jeffbaumes/code-walk

I mean if it's a code review, you gotta review the code.