上个月月底的事。客户是做仓储的，后台里有个订单列表，按日期筛。测试全过，上线第二天客服在群里甩截图，说选了 9 月 30 号，出来少了凌晨那几单，白班的人以为丢单了。
我第一反应是后端。筛选条件就是前端拼个字符串传过去，能有我什么事。群里 @ 了后端那哥们，他说他收到的就是 2026-09-30，没毛病，参数干净得很。
行吧那就是前端。本地跑一遍，本地是对的。这种本地对线上不对的最烦，一眼就是环境的事，但你问是什么环境的事，不知道。
我先猜时区。查了下，服务器跑 UTC，我这儿东八区。可日期字符串我又没做转换，直接传的，怎么会差。
磨到十一点半，我把那段来回看了好几遍，只有一个地方可疑：用户选完日期我用 new Date() 包了一下，为了比较大小。就这一下。
把这行扔给 AI，问它 new Date('2026-09-30') 拿到的是啥。它讲了一大段，什么 IOS 格式（打错了，ISO）、UTC 零点、本地时间，我头一遍没看进去。又回去翻 MDN，Date 那页我啃过不止一遍，每次都记不住。这回总算记住一条：new Date('2026-09-30') 这种只有日期的字符串，规范里是按 UTC 解析的；带 T 后面那串时间的，才按本地解析。就差那个 T。
所以我这边拿到的是 UTC 的 30 号零点，转成本地就是 30 号早上八点。我拿它当左边界去比，凌晨那几单的时间戳比它小，就被筛掉了。方向反了没有……没有，就是这么回事。当时脑子已经不转了，还跟自己绕了一会儿。
改法很简单，字符串别拿 new Date() 包，要么直接比，要么老老实实拼上 T00:00:00。我选了后者，因为还要比大小。改完发上线，两点零几分。
第二天客服没再吭声，应该是好了。
有句话我到现在没完全搞明白。AI 说规范这么定是为了兼容早期实现，这句我在 MDN 上没找到对应的段落，也可能是那页太长我漏了。反正结论能用，我先用了。估计再撞一次就彻底记住了，也可能不记得。
今日单词：offset，偏移。这词我在时区文档里见过至少五次，每次都要重新查一遍。行吧。