企业官网建设流程全解析

前一阵我在做一个日程倒计时类的内部工具，页面顶部需要把日期显示成“2026年08月27日星期四”这种完整的中文格式。乍一看，这需求简单到像是实习生拿来练手的：年、月、日、星期几，各自取出来拼一块儿不就行了？可真把代码写下去才发现，日期字符串背后全是暗坑：时间存的是 UTC，界面要的是本地时间；有人传YYYY-MM-DD，有人传时间戳；同一个toLocaleDateString，在不同浏览器里输出顺序还不一样。借着这次开发，我把从时间模型到格式化、再到跨端事故的完整链路重新捋了一遍，给也在写日历、排期、倒计时页面的朋友一份可以直接参考的答案。

1. 这串日期看似简单，先分清“日期”和“时刻”再说

1.1 页面里的中文日期，信息密度比看着高

2026年08月27日星期四。平时一扫而过，但拆开看，这串文案其实包含了两类信息：年月日是绝对定位，它告诉你“具体是哪一天”；星期四是周期定位，它告诉你“这是本周的第几个工作日”。很多排期系统只写“2026-08-27”，用户还得自己反应一下今天是周几；另一些任务清单只写“周四”，脱离当前上下文后人就懵了。两者拼在一起，信息才算完整。

从产品设计角度看，这种完整日期并不适合所有位置。消息流里的时间更适合“3分钟前”“昨天”；表格里的截止时间更适合“2026-08-27”；但在页头、日历标题、合同签署栏这类需要用户确认“当前处于哪个时间点”的地方，年月日加星期就是最稳的表达。它牺牲了一点紧凑性，换来了零歧义。我在那个日程工具里就选了这种完整格式，因为用户常会把页面截图发给同事，图里如果只写“08/27”，没人知道是哪一年。

1.2 需求的本质不是“拼字符串”，而是先定义一个日期模型

开始写代码前，先问自己一个问题：后端给我的是一个时间戳，还是一个日期字符串？这决定了后面所有代码的写法。

这里需要区分两个概念：日期和时刻。日期对应日历上的一个格子，比如2026年8月27日；时刻对应时间轴上的一个瞬间，比如2026年8月27日10时30分00秒，它带有时区属性。同一个瞬间，在东八区看是8月27日的上午，在UTC-5时区看可能还是8月26日的晚上。如果你只想表达“某一天”，却用了时刻的数据类型，跨时区后就可能出现日期偏移。

这个工具要展示的是一个目标日，本质上是日历概念。我做的第一件事就是跟后端