DateTime.ToString() 的基本用法和常见格式字符串
直接调用
ToString()而不传参，会走当前线程的区域设置（
CultureInfo.CurrentCulture），结果不稳定。生产环境必须显式指定格式或文化。
"yyyy-MM-dd"→
"2024-06-15"（推荐用于存储、API 传输）
"HH:mm:ss"→
"14:30:25"（24 小时制，注意是
HH不是
hh）
"MM/dd/yyyy HH:mm"→
"06/15/2024 14:30"（注意斜杠是字面量，实际输出受
CultureInfo影响） 想彻底避免文化影响？用不变文化：
dt.ToString("yyyy-MM-dd HH:mm:ss", System.Globalization.CultureInfo.InvariantCulture)
使用 DateTimeFormatInfo.InvariantInfo 避免本地化干扰
Windows 和 Linux 下默认
CultureInfo.CurrentCulture表现不一致，尤其在分隔符（如日期中的
/、时间中的
:）和 AM/PM 标识上。哪怕你本地测试正常，部署到 Docker 容器或 Ubuntu 服务器就可能出错。 错误写法：
dt.ToString("yyyy/MM/dd") // 在某些文化下 / 可能被替换成其他分隔符
正确写法：dt.ToString("yyyy'/'MM'/'dd", System.Globalization.DateTimeFormatInfo.InvariantInfo)
更稳妥：用单引号包裹字面量字符，比如 'T'、
'Z'，确保生成 ISO 8601 格式：
dt.ToString("yyyy-MM-dd'T'HH:mm:ss.fff'Z'", System.Globalization.DateTimeFormatInfo.InvariantInfo)
ToString("o") 和 ToString("u") —— 内置标准格式的取舍
"o"（Round-trip 格式）和
"u"（Universal sortable）是两个预定义标准格式，但行为差异明显：
"o"输出带本地时区偏移，如
"2024-06-15T14:30:25.123+08:00"；依赖
DateTimeKind，若
dt.Kind == DateTimeKind.Unspecified，会按本地时区补偏移，容易误判
"u"强制转为 UTC 并用
"yyyy-MM-dd HH:mm:ssZ"格式（无毫秒、无冒号、固定
Z），适合日志排序，但丢失毫秒精度 真正需要跨系统交换时间？优先用
ToString("O")（注意大写 O）并确保 dt.Kind == DateTimeKind.Utc，否则先调用
dt.ToUniversalTime()
自定义格式中容易忽略的陷阱
看似简单的格式字符串，实际运行时可能因大小写、重复次数、文化设置而失效。
"yyyy"是四位年份；
"yy"是两位，但
"y"（单个）在某些文化下会报错或返回意外值
"MM"是月份（01–12）；
"mm"是分钟（00–59）——大小写敏感，拼错就变成“把分钟当月份”
"dddd"返回完整星期名（如 "Saturday"），但若用
CultureInfo.GetCultureInfo("zh-CN")，会输出中文，而 InvariantInfo下返回英文，别假设它总是中文 想输出带毫秒的精确时间？用
"fff"（三位），不是
"FFF"或
"ms"；
"ffff"是万分之一秒，但 .NET 默认只保留毫秒精度，多余位恒为 0
格式化不是“写对字符串就行”，关键是控制输入的
DateTimeKind、选对文化、明确分隔符是否需转义。哪怕只是写日志，也建议统一用
InvariantInfo+ 单引号包裹字面量，省去排查环境差异的时间。
