golangci-lint 默认启用 ANSI 颜色输出以高亮错误级别，但在 CI 或不支持色彩的终端中会导致乱码；彻底禁用需使用 --no-color 运行时参数，它优先级最高且不依赖环境变量或配置文件。
golangci-lint 输出为什么带颜色？
默认开启 ANSI 转义序列，用于在支持色彩的终端（如 iTerm、GNOME Terminal、VS Code 集成终端）中高亮错误级别（error 红色、warning 黄色、info 蓝色）。但某些 CI 环境（Jenkins 控制台、部分裸机 SSH 会话）、Windows CMD 或日志归集系统不识别这些字符，会导致输出混入乱码（如 [31merror:...[0m），甚至被误判为格式错误。
怎么彻底禁用颜色输出？
用 --no-color 参数最直接有效，无需改配置文件或环境变量：
golangci-lint run --no-color golangci-lint run --no-color --out-format=checkstyle
注意：--no-color 是运行时开关，不是配置项，不能写进 .golangci.yml。它优先级最高，即使终端声称支持颜色也会强制关闭。
- CI 流水线里建议固定带上：避免因
COLORS=1或TERM=xterm-256color等环境变量意外触发着色 - 和
--out-format搭配使用更稳妥，比如checkstyle或json格式本身就不依赖颜色语义 - 别用
NO_COLOR=1 golangci-lint run—— 这个环境变量对 golangci-lint 无效，它只响应自己的参数
为什么 GOCOLOR=0 不起作用？
GOCOLOR=0 是 Go 工具链（go build, go test）用的环境变量，golangci-lint 完全不读取它。试图设这个变量只会让你多一次排查时间。
同理，CLICOLOR=0 或 FORCE_COLOR=0 也无效 —— 它们是其他工具（如 ls, npm）的约定，golangci-lint 不兼容。
CI 日志里还有乱码？检查输出管道是否被二次着色
有些 CI 平台（如 GitLab Runner 的 shell executor）或日志代理（如 Fluent Bit）会主动给 stdout 加颜色。这时单靠 --no-color 不够：
- 确认命令是否被包装在 wrapper 脚本里（比如
run-lint.sh中又调用了golangci-lint但漏传参数） - 在 CI 步骤开头加
echo $TERM，如果输出非dumb或空值，说明环境“假装”支持颜色，必须显式关掉 - 终极方案：把输出重定向到文件再 cat，绕过终端解析：
golangci-lint run --no-color > lint.out 2>&1 && cat lint.out
颜色不是 bug，但无意义的 ANSI 字符在日志里就是噪音。关掉它只要一个参数，但得知道该关谁、不该信谁。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
