javascript日期处理函数的一些问题

问题1：new Date(字符串)产生的日期对象，在某些情形下，可能会自动增加1天。猜测是和时区、UTC、GMT有关，浏览器没有默认当前时区？这是一个坑。

new Date(2022, 10, 30); //日期对象是 2022-10-30

new Date(2022, 10, 31); //日期对象是 2022-11-01

 同样的道理，

var d = new Date(2022, 10, 30);//日期对象是 2022-10-30
d.setDate(d.getDate() + 1);
//日期对象变成2022-11-01，而不是预料中的2022-10-31

感觉javascript中setDate函数的实现方式貌似借道new Date()函数，直接把天数加1后产生新对象并把指针指向原来的日期对象。

Date对象相关函数处理和程序员想象中的处理方式不同，是否有点反人类？

 https://stackoverflow.com/questions/2488313/javascripts-getdate-returns-wrong-date

第二个高赞答案说是使用UTC可以解决这个问题，but……事实证明javascript的实现者有点……2B

new Date(2022, 10, 30, 0, 0, 0); //日期对象是 2022-10-30 UTC 08:00

new Date(2022, 10, 31, 0, 0, 0); //日期对象是 2022-11-01 UTC 08:00，而不是预料中的2022-10-31  UTC 08:00

new Date(2022, 10, 30, 16, 0, 0); //日期对象是 2022-11-01 UTC 00:00！

特别是new Date(2022, 10, 30, 16, 0, 0); 这句，直接得到2022年11月1日，感觉javascript认为10月30日后次日就是11月1日，压根忘记还有10月31日这天……

所以，这不是UTC和GMT能解释的，也不是不同浏览器之间的差异，同个浏览器也会出现这种诡异的事情。

那么最终怎么解决才是最稳妥的？难不成每个程序员自己实现一遍？

https://segmentfault.com/a/1190000022403847 这篇文章给出了解决方案，也指出了根本原因在于日期格式，比如：

'2020-4-20' 格式在各个浏览器都有不同的解析方式，所以可以转换成 '2020/4/20' 格式来解决解析不一致问题，如下：

function getDate (dateStr) {
  dateStr = dateStr.replace(/-/g, '/')
  return new Date(dateStr)
}

经测试，上面2022-11-01能够准确得出结果。因此，不能说不推荐用Date构造函数来解析日期字符串，或者使用其等价的Date.parse，包括setDate都是，不能用，否则系统抽风还很难发现问题所在。