今天遇到一個怪異的BUG， 一路跟蹤到isNaN(Date.parse(str))這句上，詢問同事后得知這里的意圖是探測str是否是合法的日期字符串。根據(jù)MDN的定義：

The Date.parse() method parses a string representation of a date, and returns the number of milliseconds since January 1, 1970, 00:00:00 UTC.

只要是合法的日期字符串，就會返回一個UTC日期。那么要是不合法呢？MDN上有一個例子：

Date.parse('foo-bar 2014');// returns: NaN

這么看來他的做法應(yīng)該是可行的，但為啥出現(xiàn)問題了呢？我在自己的電腦上試了下，Date.parse('foo-bar 2014')返回的是1388530800000！于是一想，前端組里好像只有我是常用Chrome的，其他人都是Firefox，難道是兼容性的問題？

于是換瀏覽器使勁測了測，果然如此。在Firefox中，字符串中只要出現(xiàn)非日期字母就會立即判定為非法日期字符串，而在當(dāng)前版本的Chrome中，只要字符串最后的那部分是數(shù)字，并且和前面有空格分隔，Date.parse就會取空格和數(shù)字部分，并按這個部分給出一個日期。于是在Chrome下，Date.parse('foo-bar 2014')與Date.parse(' 2014')所得的結(jié)果是一致的。但如果數(shù)字前面不是空格，如'foo-bar-2014，則會同F(xiàn)irefox一樣返回NaN。

最后還借同事的mac測了下，發(fā)現(xiàn)WebKit系內(nèi)核的safari沒有這個問題，行為與Firefox一致。其他瀏覽器則還沒來得及測，有windows的朋友可以試試IE的結(jié)果。

這是我第一次遇到這樣的問題，也提醒自己盡管現(xiàn)代瀏覽器已經(jīng)越來越標(biāo)準(zhǔn)化了，兼容性的問題還是會在某些不起眼的地方出現(xiàn)，給你埋下一個又一個難以察覺的坑。