把一段在 Linux 上运行的文件处理代码搬到 Windows，最显眼的变化是路径中的斜杠方向。但实际报错常常不止于此：C:notes.txt 没有指向预想的目录，JSON 中的 \n 变成换行，或者程序把网络共享路径拼坏了。只把 / 替换成 \，通常修不完这些问题。
反斜杠延续了 DOS 和 Windows 的路径约定。DOS 命令选项里已有 /，目录路径则采用 \，两种语法长期同时存在。不过，把历史概括成“当年只有反斜杠能选”，已经超出了文档能够证明的范围。对今天的软件来说，更有用的是分清文件系统、编程语言、命令行和 URL 各自怎样解释同一段文本。
路径不是一串可以任意替换的字符
Windows 中常见的完整路径包含驱动器名、根分隔符和后续目录，例如 C:\Users\reader\notes.txt。网络共享还可以使用 \\server\share\notes.txt 这样的 UNC 路径。微软的文件命名与命名空间文档介绍了这些约定及不同命名空间。
许多 Windows API 或运行时可以接受正斜杠，但支持范围要看实际调用。命令行工具可能先把 / 当成选项，特殊命名空间又可能有自己的处理规则。一个文件 API 接受 C:/notes.txt，不能推导出所有安装器、脚本和第三方程序都接受同样写法。
所以跨平台库应尽量在内部保留路径对象，在真正调用外部接口时才转换为它需要的表示。用字符串替换统一所有输入，很容易把 UNC 前缀、URL 或本来就合法的文件名一起改坏。
阅读历史资料时也要区分事实与解释。公开的 MS-DOS 源码仓库可以帮助研究当时实现，但某个版本怎样解析参数，不等于后来所有 Windows 接口的行为。现代程序应以自己调用的 API 文档和测试为准。
C: 后面有没有反斜杠，会改变意思
C:\work\notes.txt 从 C 盘根目录出发；C:work\notes.txt 则是驱动器相对路径，需要结合该驱动器的当前目录解释。后者看起来带盘符，却不是完整绝对路径。Windows 文件路径格式对这种差异有专门说明。
这会影响后台任务和命令行程序。同一段字符串在交互终端正常，放进服务进程后找不到文件，可能只是当前目录不同。程序应明确规定相对路径以配置目录、工作目录还是调用者提供的根目录为基准，而不是任由启动方式决定。
另一个例子是 \logs\today.txt：它以当前驱动器的根为起点，却没有指定驱动器。若希望配置可重复，不应让这种隐含上下文进入重要数据路径。
报错日志可以同时记录原始配置值、解析后的路径和当前工作目录，便于定位。涉及用户目录或敏感项目名时，先做必要脱敏。只输出“文件不存在”，会迫使排查者重新猜测程序当时从哪里开始找。
字符串转义是另一层规则
Python 源码里的普通字符串、JSON 文本和用户在文件选择器中选出的路径，来源不同。写进源码时，反斜杠可能引入转义；通过操作系统接口得到的字符串，则已经是一段运行时数据，不需要再按源码字面量解读一次。
例如 JSON 中要用转义表达反斜杠。手工拼 JSON 容易产生非法文本，使用标准序列化器可以避免反复计算应该写几个 \。把序列化后的字符串再次当作路径使用，也会把额外转义带入文件名。
Python 的原始字符串方便表达某些 Windows 路径，但仍有语法限制，例如不能用单个反斜杠结束原始字符串。语言细节应查字符串字面量文档，不要把 r 前缀理解成“这个字符串不再有任何规则”。
下面示例只解析 Windows 风格的路径，不访问磁盘，因此可以在其他操作系统上运行：
from pathlib import PureWindowsPath
absolute = PureWindowsPath(r"C:\work\notes.txt")
drive_relative = PureWindowsPath(r"C:work\notes.txt")
print(absolute.is_absolute())
print(drive_relative.is_absolute())
print(absolute.name)
print(absolute.parent)
预期依次得到 True、False、notes.txt 和 C:\work。PureWindowsPath 用于路径语法计算；它不会证明对应文件存在。真正访问当前系统文件时，使用适合本地平台的 Path。pathlib 文档区分了纯路径与实际文件系统操作。
在 Linux 上处理 Windows 路径，要明确指定语法
服务端有时会接收另一台机器上传的日志。假设日志里的文件位置是 Windows 路径，而解析程序运行在 Linux：直接使用当前平台的路径函数，未必会把反斜杠识别为分隔符。
Node.js 提供 path.win32 和 path.posix，可以显式选择语法。下面用 Windows 规则提取文件名，不依赖运行脚本的平台：
const path = require('node:path');
const input = String.raw`C:\work\notes.txt`;
console.log(path.win32.basename(input));
console.log(path.win32.join('C:\\work', 'drafts', 'notes.txt'));
这里预期输出 notes.txt 与 C:\work\drafts\notes.txt。实际项目若是在操作本机文件，通常使用默认 path；若在解析另一种平台的记录，才显式选 win32 或 posix。函数行为见 Node.js path 文档。
测试快照也应该反映这一区别。你测试的是路径的语义，还是某个平台下的显示格式？前者可以比较路径组成部分，后者就应明确运行平台。把一个平台生成的完整绝对路径写进共享快照，容易因用户目录和分隔符差异产生无意义失败。
路径参数不要先拼成一整条命令
调用外部程序时，路径包含空格、括号或其他特殊字符很常见。若先拼接成一段命令，再交给 shell 解释，程序需要同时处理路径语法和 shell 引号规则。来自用户的内容还可能改变命令含义。
使用提供参数数组的进程 API，可以把“可执行程序”和“每一个参数”分开传递。Python 的 subprocess.run 等接口提供这种形式，具体行为仍要结合平台和是否启用 shell，参见官方 subprocess 文档。
对 Windows 批处理、PowerShell 和普通可执行程序，不能假定引号处理完全一致。需要调用脚本时，先确定由哪个解释器运行，再针对真实输入测试，而不是复制一段 Bash 的转义方法。
文件名以连字符开头时，还要考虑目标工具是否把它当选项。参数数组能够减少 shell 解析问题，但不会改变工具本身的选项语法。支持结束选项标记的命令可按文档使用，其他工具则需要自己的处理方式。
URL 应交给 URL 工具生成
本地路径 C:\images\a b.png 与网页地址不是同一种对象。把路径中的反斜杠换成正斜杠，仍没有处理空格、井号、编码、主机名和协议。尤其是 # 在 URL 中可能成为片段分隔符，直接拼接会指向另一个位置。
需要生成文件 URL 时，使用语言提供的转换函数，例如 Node.js 的 pathToFileURL；需要生成网站资源链接时，则以网站 URL 为基础，按服务的路由和编码规则构造。相关说明见 Node.js URL 文档。
网站上传功能也不应该相信客户端提交的完整路径。服务器通常只需识别允许的文件名和存储位置，在自己控制的目录中创建文件。去掉盘符或调用 normalize，都不能单独证明输入不会逃出目标目录；符号链接、编码和平台规则还需结合实际文件操作检查。
把测试样本从一个文件名扩展到真实输入
最小测试集可以包含带空格的目录、中文文件名、相对路径、驱动器相对路径和 UNC 路径。再加一个不存在的文件，确认错误提示确实指出解析后的目标。若程序允许网络共享或长路径，也应在相应 Windows 环境实际验证。
本文的纯路径例子只证明字符串解析结果，不代表已经在 Windows 上验证文件权限、共享访问或长路径设置。将这些测试层次分开记录，能避免“在 macOS 跑过路径测试”被误传成“Windows 文件操作全部兼容”。
反斜杠只是最容易被看见的差异。处理好当前目录、命名空间、转义和外部工具参数后，跨平台错误通常会少得多；排查时也能明确知道，是哪一层把同一段字符解释成了不同的意思。