Z表示UTC（协调世界时，也称为格林威治子午线时间），删除它会改变含义-除非您的浏览器或服务器位于格林威治时区，而且现在是冬天（没有夏令时）。
您可以在Date对象和UTC字符串之间来回转换，如下所示（我的浏览器使用中欧时区）：

> utc = '2022-11-28T16:55:44.000Z'
'2022-11-28T16:55:44.000Z'
> d = new Date(utc)
Mon Nov 28 2022 17:55:44 GMT+0100 (Central European Standard Time)
> d.toISOString()
'2022-11-28T16:55:44.000Z'

或者，您也可以在Date对象和浏览器或服务器时区的格式化字串之间来回转换（最后一行显示我的浏览器格式与您的不同）：

> formatted = '2022-11-28 17:55:44'
'2022-11-28 17:55:44'
> d = new Date(formatted)
Mon Nov 28 2022 17:55:44 GMT+0100 (Central European Standard Time)
> d.toLocaleString()
'11/28/2022, 5:55:44 PM'

但是您不应该在数据库中以这种格式存储Date对象，除非您可以保证它们总是在同一时区中读取和写入。（在CET中）并存储它，那么在新西兰时区使用浏览器读取它并将其转换回Date对象的其他人将看到错误的值。如果格式规则不明确（9月11日还是11月9日？），则类似9/11/2022的日期将不明确。
这就是为什么我在存储Date对象时更喜欢使用UTC字符串，并且只在将它们输出给用户和解析用户输入时才使用格式化字符串。

我看到它甚至更强：你应该永远将日期存储为字符串，这是一个设计缺陷。总是存储正确的Date对象。在SO上你可以找到数百个问题，人们在这些问题上有问题，因为他们将日期值存储为（本地化的）字符串。这不仅限于MongoDB，它适用于任何数据库。
MongoDB中的Date对象是UTC时间-总是且仅！通常客户端应用程序负责以本地时区和本地格式显示日期/时间。
你说的“把它转回来”是什么意思，你是怎么做的？
不应依赖没有时区new Date(<string>)某些浏览器/环境可能应用UTC时间，其他浏览器/环境可能使用当前本地时区，请参阅假定时区差异
看看第三方日期库，例如moment.js、Luxon或Day.js。通常它们提供更多的控制如何解析字符串和时区。