前端开发中日期时间使用容易引起的bug

· 月份从0开始计算

new Date().getMonth() 获取的月份是从0开始算的，因此实际使用要+1

· 日期时间解析兼容

iOS系统仅支持特定格式的日期字符串解析，包括：

"yyyy-MM-ddTHH:mm:ss+HH:mm"（带时区）
其他格式（如 "yyyy-MM-dd HH:mm:ss"）在部分iOS版本中会解析失败或返回 Invalid Date

"yyyy/MM/dd"

"yyyy/MM/dd HH:mm:ss"

"yyyy-MM-dd"

"yyyy-MM-ddTHH:mm:ss"（ISO 8601）

解决方案：可以使用 “/” 替换 “-‘’ 解决。也可以使用 new Date(year, month, day) 构造函数

        // const str = '2012-1-16 00:00:00'
        const str = '2012-1-16 00:00:00'.replace(/-/g,'/')  //解决ios解析 date 不支持 - 号的问题
        const t = new Date(str)
        const y = t.getFullYear()
        const m = t.getMonth() + 1
        const d = t.getDate()
        alert(d)

· new Date(dateString)解析差异

分隔符 - 和 / 的区别，new Date() 的解析策略就完全不同。前者（YYYY-MM-DD）被当作 UTC 时间，而后者（YYYY/MM/DD）被当作本地时间。

8小时差异（东八区示例）：‌ 在东八区环境下，new Date('2025-03-11') 代表的是北京时间 3月11日 08:00，而 new Date('2025/03/11') 代表的是北京时间 3月11日 00:00。两者相差 8 小时‌

‌推荐做法：‌

• ‌一致性：‌ 在项目中统一使用一种日期字符串格式进行解析。
• ‌明确意图：‌ 如果业务逻辑需要处理本地时间，使用 YYYY/MM/DD 格式更直观；如果需要处理不考虑时区的绝对日期或UTC时间，优先使用 YYYY-MM-DD 格式。
• ‌避免歧义：‌ 最可靠的方式是始终 ‌包含具体的时间部分‌（YYYY-MM-DDTHH:mm:ss 或 YYYY/MM/DD HH:mm:ss）并明确指定时区（例如 Z 表示 UTC 或 +HH:mm），这样可以完全消除解析歧义‌

· 日期时间有效性

当日期时间不合法，格式化会提示Invalid Date，正确的做法应该是先判空符合再格式换。

日期分隔符可用-、/、.或空格（如 2025.07.18）

· 注意单位转换

• 问题：时间戳的单位通常是毫秒，但在某些情况下可能会误以为是秒。
• 解决方案：确保在处理时间戳时，单位一致。如果需要转换，可以使用 Date.now() 获取毫秒级时间戳，或者 Math.floor(Date.now() / 1000) 获取秒级时间戳。