用Chalk或picocolors给命令行输出上过色的开发者，几乎都遇到过这样一个问题：终端里输出五颜六色非常好看，可一旦把这些内容重定向到文件，打开一看全是类似 \x1b[32m、\x1b[0m 这样的乱码。这些字符其实是ANSI转义序列（也叫VT控制序列），Node.js从v16.11开始提供了内置方法 util.stripVTControlCharacters，专门用来把这类字符从字符串里剥离掉，不需要引入任何第三方依赖。
ANSI转义码为什么会污染日志文件
ANSI转义序列是终端的标准控制协议，由ESC字符（十六进制 0x1B）开头，后面跟着一串参数和指令。比如 \x1b[31m 表示把后续文字染成红色，\x1b[0m 表示重置样式，\x1b[2J 表示清屏。这些指令只在支持VT100协议的终端里有意义，终端会解析它们并渲染出颜色和光标动作，而写入文件之后就变成了一堆不可见或显示为乱码的控制字节。
污染带来的麻烦不只是看着难受。用grep检索日志时，目标文字可能被颜色码从中间切开，导致明明日志里有这个词却搜不到；用ELK或Loki做日志采集时，转义序列会被原样入库，既浪费存储又干扰分析；某些解析器甚至可能因为非法控制字符直接报错。所以只要是"输出带颜色、落盘要干净"的场景，都绕不开清理这一步。
stripVTControlCharacters的用法与原理
这个API非常简单，接收一个字符串，返回去除所有ANSI转义序列后的新字符串：
const util = require('util');
const colored = '\x1b[31mERROR\x1b[0m: 服务启动失败';
console.log(colored);
// 终端里 ERROR 是红色的
const clean = util.stripVTControlCharacters(colored);
console.log(clean);
// 输出: ERROR: 服务启动失败（无任何颜色码）它的内部实现其实就是一段内置正则，覆盖了CSI序列（如 \x1b[38;5;196m 这种256色和真彩色指令）、OSC序列（如设置终端标题的 \x1b]0;title\x07）以及若干单字符控制码。相比自己手写正则，用它有几个明显好处：一是官方维护，对各种边界情况（带问号参数的私有模式 \x1b[?25l、光标定位指令等）处理得比较周全；二是无依赖，对于CLI工具来说能少装一个包就少一个供应链风险；三是Node.js在内部处理 console 输出时用的也是同一套逻辑，行为和预期一致。
在日志管道中的三种接入方式
第一种是写入时清理，最直接。自己封装一个logger，在落盘前统一过滤：
const util = require('util');
const fs = require('fs');
function log(msg) {
const line = util.format(msg) + '\n';
// 终端保留颜色，文件写入干净文本
process.stdout.write(msg + '\n');
fs.appendFileSync('app.log', util.stripVTControlCharacters(line));
}
log('\x1b[32mOK\x1b[0m 用户注册成功 id=1001');第二种是在管道出口统一处理，适合已经存在大量散落的彩色输出、不想逐个改造的场景。可以用一个可写流包装 process.stdout，或者用 tee 类工具时在Node侧套一层Transform流：
const { Transform } = require('stream');
const util = require('util');
function stripStream() {
return new Transform({
transform(chunk, enc, cb) {
cb(null, util.stripVTControlCharacters(chunk.toString()));
}
});
}
process.stdout.pipe(stripStream()).pipe(process.stdout);第三种思路是从源头控制：很多着色库本身支持检测环境，比如Chalk在检测到 stdout 不是TTY时会自动关闭颜色，也可以通过 NO_COLOR 环境变量或 FORCE_COLOR=0 强制关闭。严格来说这不是清理而是预防，两者结合最稳妥——源头尽量不产生转义码，兜底再走 stripVTControlCharacters。
与其他清理方案的对比
自己写正则是最常见的替代方案，典型写法是 str.replace(/\x1b\[[0-9;]*m/g, '')。这个正则只能匹配 m 结尾的SGR颜色指令，遇到光标移动（\x1b[2A）、清屏（\x1b[2J）、隐藏光标（\x1b[?25l）就无能为力了。要补全就得写成 /\x1b\[[0-9;?]*[a-zA-Z]/g 之类的宽松版本，但过宽又可能误伤正常文本。另外还有 ansi-strip 这类npm包可用，功能与内置方法等价，只是多了一个依赖。
| 方案 | 覆盖度 | 维护成本 | 适用场景 |
|---|---|---|---|
| util.stripVTControlCharacters | 高，官方实现 | 零 | Node 16.11+项目首选 |
| 手写正则 | 取决于正则质量 | 高 | 老版本Node或极简场景 |
| 第三方strip包 | 高 | 低 | 需要兼容旧Node时 |
| 环境变量关闭颜色 | 预防而非清理 | 低 | 可控运行环境 |
需要注意两点：一是版本门槛，Node 16.11之前的版本没有这个API，只能降级到正则或第三方包；二是它只处理VT控制序列，不会清除其他不可见字符，如果日志里还混入了BOM或零宽字符，需要另行处理。另外对于超大量日志的实时清理，建议用Transform流分块处理而不是把整个文件读进内存，避免大文件场景下的内存压力。
总结一下，util.stripVTControlCharacters 是Node.js为清理ANSI转义码提供的标准答案，一行调用就能把终端彩显输出转换成干净文本。在构建CLI工具或日志采集链路时，把它放在落盘或上报的最后一环，配合颜色库的TTY检测，就能同时兼顾终端体验和日志质量。
Node.jsstripVTControlCharacters日志清理修改时间：2026-09-04 10:11:50