Console.ForegroundColor 直接赋值 ConsoleColor 枚举值即可实时改变后续输出文字颜色，无需刷新或配置文件；它非线程安全，多线程修改可能互相覆盖；16种颜色含8基础色及8 Dark 版本，旧版 cmd 对 Dark 色支持不佳；颜色失效常见于环境限制、输出流重定向或终端不支持 ANSI。
Console.ForegroundColor 直接赋值就能改颜色
控制台文字颜色不是靠初始化或配置文件，就是一行代码的事：Console.ForegroundColor 是个可写属性，赋一个 ConsoleColor 枚举值就生效。它影响后续所有 Console.Write 和 Console.WriteLine 输出的文字，直到你再改它。
常见错误是以为要“刷新”或“重绘”控制台才生效——不用。也不需要 Console.ResetColor() 配合才能用，那是收尾时才考虑的。
-
Console.ForegroundColor = ConsoleColor.Red;之后输出全是红色，直到你换别的颜色或重置 - 颜色只对新输出生效，已输出的文字不会变色
- 如果在多线程环境里频繁修改这个属性，不同线程可能互相覆盖——
Console类不是线程安全的
哪些颜色可用？别硬记枚举名
ConsoleColor 只有 16 个固定值：8 个基础色（Black、Blue、Green、Cyan、Red、Magenta、Yellow、White），加 8 个“高亮版”（DarkBlue 到 DarkGray）。Windows 终端和 VS Code 的集成终端基本都支持，但旧版 cmd.exe 对 Dark* 色支持不稳定，比如 DarkYellow 可能显示成棕色甚至和 Yellow 没区别。
- 深色背景上优先用
Light*系列（实际是没前缀的那 8 个），比如黑底配White或Green - 浅色背景（如某些 PowerShell 主题）下，
Black或DarkGray才看得清 - 没有
BrightRed这种命名，只有Red和DarkRed——名字里的 “Dark” 是相对概念，不是绝对暗
颜色没生效？先查这三件事
最常踩的坑不是代码写错，而是环境或逻辑干扰。颜色“看起来没变”，大概率是下面其中之一：
- 你改了
Console.ForegroundColor，但紧接着又调了一次Console.WriteLine且没指定颜色——它会沿用上次设置，但如果之前被其他代码（比如日志库）改过，你就感知不到自己的改动 - 运行在非交互式环境，比如 CI 的 Linux runner 上跑
dotnet test，Console输出会被重定向，颜色控制符可能被过滤或忽略（Linux 下需确保TERM环境变量存在且终端支持 ANSI） - 用了
Console.SetOut()自定义了输出流，而该流不处理颜色控制序列——此时ForegroundColor设置无效，得自己往字符串里插 ANSI 转义码（如"\x1b[31m"）
想临时变色又自动恢复？别手动记旧值
手动存旧颜色再恢复容易漏写或顺序错，尤其嵌套调用时。更稳妥的做法是用 Console.ResetColor()，它把前景色和背景色都设回默认值（通常是 Gray 前景 + Black 背景），而且这个操作是幂等的。
示例场景：打印错误信息用红色，完事立刻复位：
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine("ERROR: File not found");
Console.ResetColor(); // 不管之前是什么颜色，都回到默认
- 不要依赖“上一次是什么颜色”，因为控制台状态可能来自外部（比如用户启动时设置了主题）
-
ResetColor()不抛异常，也不受当前是否支持颜色的影响，安全调用 - 如果需要精确还原到某个特定旧颜色，才值得缓存
Console.ForegroundColor，否则过度设计
颜色本身简单，麻烦的是它依赖终端解释能力，而 C# 的 Console 类只是把颜色映射成系统 API 调用或 ANSI 序列——中间哪一环断了，都会让你觉得“代码没起作用”。
