DateTime.ToString() 必须显式指定格式和文化，推荐用InvariantInfo避免环境差异；”yyyy-MM-dd”用于存储/API，”o”格式需确保Kind为Utc，自定义格式注意大小写敏感和字面量转义。
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 + 单引号包裹字面量，省去排查环境差异的时间。