我分两段把上下游完整链路拆开，你就能明白问题在哪：
1. 上游发给你的数据（网络传输时）
上游对外输出 JSON：
json
"files":"[{\"datatype\":\"离线\"}]"网络上确实是带转义、外层双引号包裹的字符串，符合对方说的 “转义后的”。
2. 数据到你服务，存入变量String files
当你的接口接收完参数、框架解析 JSON 后： 内存里files字符串的值变成：[{"datatype":"离线"}]所有转义斜杠 \ 全部消失了。 原因：JSON 解析器会自动剥离外层引号、还原内部转义字符，拿到原始文本。
举个通俗例子： 网络报文"[{\"a\":\"1\"}]"→ 程序解析成 Java 字符串后，内存只存[{"a":"1"}]，不存在任何 \。
3. 你直接inputs.put("files", files)再序列化发下游
fastjson 扫描到你的字符串内容[{"a":"1"}]是标准数组格式，自动把这个字符串翻译成 JSON 数组输出：
json
"files": [{"datatype":"离线"}]外层引号没了，从字符串变成数组，下游接口不认。
核心矛盾
上游给你的是传输态带转义字符串； 但你程序内存拿到手，已经是无转义的数组文本； 直接丢 fastjson 序列化会自动拆包成数组，无法原样转发。
必须多一步的原因
想要重新输出"files":"[{\"datatype\":\"离线\"}]"，就要把内存里的数组文本再做一次 JSON 序列化，重新生成带转义的字符串：
java
运行
// 复用你代码里已经解析好的fjlist inputs.put("files", JSONArray.toJSONString(fjlist));这一步是把[{"datatype":"离线"}]这段文本，重新包装成\"[{\\\"datatype\\\":\\\"离线\\\"}]\"这种传输用的转义字符串，抵消框架自动解包的行为。
一句话总结
上游网络报文是带转义字符串，但经过你的接收框架解析后，转义符、外层引号全部被脱掉；fastjson 序列化又自动还原成数组，所以你不重新转一次，永远达不到下游需要的格式。不存在不转换直接透传的方案。