JSON文本可以写出-0，但某些工具重新输出时会把它写成0。这类现象涉及数字解析与序列化的表示规则，不能仅凭字符改变就认定计算错误。本文在KKCE工作区把数字负零和文本负零放在一起，观察两者的处理差异。
先确定你要保存的是数字还是写法
本轮输入delta为数字-0，text为带引号的"-0"。前者让解析器按数值读取，后者要求保存两个字符。它们在源文件里很相似，却为下游提供了不同类型的值。如果字段来自仪表、计算结果或财务展示，应先明确业务是否真的需要保留负号，而不是因为原始文本带了负号，就默认所有环节必须输出相同的外观。
官网输出展示了什么
执行格式化后，演示中的数字字段写成0，而字符串字段仍保持"-0"。截图展示的是重新输出的文本，不能反推解析器内部一定怎样保存。以JavaScript为例，运行时能够区分正零与负零，但常规JSON序列化会把数值负零写为0；这个过程不等同于任意改动了所有负数，也不能推广到每一种语言或定制序列化库。
别用全局替换制造负号
如果接收方只关心数学上的零，把两种写法视为同一数值可能符合合同；如果原始表示具有审计含义，应额外保留输入文本或专门的符号信息。不要在格式化结果中搜索所有0再替换成-0，这会改变其他字段，也无法知道哪些零原本带符号。先给字段建立清晰的语义，再选择能表达这项语义的数据结构。
将特殊值纳入往返检查
在项目自己的解析器中同时测试0、-0、小幅负数及字符串版本，记录读取类型、内部比较和再次输出的结果。数值比较相等与文本逐字相同是不同的验收目标，应由使用场景决定采用哪一个。KKCE可以提供一个直观的观察样例；若涉及计算方向、符号位或原文归档，仍需使用部署端的专用检查方法验证相关性质。
演示说明：演示使用构造字段。页面输出的零值表示不能替代对运行时符号位或业务计算规则的检查。
功能入口：JSON格式化。
