I would use preprocessor directives:
#if DEBUG
Console.WriteLine("Debug version");
#else
Console.Writeline("Prod");
#endif
You can slap this pretty much anywhere in your program. Specifically in your case of a blazor app, not sure what you want to do in those conditions, but for instance you could have one component or text block show up in dev, and a different component in release.
One advantage of using the preprocessor directives is that you don't end up with all the unnecessary conditionals and extra lines of non-applicable code in production. Your release version of the code will only have what's under the else statement above.
One tip I have though is that you should change your build mode to "release" and make sure it compiles with your "else" conditions before committing or doing pull requests. I've made this mistake where you end up only compiling the Debug version of code, everything checks out, but the compile-time warnings won't show up for the other condition unless you build in that mode.
Here's a link where you can read all the gory details about how the directives work: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives
The pros/cons of using proprocessor directives vs the environment check can be found here, amongst other places. #if DEBUG vs if (env.IsDevelopment())
Edit: also wanted to add the maybe non-obvious tip that you can define your own constants as arguments in the msbuild string, for example.
/p:DefineConstants="STAGING;OTHERSTUFF"
In this way, you can expand your preprocessor directive inquiries beyond the stock constants, which may be more useful as you build and deploy to each environment. For instance, if you build release versions for both stage and prod, defining your own constants for the build/deploy process such as within your devops ci/cd pipelines can give you finer grained control over the directives.