最稳妥方案是用 setInterval 配合 toLocaleDateString 动态更新日期，首屏手动调用、DOM 加载后初始化，并为旧浏览器提供手写格式化降级。
用 setInterval 配合 toLocaleDateString 最稳妥
直接写死时间没意义，动态更新必须靠定时器。但别用 setInterval(() => { document.getElementById('time').innerText = new Date() }, 1000) 这种原始拼接——格式难控、时区错乱、中文显示不友好。toLocaleDateString 能自动适配用户本地格式，包括年月日顺序、分隔符、是否补零。
实操建议：
- 用
new Date().toLocaleDateString('zh-CN')得到类似"2024年6月12日"的字符串，无需手动拼接 - 定时器间隔设为
1000毫秒即可，不需要更短；时间变化只发生在整秒，高频刷新纯属浪费 - 首次渲染别等定时器触发，先手动调用一次更新函数，避免页面刚打开时空白
- 如果只要年月日（不含星期），传参加
{ year: 'numeric', month: 'long', day: 'numeric' }更精确，避免某些系统默认带星期
document.getElementById 失效？检查 DOM 加载时机
常见错误是脚本放在 <head> 里，一执行就报 Cannot set property 'innerText' of null——因为 DOM 还没生成，getElementById 找不到元素。
解决办法只有两个：
立即学习“前端免费学习笔记（深入）”；
- 把
<script>标签移到</body>前，确保 DOM 已就绪 - 或者用
DOMContentLoaded事件包裹初始化逻辑：document.addEventListener('DOMContentLoaded', () => { const el = document.getElementById('date'); if (el) updateDate(); setInterval(updateDate, 1000); });
需要兼容旧浏览器？避开 toLocaleDateString 的坑
IE11 支持 toLocaleDateString，但参数对象（如 { year: 'numeric' }）不支持；Safari 旧版本对 'zh-CN' 语言标签响应不稳定。真要保底，得手写格式化逻辑。
简易 fallback 方案：
- 先尝试
toLocaleDateString('zh-CN', options)，捕获异常再降级 - 降级时用
date.getFullYear()、date.getMonth() + 1、date.getDate()拼接，注意月份从 0 开始 - 手动补零：用
String(date.getDate()).padStart(2, '0')，IE 不支持padStart就改用(date.getDate()
为什么不用 moment.js 或 dayjs？
单纯显示年月日，引入整个日期库是过度设计。它们的体积（moment 50KB+，dayjs 2KB+）和额外依赖，对静态时间展示毫无必要。原生 API 完全够用，且无兼容性包袱（除上面提到的参数对象外）。
只有当你需要解析任意格式字符串、跨时区计算、相对时间（如“3小时前”）时，才值得引入第三方库。否则就是给简单问题叠复杂度。
真正容易被忽略的是：用户可能手动修改系统时间，或设备休眠后唤醒，setInterval 不会自动校准。如果精度要求高（比如倒计时），得在每次触发时重新调用 new Date()，而不是靠累加毫秒数。
