As a veteran of a dozen different code review approaches I've identified a few properties of those that succeed and those that fail.
If you want your code review process to fail its easy just...
1. Make it about you and your preferences. Does this code adhere to my particular aesthetic preferences? Are the variables named the way I would name them? Do I consider this code readable? How can I force others to adopt my perspective? Remember the purpose of code reviews it to keep iron-fisted control of the code base such that it never becomes that dreaded "big ball of mud"
2. Demand that the team adhere to a set of rigid rules regardless of how practical their application is.
3. Most important focus mainly on the subjective qualities of the code(format, spacing, naming, etc.) Allow non-critical path items to hold up delivery and use those items to critique others based on an arbitrary measuring stick.
If you want your code review process to succeed. Its a little harder....
1. Be problem focused. What has bitten you in the past? Are you sure you understand the cause? Acknowledge that there is no "right way" and that you will build the perfect code review model through trial and error.
2. Start with the bare minimum and build on it with a regular retrospective process. Allow your team(s) to take ownership of the code review process both as an expression of what they want to accomplish and as a way to improve their daily lives.
3. Accept that you might have been the one doing it wrong all this time.
4. Focus on the objective qualities in the code. Is this the best approach to solving this problem? Does it work? Are there any obvious bugs? Based on our collective experience will this code cause problems later?
5. If you feel like you are nit picking then you are nit picking. Don't nit pick.
Code reviews can either be a tool to write better code or a form of weaponized OCD. Don't be the latter OP, you're better than that.