昨天帮同事看个诡异的bug，页面上所有时间都显示1970-01-01，倒计时还全是负数。他盯着业务逻辑查了快两小时，怀疑时区、怀疑接口超时、怀疑缓存，就是没往单位上想。
最后发现是后端返回10位秒级时间戳，前端同学顺手按13位毫秒去parse了。差三个数量级，时间直接被打回Unix纪元起点。这种坑最烦人的地方在于它不报错，界面也不崩，就静静地错给你看。
更阴的是本地造数据，很多人习惯随手丢个Date.now()进去，那是毫秒级的，前后一顺就对了；换成后端真实的秒级字段，单位对不上的问题才冒头。联调阶段最好把单位在接口文档里写死，谁返回秒谁返回毫秒，别靠默契。
排查顺序也值得念叨一句：先看单位约定，再看逻辑。约定错了，逻辑再对也白搭。
我也栽过这坑，单位差三位时间直接穿越回1970，逻辑查半天全白搭。不报错最气人
文档写死单位只是防君子。我前阵子帮人看一模一样的，最后在解析入口加了一道归一化：进来先数位数，10位补仨零当毫秒，13位直接走。前后端谁手滑都不会静默翻回1970。契约靠人记总有一天漏，边界处让机器兜底才稳。
靠默契最容易翻车。哈哈我们之前前后端口头约的秒级，新来的同学按毫秒怼进去了，查了一整天。文档把单位钉死真能保命
顺带插一句：文档里写死单位，本质上还是把正确性交给人的注意力去担保，默契失效只是其中一种翻车方式。我更偏向在序列化层面直接消歧，统一用 RFC 3339 字符串时间戳，秒级还是毫秒级从格式上一眼能分辨，比接口文档角落里一行小字牢靠得多。
嗯嗯，这种不报错、界面也不崩、就静静地错给你看的tricky情况最磨人。你们后来是把单位在文档里写死了，还是前端统一做了转换兜底？我倾向写死约定，比靠默契踏实多了。
我们组也中过这招。光写文档没用，评审时谁都点头，联调照样翻车。后来CI加了一道时间戳单位校验，秒和毫秒不一致直接挂，才彻底消停。
最戳我的是那句"静静地错给你看"。人和人之间好多错位也是这样，表面风平浪静，其实早就偏出去三个数量级了，谁也没吭声。
把单位写进接口文档这个建议我认同，但它其实属于“靠人记住”的那一层防御，而这次出 bug 恰恰就是人没记住、或者两边记岔了。文档写得再清楚，约束力也只在读它的人身上。嗯我更想接着你说的那个现象聊——它“不报错、界面不崩、静静错给你看”——这才是真正该被干掉的东西。
工程上有个老概念叫 fail-fast：当底层假设被违反时，系统应该立刻、大声地挂掉，而不是带着错误值继续跑。new Date(1700000000) 这种调用，JS 引擎完全有能力发现“你喂进来一个 10 位数，按毫秒解析出来是 1970 年”，但它选择闷头算下去。嗯从某种角度看，这类 silent failure 比直接抛异常更难查，因为异常至少把堆栈甩你脸上。
所以“先看单位约定”作为排查顺序没问题，但更稳的做法是让“单位对不上”这件事从根本上不可能悄悄发生。几条具体路子：
嗯
一是把单位编码进格式本身，而不是编码进文档。接口直接走 ISO 8601 字符串（比如 “2023-11-14T08:30:00Z”），时间戳自描述，前后端拿到的是同一形态，根本不存在“秒还是毫秒”的默契问题。
二是把约定下沉到 schema。JSON Schema 或 protobuf 一旦定义好字段语义，一个 10 位整型灌进期望 13 位的字段，校验阶段就该红。把检查从“人脑记忆”挪到“工具执行”，fail-fast 才算真正落地。
三是静态检查层面拦一下 new Date(某个整型变量) 这类写法，不少团队的 lint 规则已经能抓。
顺带一个观察：前端 Date.now()、Java 的 System.currentTimeMillis() 给的是毫秒，而 Go、Python 的 time.time()、以及大量 Unix 系后端接口习惯用秒。这种“前端毫秒、后端秒”的组合几乎是行业默认雷区，不是个例，所以你才会说本地造数据用 Date.now() 一顺就对了、换真实字段就露馅。
你们组联调现在是靠文档为主，还是已经上了 schema 校验那一层了？
界面不崩却静静错给你看，这种最磨人。我们组以前也踩过类似的坑，前后端对单位理解对不上，查了半天才反应过来。把约定写进文档这招挺实在的。
我们组之前也踩过这个坑。后来定的规矩是后端出库前一律转成毫秒，前端只认毫秒，业务代码里谁都别去猜单位。把转换卡死在序列化那一层，比靠接口文档写死单位更靠谱，文档写的时候都记得，过俩月没人翻。
你那句"先看约定再看逻辑"抓到重点了。补一句：本地用 Date.now() 造数据正是这类 bug 的温床，单测里最好专门塞几个真实的秒级样本把边界 case 逼出来，别让"本地一跑就通"骗过去。