Bun Shell 中文变成 u4E2D：检查命令字面量

在 Windows 上运行 Bun Shell，中文测试 变成了 u4E2Du6587u6D4Bu8BD5，切换 .text()、.bytes() 结果也不对。遇到这组表现，先检查传给 Shell 的命令字面量。Bun 1.4.4 在上述 Windows 路径中可能在执行前改写中文输入，不能只按控制台编码问题处理。

这里的 u4E2D 是几个普通 ASCII 字符，前面没有反斜杠。它既不是正常的中文 UTF-8 字节，也不是可以直接交给 JSON 解析器还原的 Unicode 转义。

先看文件里的字节是否已经改变

下面这类写法把中文放在标签模板的固定部分：

import { $ } from 'bun';

const output = await $`echo 中文测试`.text();
console.log(output);

在符合该故障条件的 Windows 环境里，问题可能发生在命令解析阶段。即使将同一条命令重定向到文件，文件里也会出现 uXXXX 字符；换成 .bytes() 只是取回已经错误的内容，无法恢复原来的输入。

排查时同时保留命令文本、Bun 完整版本、原始输出文件和字节内容。若文件中的字节正确，只是终端显示不对，应继续查终端和解码约定；若输入从另一个文件读取，也要先确认那个文件本身没有损坏。不要仅凭“中文乱码”就套用这里的处理。

把文字放到插值参数中

对固定命令、变化的数据，可以把数据移出模板字面量：

import { $ } from 'bun';

const message = '中文测试';
const output = await $`echo ${message}`.text();
console.log(output);

Bun Shell 会把普通字符串插值作为字面量参数处理，并负责 Shell 转义。这条输入路径可以避开上述固定字面量的异常。不要改成 { raw: message }，也不要为方便而把用户输入拼成整条 cmd /c 命令；那会改变命令解析和转义边界。

如果调用的是外部程序，也可以用 Bun.spawn() 的参数数组，明确分开可执行文件与参数。Windows 的 echo 通常是 Shell 内建命令，不能直接把它当成任意机器上都存在的 echo.exe。采用参数数组时，应使用项目已有、路径和输入约定明确的可执行程序。

不要在输出端批量替换 uXXXX

把所有 u 后跟四位十六进制的文字替换成汉字，会误改原本合法的标识符、路径和日志，而且无法区分哪些字符曾被错误转换。更换代码页、使用宽松解码或忽略错误，也不能修复执行前已经变化的命令。

这条排查路径适用于 Bun 1.4.4 的上述 Windows 场景。其他平台或版本需要先核对命令字面量和输出字节，不能只因报错相似就认定受影响。若准备通过升级替代这项处理，应先在目标正式版本验证相同输入。

调整后，用相同的中文、空格和包含 Shell 特殊字符的合法参数核对接收端拿到的值，再比较输出文件的原始字节与预期编码。只有原始内容正确，才继续验证终端显示；进程退出码为零并不能证明文字没有被改写。