Date对象是JavaScript操作日期时间的唯一内置方式，但易因时区、格式化和跨浏览器差异出错；应避免字符串初始化，优先用数值参数；获取时间用getFullYear()等明确方法；UTC时间用getUTCXXX()；存传标准时间用toISOString()或getTime()；复杂运算建议用date-fns等库。
Date 对象是 JavaScript 操作日期和时间的唯一内置方式，没有“替代方案”或“更优选择”——它就是标准，但用起来容易出错，尤其在时区、格式化和跨浏览器行为上。
为什么 new Date() 有时返回 Invalid Date？
常见于字符串解析失败。JavaScript 的 Date 构造函数对字符串格式极其敏感，且各浏览器解析规则不一致。
-
new Date("2024-10-05")在大多数现代浏览器中有效（ISO 8601 格式），但new Date("05/10/2024")可能被解析为 10月5日 或 报错，取决于地区设置 - 避免用字符串初始化：优先用数值参数，如
new Date(2024, 9, 5, 14, 30, 0)（注意月份从 0 开始） - 若必须解析字符串，先校验格式，或用正则提取年月日再传入数值构造器
如何安全获取年月日时分秒？
别直接用 getYear()（已废弃）或 getMonth()（返回 0–11），也别依赖 toString() 的输出格式——它不可控且含时区信息。
- 用
getFullYear()、getDate()、getHours()等明确命名的方法 - 补零需手动：例如
String(date.getDate()).padStart(2, '0')，toLocalString()虽方便但格式不可移植 - 需要 UTC 时间？用
getUTCFullYear()等对应方法，而非先调toUTCString()再解析字符串
时区处理最常踩的坑是什么？
Date 对象内部始终以毫秒数（UTC 时间戳）存储，但所有 getXXX() 方法默认返回**本地时区**值，而 toISOString() 返回 UTC 字符串——这个隐式切换是混乱源头。
根据ui图生成前端页面
下载
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
立即学习“Java免费学习笔记（深入）”；
-
new Date().toISOString()总是 UTC，形如"2024-10-05T06:30:00.000Z"；但new Date().toString()显示本地时间，比如"Sat Oct 05 2024 14:30:00 GMT+0800" - 想存/传标准时间？用
getTime()（毫秒时间戳）或toISOString()，别用toString() - 服务端期望 UTC？前端传
date.toISOString()；服务端返回 ISO 字符串？前端可直接new Date(isoString)解析（只要格式合规）
需要格式化或加减日期怎么办？
原生 Date 不提供日期运算或灵活格式化，硬写容易翻车。简单场景可手写，复杂需求建议用轻量库（如 date-fns），但得清楚边界。
- 加 3 天：
date.setDate(date.getDate() + 3)（会修改原对象）；如不想改原值，先new Date(date)克隆 - 格式化到
"YYYY-MM-DD"：可封装`${d.getFullYear()}-${String(d.getMonth()+1).padStart(2,'0')}-${String(d.getDate()).padStart(2,'0')}` - 别用
setMonth(date.getMonth() + 1)做“加一个月”，遇到 1 月 31 日会跳到 3 月 3 日——月份长度不固定，这是纯逻辑陷阱
真正难的不是“怎么写”，而是意识到 Date 是一个低阶原始类型：它不做假设、不隐藏时区、不自动归一化。你每次调用方法，都得心里清楚当前操作的是本地视图还是 UTC 底层，以及字符串输入输出是否跨了时区边界。
