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（月份）vsmm（分钟）——写成"yyyy-MM-dd mm:ss"会把分钟显示成“十二月” -
HH（24 小时制，00–23）vshh（12 小时制，01–12）——"hh:mm tt"才能输出10:13 PM，"HH:mm"永远是 24 小时制 -
yyyy（4 位年）vsyy（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 是月份还是分钟？这个分隔符会不会被系统偷偷换掉？
