是数组可以用for 对象数组就用不起了？

花了点时间解决了这个问题，描述下问题： 小程序ios真机显示的时间多了八个小时，安卓没这个问题。而且开发工具模拟器没有这个问题，显示时间正常，真机调试也不会出现这个问题……他只有在线上版本和体验版ios真机才会出现这个问题…… 后端传过来的时间格式： "2020-04-23T11:21:04.254" toTime(strTime) { if (!strTime) { return ''; } var myDate = new Date(strTime + '+0800'); if (myDate == 'Invalid Date') { strTime = strTime.replace(/T/g, ' '); //去掉T strTime = strTime.replace(/-/g, '/'); strTime = strTime.replace(/\.\d+/, ' '); //去掉毫秒 myDate = new Date(strTime + '+0800'); } var d = new Date(myDate);  let y = d.getFullYear() let m = (d.getMonth() + 1) m = m < 10 ? ('0' + m) : m; let day = d.getDate() < 10 ? (`0${d.getDate()}`) : d.getDate() let h = d.getHours() < 10 ? (`0${d.getHours()}`) : d.getHours() let minute = d.getMinutes() < 10 ? (`0${d.getMinutes()}`) : d.getMinutes() let second = d.getSeconds() < 10 ? (`0${d.getSeconds()}`) : d.getSeconds() d = `${ y }-${ m }-${ day } ${ h }:${ minute }:${second}` return d; } 还是让后端给时间戳吧……就没这些坑了 原因： 一种说法：安卓会把这个带T字母的时间看做UTC时间格式，（包括ios打包后也会相差8个小时）与北京时间相差8个小时。你要将UTC时间转化为北京时间然后进行格式化。GMT +0800 已经是加了8个小时的了。 另一种说法：Android和iOS在日期格式上的处理方式有所不同，这个不同也影响到小程序的相关日期时间函数。因为iOS只支持2020/01/01 这种日期格式，不支持2020-01-01这样的格式，而现在很多后端处理日期的格式是2020-01-01，发送过来的，或者自己小程序前端生成的也是这种格式，new Date()就会出现兼容性问题。 参考博客：https://blog.csdn.net/namechenfl/article/details/90241952 https://developers.weixin.qq.com/community/develop/article/doc/000e2e82d14cd80838c9cb8b552013