Mongoose日期与时区问题：如何按服务器时区返回日期？

先澄清一个时区细节：欧洲/巴黎在1月属于中欧标准时间（CET），是UTC+1而非UTC+2（UTC+2是夏季的CEST）。所以你创建的2020-01-01 20:20:20巴黎时间，对应的UTC时间确实是2020-01-01T19:20:20.000Z——这就是Mongoose返回这个值的原因，因为MongoDB始终以UTC存储日期，Mongoose返回的Date对象底层也是UTC，但调用toString()时会根据Node的时区设置转换为服务器时区的可读字符串。

针对你的核心需求——全局自动处理日期转换，无需逐个字段手动操作，保持UTC存储的同时按服务器时区输出友好格式，且你无法注册全局插件，这里有两个最优方案：

方案1：全局配置Mongoose的toJSON/toObject转换规则 #

你可以直接通过mongoose.set()全局设定所有Schema的JSON/对象转换规则，利用transform函数统一处理所有Date类型字段，不需要全局插件：

const mongoose = require('mongoose');
// 推荐用date-fns做格式化，轻量且日期处理能力强；也可以用moment或原生API
const { format } = require('date-fns');

// 全局配置toJSON（发送给客户端时会用到）
mongoose.set('toJSON', {
  transform: (doc, ret) => {
    // 遍历返回对象，自动识别并转换Date字段
    for (const key in ret) {
      if (ret[key] instanceof Date) {
        // 转换为服务器时区的友好格式，比如"2020-01-01 20:20:20"
        ret[key] = format(ret[key], 'yyyy-MM-dd HH:mm:ss', { timeZone: process.env.TZ });
        
        // 如果你需要带时区偏移的ISO格式，比如"2020-01-01T20:20:20+01:00"，可以替换为：
        // ret[key] = new Intl.DateTimeFormat('en-GB', {
        //   year: 'numeric', month: '2-digit', day: '2-digit',
        //   hour: '2-digit', minute: '2-digit', second: '2-digit',
        //   timeZone: process.env.TZ
        // }).format(ret[key]).replace(' ', 'T') + '+01:00';
      }
    }
    return ret;
  }
});

// 同步配置toObject，确保控制台输出或调用doc.toObject()时也生效
mongoose.set('toObject', {
  transform: (doc, ret) => {
    for (const key in ret) {
      if (ret[key] instanceof Date) {
        ret[key] = format(ret[key], 'yyyy-MM-dd HH:mm:ss', { timeZone: process.env.TZ });
      }
    }
    return ret;
  }
});

这个方案的优势：

• 一次配置全局生效，所有Schema的文档在转换为JSON/普通对象时都会自动处理日期
• 性能开销极低：transform只在文档被转换时执行，且仅遍历当前文档的字段，只处理Date类型
• 完全符合你的限制，不需要注册全局插件

方案2：自定义基础Schema（灵活控制范围） #

如果全局配置不适合你的场景（比如部分Schema不需要日期转换），可以创建一个带转换规则的基础Schema，让需要的业务Schema继承它：

const mongoose = require('mongoose');
const { format } = require('date-fns');

// 创建带日期转换的基础Schema
const baseTimezoneSchema = new mongoose.Schema({}, {
  toJSON: {
    transform: (doc, ret) => {
      for (const key in ret) {
        if (ret[key] instanceof Date) {
          ret[key] = format(ret[key], 'yyyy-MM-dd HH:mm:ss', { timeZone: process.env.TZ });
        }
      }
      return ret;
    }
  },
  toObject: {
    transform: (doc, ret) => {
      for (const key in ret) {
        if (ret[key] instanceof Date) {
          ret[key] = format(ret[key], 'yyyy-MM-dd HH:mm:ss', { timeZone: process.env.TZ });
        }
      }
      return ret;
    }
  }
});

// 业务Schema继承基础Schema
const testSchema = new mongoose.Schema({
  myDate: { type: Date, required: true },
}, { timestamps: true }).add(baseTimezoneSchema);

exports.TestSchema = mongoose.model('TestSchema', testSchema);

这样你可以精准控制哪些Schema应用日期转换规则。

关于性能与保留Date对象的补充 #

你担心遍历字段的性能问题，其实这种遍历的开销非常小——它只在文档转换时执行，且仅处理当前文档中的Date字段，对于绝大多数业务场景来说完全可以忽略。如果你的文档有大量日期字段，可以优化为提前定义需要转换的字段列表，但自动检测Date类型已经足够高效。

另外，如果你想保留Date对象而非转换为字符串，其实不需要额外处理：Date对象本身已经包含时区信息，当客户端接收到JSON格式的日期（会转为ISO字符串），可以根据服务器指定的时区解析显示。但如果你希望在服务器端直接返回服务器时区的格式化字符串，上面的方案就是最优解。

最后再强调：process.env.TZ只会影响Node自身的日期显示逻辑，不会改变MongoDB存储的UTC时间，我们的方案只是在输出时将UTC时间转换为服务器时区的友好格式，完全符合你“UTC存储，按服务器时区调整显示”的需求。

内容的提问来源于stack exchange，提问作者L. Faros