Ansible win_shell传C:\路径时触发Jinja2引号不平衡报错问题

该报错触发于Ansible的模块参数解析阶段，并非win_shell模块执行时的PowerShell报错，也和Expand-Archive命令本身无关。
Ansible的参数拆分逻辑存在历史兼容bug：当单引号包裹的字符串末尾紧邻反斜杠\时，解析器会误将该反斜杠识别为单引号的转义符，把后续的闭合单引号当作普通字符处理，最终判定引号/Jinja2块不闭合，抛出参数拆分失败的错误。

• 目标路径为c:\temp时，路径内的反斜杠后跟随普通字符t，不会触发上述转义逻辑，因此命令可正常解析执行
• 目标路径为C盘根目录c:\时，反斜杠刚好是单引号包裹内容的最后一个字符，紧邻闭合单引号，直接触发解析bug
  手动将c:\转义为c:\\无法解决问题的原因是：解析器处理完第一层转义后，字符串末尾仍然是反斜杠，依然会转义后续的闭合单引号。

以下方案均不需要针对盘根目录场景编写特殊分支逻辑，兼容含空格、特殊字符的各类Windows路径，适配Jinja2模板自动生成代码的场景：

• 方案1（最简便，全场景兼容）：统一将所有Windows路径中的反斜杠替换为正斜杠。PowerShell原生支持正斜杠作为路径分隔符，c:/与c:\的执行效果完全一致，替换后路径末尾不会出现紧邻单引号的反斜杠，从根源上规避解析bug。修改后的解压命令示例：

  Expand-Archive -LiteralPath 'c:/my_data.zip' -DestinationPath 'c:/' -Force
  

  Jinja模板生成路径时，只需对所有路径统一做一次反斜杠转正斜杠的替换即可，无需额外判断路径类型。
• 方案2（保留反斜杠写法）：通过Ansible的quote过滤器自动处理路径转义，不需要手动调整路径格式。将路径定义为变量后传入命令，过滤器会自动适配所有转义规则，示例写法：

  - name: Unarchiving install_my_data_1655833375 folder or file
    vars:
      archive_path: 'c:\my_data.zip'
      extract_dest: 'c:\'
    win_shell: |
      Expand-Archive -LiteralPath '{{ archive_path | quote }}' -DestinationPath '{{ extract_dest | quote }}' -Force
  

• 方案3（最佳实践）：放弃通过win_shell调用PowerShell命令的写法，直接使用Ansible官方原生win_unzip模块完成解压操作。该模块内置Windows路径转义逻辑，不会触发参数解析bug，写法更简洁，示例：

  - name: Unarchiving install_my_data_1655833375 folder or file
    win_unzip:
      src: c:\my_data.zip
      dest: c:\
      delete_archive: false
  

内容的提问来源于stack exchange，提问作者ZZTest