JavaScript Date 对象易出错主因是隐性规则：月份从 0 开始（getMonth() 返回 0–11）、字符串解析不一致、时区处理复杂；应避免 new Date(string)，优先用参数构造或 ISO+Z 格式，序列化用 toJSON()/toISOString()。
JavaScript 的 Date 对象本身不难，但日期操作容易出错——不是因为方法记不住，而是因为时区、月份从 0 开始、字符串解析不一致这些隐性规则没踩准。
getMonth() 返回 0–11，不是 1–12
这是最常踩的坑：调用 getMonth() 得到的是 0 表示一月，11 表示十二月。直接拼接成 "2024-12-25" 这类格式时，如果没加 +1，十一月会变成 10，但用户看到的是“10月”，实际是十一月。
- 正确写法：
date.getFullYear() + '-' + (date.getMonth() + 1).toString().padStart(2, '0') + '-' + date.getDate() - 错误写法：
date.getFullYear() + '-' + date.getMonth() + '-' + date.getDate()（一月变成 0） - 注意：
getUTCMonth()同样返回 0–11，只是基于 UTC 时间
new Date(string) 解析行为不可靠
传入字符串构造 Date 对象时，不同浏览器对格式容忍度不同。比如 new Date("2024-01-01") 在 Chrome 中是 UTC 上午，Safari 可能按本地时区解释；而 new Date("01/01/2024") 在某些地区会被当成“日/月/年”解析，导致错乱。
- 安全做法：用明确参数构造，如
new Date(2024, 0, 1)（注意月份是 0） - 若必须解析字符串，优先用 ISO 格式且带时区，如
"2024-01-01T00:00:00Z"（末尾Z表示 UTC） - 避免使用
new Date("2024/01/01")或new Date("01-01-2024")，解析结果不确定
getTime() 和 getTimezoneOffset() 配合处理时区偏移
getTime() 返回毫秒数（UTC 时间戳），而 getTimezoneOffset() 返回当前环境与 UTC 的分钟差（注意：东八区返回 -480，即比 UTC 快 480 分钟）。两者结合才能做跨时区时间计算。
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
立即学习“Java免费学习笔记（深入）”；
- 获取当前 UTC 时间戳：
new Date().getTime()（没错，它本来就是 UTC 毫秒数） - 把本地时间转为 UTC 小时：
new Date().getHours() - new Date().getTimezoneOffset() / 60 - 注意：
setHours()等 setter 方法操作的是本地时间，不是 UTC —— 如果想设 UTC 小时，要用setUTCHours()
toJSON() 和 toISOString() 是序列化首选
需要把日期发给后端或存 localStorage 时，别用 toString() 或 toLocaleString()，它们依赖本地环境，格式不统一。应该用 toJSON()（内部调用 toISOString()）输出标准 ISO 8601 字符串。
-
new Date().toJSON()→"2024-05-20T08:30:45.123Z" -
new Date().toISOString()→ 同上，二者行为一致 - 反向解析时，
new Date("2024-05-20T08:30:45.123Z")总是按 UTC 解析，可靠 - 不要用
JSON.stringify(new Date())以外的方式手动拼 ISO 字符串，容易漏掉毫秒或时区
真正麻烦的不是方法少，而是每个方法背后都连着时区、本地化、历史兼容性三根线——稍一松手就打结。尤其在表单提交、定时任务、跨系统时间比对这些场景里，漏掉 +1 或误信字符串解析，问题往往隔几小时才暴露。
