经验分享时间戳时区URL编码JSONHTTP状态码
一次线上“时间不一致”事故：我用几个小工具查清真相
有一天用户在群里说“你们的订单时间不对”。截图一看，确实不一致：列表页是一个时间，详情页又是另一个时间。我负责先把问题“说清楚”，于是开始沿着数据流排查。
第一步：先把可见的都收集起来
我让用户把“列表页”和“详情页”的截图一起发来，并附上“点击详情时地址栏的完整URL”。我拿到 URL 以后，先把查询串丢进在线的 URL 编解码工具里看一眼，检查是否有被二次编码的参数。结果显示：参数本身没问题，中文与特殊字符都正常编码。
第二步：接口返回的 JSON 到底是什么样
接着我打开接口调试工具，把响应 JSON 粘贴到在线 JSON 格式化校验里。一来检查语法，二来看字段是否齐全，三来看时间字段是什么单位。这里就发现了第一个线索：有的接口返回 timestamp 是 13 位（毫秒），另一个接口返回的是 10 位（秒）。
第三步：把时间戳互转成“看得懂的时间”
我把两个时间戳分别放入“时间戳互转”工具，确认 13 位是毫秒、10 位是秒；然后分别看“本地时间”和“UTC时间”的对应值。很快就能对应截图上的显示差异：列表页使用了毫秒，详情页被当成秒处理，显示就偏差了。
第四步：时区与格式模板的双重确认
虽然单位查出来了，但我还是做了双重确认：把两个时间都转换成 UTC 与本地时区对照，确认不是时区导致。接着看了下页面的格式化模板，确认格式化没有做额外的偏移。至此，基本坐实“单位不一致”。
第五步：和后端同学对齐，补一条‘状态码说明’
为了让问题收敛更快，我把接口的 HTTP 状态码和响应一起粘贴到状态码说明页去核对。状态码是 200，响应链路没问题，所以问题主要在数据语义。我把这一整套核对过程整理到 issue 里，后端同学一眼就能对齐。
结尾：我的固定排查套路
- URL 参数先过一遍编码检查；
- JSON 响应先格式化校验，再看字段单位；
- 时间戳互转确认“秒/毫秒、本地/UTC”；
- 不确定的地方用状态码说明做一次“非问题项”排除；
- 最后把步骤写清楚，方便更多人复用。
这类问题的难点不是“算法”，而是“细节一致性”。用几个合适的小工具，能让排查又快又稳。