Windows 下 CLI 参数的引号陷阱：为什么 --resume 'uuid' 会失败

问题现象

在 Windows 终端执行：

qoderclicn --resume '0691d0aa-e732-47ee-8261-f13ad7202fa4'

报错：找不到对应的 session。

去掉引号后一切正常：

qoderclicn --resume 0691d0aa-e732-47ee-8261-f13ad7202fa4

根因：单引号在 Windows shell 里不是"引号"

这是 Unix 和 Windows shell 语义差异的经典坑。

Shell	单引号 `'...'` 的行为	双引号 `"..."` 的行为
Bash / Zsh	强引用，剥掉引号，内容原样传递	弱引用，剥掉引号，允许变量展开
cmd.exe	**字面字符**，原样传给程序	弱引用，剥掉引号
PowerShell	强引用，剥掉引号（和 Bash 类似）	弱引用，剥掉引号，允许变量展开

关键点：cmd.exe 不认单引号。它把 ' 当作普通字符，连同 UUID 一起传给程序。

所以程序实际收到的参数是：

'0691d0aa-e732-47ee-8261-f13ad7202fa4'

注意首尾各多了一个 ' 字符。程序拿这个字符串去匹配 session ID，当然匹配不上。

为什么在 Bash 里没问题

Bash 的引号处理发生在 shell 层，程序拿到的永远是"去引号后"的参数：

# Bash 中以下三种写法等价，程序收到的都是纯 UUID
--resume '0691d0aa-...'
--resume "0691d0aa-..."
--resume 0691d0aa-...

很多开发者习惯了 Bash 的"单引号 = 安全包裹"，切到 Windows cmd 后惯性照搬，就踩坑了。

什么时候确实需要引号

只有参数包含空格或特殊字符时才需要：

:: 路径含空格，必须用双引号
qoderclicn --config "C:\Program Files\myapp\config.json"

:: UUID 不含空格，不需要任何引号
qoderclicn --resume 0691d0aa-e732-47ee-8261-f13ad7202fa4

规则总结

场景	推荐做法
参数无空格/特殊字符	不加引号
参数含空格（路径等）	用**双引号** `"..."`
参数含 `%` 或 `&`（cmd 特殊字符）	用双引号包裹，或转义
跨平台脚本	避免单引号；用双引号或干脆不加

延伸：为什么 AI 工具容易犯这个错

LLM 的训练语料以 Linux/macOS 环境为主，Bash 语法占绝对多数。当 AI 生成 Windows 命令时，很容易把 Bash 的引号习惯带过来——给 UUID、数字、简单标识符加上单引号"以防万一"。在 Bash 里这是无害的（引号被剥掉），但在 cmd.exe 里就是 bug。

给 AI 生成 Windows 命令的 prompt 建议：明确指定目标 shell（cmd / PowerShell / Git Bash），并要求"不含空格的参数不加引号"。

参考

• Microsoft Docs: Command shell overview
• SS64: Quotes and Escaping in Windows CMD