模型 JSON 里的路径和正则反斜杠，为什么多解码一次就变了内容

路径从模型结果读出以后变短了，正则里的反斜杠不见了，经常不是模型漏写，而是客户端又做了一次转义解码。JSON 文本里的双反斜杠与内存字符串里的一个反斜杠并不矛盾。先把源文本、内存值和显示表示三个层次分开，才能判断哪一步改了内容。

一次 JSON 解析已经解释转义

附件有 Windows 风格路径、包含字面 \n 的正则片段，以及真正包含换行的备注。它们通过标准序列化生成 JSON，再读取一次，预期与原始 Python 字符串逐字相同。控制台的 repr 或 JSON 导出会再次显示转义，这是为了让内容可读，不表示内存中增加了字符。

例如字面反斜杠与 n 是两个码点，真实换行是一个控制码点。肉眼看日志时可能混淆，检查器直接比较码点列表和字符串长度。路径里如果真的含制表符，不能仅凭“看起来对齐”判断为正常；它与反斜杠加 t 是不同的数据。

二次解码为什么危险

对已经解析出的字符串再运行 unicode_escape，可能把字面 \n 变成真正换行，或把路径中的片段当作转义。附件只在受控反例里演示这个变化，并断言它与原值不再相同。不是所有字符串都需要第二次解码；只有合同明确说字段内部承载另一层编码文本，才应由专门解析器处理。

失败反例是全局执行 replace('\\','\') 来“修 Windows 路径”。它可能碰巧修好一个展示复制错误，同时破坏原本有效的正则和网络路径。一个没有语法上下文的替换函数无法知道哪些反斜杠是数据、哪些是编码标记。

用往返和码点验收

检查顺序是保留收到的 JSON 字节、标准解码一次、按字段合同验证，再标准序列化回读。正常输入需要保持值相等；不要求序列化后的原文字节完全一致，因为空白和转义写法可以变化。若业务要求字节签名，则要另外固定规范化策略，不能混用值相等和字节相等。

非法转义应由 JSON 解码报错，不在失败后盲目补斜杠。共享诊断时保存安全转义展示与明确层次，注明“这是源文本”或“这是内存值的展示”，能减少维护者复制日志时制造新的编码层。

本文只做本地文本转换，路径不会被打开，正则也不会用于扫描真实文件。即使字符串保真，路径权限、允许目录和正则运行资源仍需另验。检查通过代表转义层数符合合同，不代表某个操作系统路径一定存在，也不证明模型理解了正则含义。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a024.json，离线检查器 a024.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a024.py。

一手资料1；一手资料2。资料核对日期：2026-10-24。