好吧，还是先说说我的亲身经历，步骤如下：首先在芬兰语Windows环境安装并配置软件；其次对某一台特定测试机发出请求。返回下图结果。
经过反复验证，该问题在CCJK，FR, DE上均不复现。那么在request场景中，最大的嫌犯就只能是时间格式了吧，来看看Windows的Finland Region设置。
果不其然，在芬兰语中分秒分隔符并不是我们熟悉的“:”而是“.”。再回到本例中，查看错误日志发现最初的错误源头来自于Data Serialization，另外注意到开发人员使用了Json.NET（技术细节请参见 http://www.newtonsoft.com/json）来序列化对象日期，同时并未指定culture，这样程序就会采用OS默认的culture，在本例中即芬兰语。示意代码如下： CultureInfo culture = CultureInfo.GetCultureInfo("fi"); Product pro = new Product(); pro.Log = culture + " App Launched..."; pro.LogDate = new DateTime(2016, 8, 5, 1, 2, 3); var converter = new IsoDateTimeConverter() { Culture = culture, DateTimeFormat = "yyyy-MM-ddTHH:mm:ssZ" }; string defaultJson = JsonConvert.SerializeObject(pro); Console.WriteLine(defaultJson); string isoJson = JsonConvert.SerializeObject(pro, converter); Console.WriteLine(isoJson); 为了效果展示，我将culture明示为fi，DateTimeFormat也指定了pattern格式。这下应该万无一失，序列化后的时间板儿定输出2016-08-05T01:02:03Z吧？OK! 所见略同，走起。 {"Log":"fi App Launched...","LogDate":"2016-08-05T01:02:03"} {"Log":"fi App Launched...","LogDate":"2016-08-05T01.02.03Z"} 啊哦~~~这就是生活啊！即便我们煞费苦心的指定了DateTimeFormat pattern，然而一旦遇到这种情况，终究还是根儿红苗正的culture说了算…… 长歌当哭，是在痛定思痛之后的。这里我直接放出了InvariantCulture的大招。 CultureInfo culture = CultureInfo.InvariantCulture; 再次运行，这个世界终于清静了。 {"Log":" App Launched...","LogDate":"2016-08-05T01:02:03"} {"Log":" App Launched...","LogDate":"2016-08-05T01:02:03Z"} 本案中bug正是因为序列化时间日期产生了异常，导致之后的request请求异常，checkin 代码后，问题亦不再出现。那么问题来了——日后当你再次遇到仅在某一个culture或locale出现的国际化bug时，你又会想到什么呢？这就是生活？呃……好吧
