JavaScript日期对象创建应避免字符串解析，优先用new Date(年,月,日)或带时区的ISO格式；加减操作推荐毫秒计算；格式化用toLocaleDateString；注意时区差异，UTC时间需用getUTC系列方法。
JavaScript 日期对象创建容易出错，别直接传字符串
用 new Date('2024-10-05') 看似方便，但不同浏览器解析行为不一致：Safari 和旧版 Chrome 可能按 UTC 解析，而 Firefox 按本地时区。结果同一天在不同设备上得到的小时数可能差 8 小时。
- 稳妥做法是显式拆解年月日：
new Date(2024, 9, 5)（注意月份从 0 开始） - 若必须解析字符串，优先用 ISO 格式加时区标识：
new Date('2024-10-05T00:00:00+08:00') - 避免
new Date('10/05/2024')这类本地格式，IE 直接报Invalid Date
日期加减要用毫秒计算，别改年月日字段
直接修改 date.getFullYear() 或 date.setDate() 看似直观，但跨月、跨年时容易忽略边界（比如 1 月 31 日加一个月，不是 2 月 31 日，而是 3 月 3 日）。正确做法是统一转成毫秒操作。
- 加 7 天：
date.setTime(date.getTime() + 7 * 24 * 60 * 60 * 1000) - 减 1 个月（近似）：
date.setMonth(date.getMonth() - 1)—— 这个可以，但仅限“月”单位；天/小时/分钟必须用毫秒 - 注意
setTime()会改变原对象，如需保留原值，先new Date(date.getTime())拷贝
格式化推荐 toLocaleDateString 而非手拼字符串
手动拼 date.getFullYear() + '-' + (date.getMonth()+1) + '...' 不仅冗长，还容易漏补零、错判时区、不支持国际化。现代浏览器都支持 toLocaleDateString 的选项参数。
- 中文格式（年月日）：
date.toLocaleDateString('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit' })→"2024-10-05" - 带时间（24 小时制）：
date.toLocaleString('zh-CN', { hour12: false, hour: '2-digit', minute: '2-digit' }) - 注意：
en-US下默认是10/5/2024，而zh-CN是2024/10/05，别依赖默认行为
时区处理最常被忽略，new Date() 总是本地时区
new Date() 创建的对象，其内部时间戳是 UTC，但所有 getter 方法（getHours()、getDate()）返回的是当前系统时区的值。这意味着同一时间戳，在北京和纽约调 getHours() 会得到不同数字。
立即学习“Java免费学习笔记（深入）”；
- 要获取 UTC 时间，必须用
getUTCHours()、getUTCDate()等方法 - 后端通常存 UTC 时间戳，前端显示时应先转成本地时间（用 getter）或按用户偏好时区（需
Intl.DateTimeFormat配置timeZone） - 调试时别只看
console.log(date)的输出字符串——它自动转成本地格式，掩盖了真实时间戳
时区和字符串解析这两块，最容易在线上环境突然暴露问题，尤其当用户分布广、测试机时区固定时。
