数据库中存储的JSON字符串因反斜杠未正确转义（如 "C:" 而非 "C:\"）导致前端 JSON.parse() 失败；根本原因在于数据写入阶段未使用标准JSON序列化，而非法手动拼接——修复需从源头杜绝，而非在损坏数据上打补丁。
数据库中存储的json字符串因反斜杠未正确转义（如 `"c:"` 而非 `"c:\"`）导致前端 `json.parse()` 失败；根本原因在于数据写入阶段未使用标准json序列化，而非法手动拼接——修复需从源头杜绝，而非在损坏数据上打补丁。
该问题表面是“JSON解析失败”，实则是数据生成阶段的结构性缺陷。原始字符串 {"MountPoint":"C:"} 在JSON语法中非法：反斜杠 是转义字符，单独出现在引号内（如 " 表示双引号，\ 表示单个反斜杠），而 C: 中的 后无合法转义目标（如 n, t, " 或 \），因此整个字符串不符合JSON规范。浏览器网络面板中看到的 "[{"MountPoint":"C:\", ...}" 实际是Java JSONObject.toString() 对已损坏字符串的二次错误转义结果，进一步加剧了解析崩溃。
✅ 正确解决方案：从源头重建合规JSON
绝对禁止通过字符串拼接、StringBuilder.append() 或正则替换等方式“修补”JSON。以下为推荐实践：
-
Java端序列化必须使用标准JSON库
使用如 Jackson、Gson 或 org.json（正确用法）等库，确保自动处理转义：// ✅ 正确：由库自动转义 ObjectMapper mapper = new ObjectMapper(); String json = mapper.writeValueAsString( List.of(Map.of("MountPoint", "C:\", "FreeSpace", "18 GB")) ); // 输出: [{"MountPoint":"C:\","FreeSpace":"18 GB",...}] -
数据库层重构存储结构
-
首选方案：改用原生JSON类型（如 PostgreSQL 的 JSONB 列），避免VARCHAR存JSON：
ALTER TABLE servers ALTER COLUMN disk_info TYPE JSONB USING disk_info::jsonb;
-
更优方案：拆分为关系型字段（符合范式）：
ALTER TABLE servers ADD COLUMN mount_point TEXT, ADD COLUMN free_space TEXT, ADD COLUMN total_capacity TEXT, ADD COLUMN total_bytes BIGINT, ADD COLUMN free_bytes BIGINT;
-
首选方案：改用原生JSON类型（如 PostgreSQL 的 JSONB 列），避免VARCHAR存JSON：
⚠️ 临时应急（仅限历史数据抢救）
若已存在海量损坏数据且无法重写源头，且100%确认所有反斜杠均意图为字面量 （且无任何字段含双引号），可执行SQL批量修正：
-- PostgreSQL示例（注意：仅当无嵌套引号时安全） UPDATE servers SET disk_info = REPLACE(disk_info, '', '\') WHERE disk_info ~ '"MountPoint"s*:s*"C:\';
但此操作风险极高：若某条记录含 {"Name":"O"Reilly"}，REPLACE 会将其破坏为 O\"Reilly，导致更严重错误。
? 关键原则总结
- 永远不要手写JSON：JSON看似简单，但转义规则（, ", /, Unicode等）极易出错，专业库已覆盖全部边界情况。
- 存储即语义：VARCHAR存JSON = 放弃数据库查询能力（无法高效按 FreeBytes
-
防御性验证：在数据入库前校验JSON有效性：
try { new JSONObject(dirtyString); // org.json 验证器 } catch (JSONException e) { throw new IllegalArgumentException("Invalid JSON input", e); }
真正的健壮性不来自事后修复，而源于设计阶段对格式规范的敬畏——让机器（库）做它最擅长的事，让人专注业务逻辑。
