DateTime格式异常求助：格式化后斜杠自动转为横杠

哇，干了几十年日期格式化从没遇到过这种诡异情况，2018年那回突然斜杠变横杠，换谁都得懵圈！我来帮你捋捋这事儿到底咋回事儿，以及怎么解决。

问题根源：/不是字面量，是「日期分隔符占位符」 #

在.NET的日期格式化规则里，/并不是直接输出斜杠的字面量，它是一个占位符，会被当前线程的CultureInfo（或者你指定的文化）里的「日期分隔符」替换掉。

比如en-US文化默认的日期分隔符是/，但如果你的Web应用全局文化被改成了用-当分隔符的文化（比如de-DE、fr-FR，或者自定义的文化设置），哪怕你写了M/d/yyyy，最终输出的也会是M-d-yyyy。

你看你写的代码里，只有第一行明确指定了en-US，但后面几行（比如ToString("MM/dd/yyyy")、ToShortDateString()）都是用的当前线程的默认文化——如果这个默认文化的日期分隔符是-，那结果自然就不对了。甚至有可能你第一行的代码也被其他地方篡改了CultureInfo的配置（比如有人修改了en-US的DateTimeFormat），不过这种情况比较少见。

解决方法：两种思路搞定它 #

1. 强制输出字面量斜杠：用单引号转义 #

如果你不管当前文化是什么，就想固定输出/，那把格式字符串里的/用单引号包起来就行，这样.NET就会把它当成字面量处理，不会替换成文化里的分隔符：

// 转义斜杠，强制输出/
var bdt = DateTime.Now.AddDays(-1).ToString("M'/'d'/'yyyy");
// 或者MM/dd/yyyy的版本
var bdt = DateTime.Now.AddDays(-1).ToString("MM'/'dd'/'yyyy");

2. 牢牢锁定en-US文化，不受全局设置影响 #

如果你的需求就是要遵循en-US的日期格式，那每次格式化时都明确传入en-US的CultureInfo，同时排查全局文化设置有没有被篡改：

// 明确创建en-US文化对象，避免受全局线程文化影响
var usCulture = CultureInfo.CreateSpecificCulture("en-US");
// 格式化时传入这个文化
var bdt = DateTime.Now.AddDays(-1).ToString("M/d/yyyy", usCulture);
var bdt2 = DateTime.Now.AddDays(-1).ToString("d", usCulture); // 短日期格式也会用en-US的/

另外，别忘了检查Web应用的全局配置：

• 如果是ASP.NET Framework，看看web.config里有没有<globalization>节点，比如：

  <globalization culture="en-US" uiCulture="en-US" />
  

  如果这里被改成了其他文化，会影响整个应用的默认日期分隔符。
• 如果是ASP.NET Core，检查Startup.cs（或者Program.cs）里的文化配置，比如：

  app.UseRequestLocalization(options =>
  {
      options.DefaultRequestCulture = new RequestCulture("en-US");
      // ...其他配置
  });
  

  确保默认文化是你需要的en-US。

3. 排查线程文化是否被悄悄修改 #

可以在格式化代码之前加一行调试代码，看看当前线程的日期分隔符到底是什么：

// 输出当前线程的日期分隔符
Debug.WriteLine(Thread.CurrentThread.CurrentCulture.DateTimeFormat.DateSeparator);

如果输出的是-，那说明线程文化确实被改了——可能是代码里某个地方调用了Thread.CurrentThread.CurrentCulture = new CultureInfo("xx-XX")，或者第三方组件修改了线程文化。

最后碎碎念 #

这种问题看起来是格式字符串的锅，实则是文化设置的坑——我当年也踩过类似的坑，排查了半天才发现是同事为了适配海外用户，偷偷改了全局文化配置！所以遇到这种诡异的格式化问题，先查文化设置准没错。

内容的提问来源于stack exchange，提问作者GoldBishop