你在 Git Bash 里执行一条命令，参数里带了点 Unix 风格的路径。命令跑完了，没有任何报错，但结果完全不对——它处理的是另一个文件。你反复检查参数，确实写的是 /tmp/x，可命令像是在跟一个你从没见过的文件打交道。
现象
几个典型片段：
- 想让某个工具把结果输出到
/tmp/x，结果文件出现在了「Windows 临时目录」里，或者干脆跑到了别的盘； - 命令里写
/Query，被改成了某个 Git 安装目录下的路径（比如C:/Program Files/Git/Query）； - 参数
/S、/reg:64这类本来该原样传给 Windows 程序的开关，被当成路径「翻译」掉了，程序收不到正确的参数。
共同点是：命令没报错，但行为不是你写的那个意思。
根因
这背后是 MSYS 的路径转换机制。
Git Bash 运行在 MSYS2 这个兼容层之上。MSYS 的目标是让 Unix 风格的工具和脚本能在 Windows 上跑。为此它做了一个「贴心」的设计：当一个参数看起来像 Unix 路径时，自动把它翻译成对应的 Windows 路径，再交给 Windows 原生的程序。
它的判断规则大致是：参数以 / 开头，并且像是绝对路径，就认为是 Unix 路径，尝试转换。比如：
/tmp/x→ 转换成一个实际的 Windows 临时目录路径；/Query→ 被当成「根目录下的 Query」，于是补成C:/.../Query。
这个转换对「给 MSYS 自己的工具用」是有益的，但对「需要原始参数」的场景就是灾难——尤其是那些用 / 开头做开关的 Windows 程序（/S、/Q、/reg:64 等），或者你故意想保留 Unix 语义的参数。
你没法直接控制它转不转——是 MSYS 在解析参数，它说了算。
解决
有三种办法，按推荐程度排列。
方法一：用 MSYS_NO_PATHCONV=1 前缀，为这次调用禁用转换。
MSYS_NO_PATHCONV=1 some-tool.exe /Query /S
这样这次调用里，MSYS 不会去翻译任何参数，你写的 /Query 就原样传过去。它只对这一条命令生效，不影响全局。
方法二：把参数写成双斜杠 //。
some-tool.exe //Query
MSYS 看到 // 开头会认为「已经处理过了」，不再转换，于是把 //Query 交给程序；有些程序会把它理解成 /Query。
方法三：外面套一层 cmd /c，绕过 MSYS 的解析。
cmd /c "some-tool.exe /Query /S"
命令由 Windows 的 CMD 来解析，MSYS 不插手参数。
一个更通用的原则：跨工具传路径时，统一用绝对的 Windows 路径（C:/dir/file 或 C:\dir\file）最不容易出歧义。因为 Windows 路径不会被 MSYS 转换，语义明确；而 Unix 风格路径在 MSYS 里永远有被改写的风险。
延伸与预防
这条坑的教训浓缩成一句话：
在 Git Bash 里，参数什么时候被改写是它说了算，不是你说了算。
它不是「你写什么就是什么」，而是「你写什么 + MSYS 怎么理解 = 实际执行什么」。中间多了一层你不可见的解释器。
往大了说，这是**「多层外壳」问题的通用形态**：你写的命令，要经过好几层解析器（bash、MSYS、Windows 参数解析、目标程序的参数解析），每一层都可能按自己的规则改写你的输入。判断一个参数最终会变成什么，要在脑子里把这几层都过一遍。
实用自检：在 Git Bash 里，凡是参数含 / 开头的，先停一下——它会被转换吗？我需要它被转换吗？如果不需要，用 MSYS_NO_PATHCONV=1 或绝对 Windows 路径。
这个坑还有个下游版本：一旦你用 MSYS_NO_PATHCONV=1 关掉了转换，那些依赖转换才正常的东西又会跟着坏掉（比如 /dev/null）。所以修完一处，记得再看一眼有没有在下游制造新问题。