c# datetime 格式化大全

C#中DateTime.ToString()是格式化唯一核心入口，仅含标准格式符与自定义格式字符串两套机制；90%错误源于大小写误用、文化依赖忽略及mm（分钟）与MM（月份）混淆。

直接说结论：C# 中 DateTime.ToString() 是格式化的唯一核心入口，没有“大全”API，只有“标准格式符”和“自定义格式字符串”两套机制，用错大小写、忽略区域文化、混淆 mm（分钟）和 MM（月份）是 90% 的报错根源。

标准格式符：快速套用但受文化影响

标准格式符是单字母（如 "d"、"D"、"s"），对应系统预设的本地化模式。它们省事，但输出不稳定——中文系统下 "d" 输出 2025/12/26，英文系统可能变成 12/26/2025。

• "s"（Sortable）最安全：固定 ISO 8601 格式 yyyy-MM-ddTHH:mm:ss，无文化依赖，适合日志、API、数据库存取
• "G" 和 "g" 看似通用，实则受 CultureInfo.CurrentCulture 控制，跨语言部署时极易出错
• 想强制显示“年月日”汉字？别硬套 "D"，它在英文环境会输出英文月份；改用自定义：ToString("yyyy年MM月dd日")

自定义格式字符串：精准控制但大小写敏感

这是真正可控的方式，靠拼接占位符实现任意格式。关键不是记全所有符号，而是盯住三组易混对：

• MM（月份） vs mm（分钟）——写成 "yyyy-MM-dd mm:ss" 会把分钟显示成“十二月”
• HH（24 小时制，00–23） vs hh（12 小时制，01–12）——"hh:mm tt" 才能输出 10:13 PM，"HH:mm" 永远是 24 小时制
• yyyy（4 位年） vs yy（2 位年）——金融/审计场景必须用 yyyy，避免 2025 年被缩成 25 引发歧义

高频实用组合：

DateTime.Now.ToString("yyyyMMdd_HHmmss")     // 文件名安全：20251226_221345
DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss.fff") // 带毫秒日志：2025-12-26 22:13:45.123
DateTime.Now.ToString("yyyy-MM-ddTHH:mm:ssZ")    // UTC 时间（ISO 8601）：2025-12-26T22:13:45Z

区域文化（Culture）：不显式指定就默认“当前系统”

分隔符（如 / 或 -）、星期/月份名称、AM/PM 文字，全由当前线程的 CultureInfo 决定。你写 "yyyy/MM/dd"，在中文 Windows 上没问题，但在德语系统里可能被替换成 2025.12.26（因为德语用点作日期分隔符）。

• 要 100% 固定格式，必须传 CultureInfo.InvariantCulture
• 正确写法：DateTime.Now.ToString("yyyy-MM-dd", CultureInfo.InvariantCulture)
• 错误写法：DateTime.Now.ToString("yyyy/MM/dd") —— / 在某些文化中会被自动替换

容易被忽略的边界点

很多问题不是不会写，而是没意识到这些隐性约束：

• DateTime 本身不存格式，ToString() 只是“快照式转换”，反复调用不会改变原值
• 毫秒精度只到 fff（三位），ffff 及以上只是补零，不代表更高精度（DateTime 最小刻度是 100 纳秒，但 ToString 不暴露）
• UTC 时间建议用 DateTime.UtcNow.ToString("o")（"o" 是 Round-trip 格式），它自动带时区偏移，比手拼 "yyyy-MM-ddTHH:mm:ss.fffK" 更可靠
• 如果用于文件名、URL、JSON 键等场景，避开 :、/、空格、中文，优先选 yyyyMMddHHmmss 或 yyyy-MM-ddTHH-mm-ss

真正难的不是记住几十个格式符，而是每次写 ToString 时，心里默念三句：我需要跨文化一致吗？这个 MM 是月份还是分钟？这个分隔符会不会被系统偷偷换掉？