应显式指定CultureInfo和DateTimeKind：用InvariantCulture保证格式稳定，"s"或"o"格式符避免文化/时区歧义，自定义格式需注意大小写、转义和分隔符。
直接用 DateTime.ToString() 就行，但必须注意格式字符串写法、文化信息影响和时区隐含行为——不加干预时，输出会随系统区域设置跑偏，尤其在服务器部署或跨语言 UI 场景下容易出错。
标准格式符（如 "d"、"G"、"o"）怎么选才安全
标准格式符是单字母，语义固定，不易拼错，适合快速开发和日志记录。但它们依赖当前线程的 CultureInfo，同一段代码在中文 Windows 和英文 Linux 上输出可能完全不同。
-
"d"→ 短日期：中文环境是2026/4/10，英文是4/10/2026；"D"同理，星期名和月份名全变 -
"o"（往返格式）最可靠：输出2026-04-10T16:21:00.0000000，但要求DateTime.Kind == DateTimeKind.Utc，否则会带本地偏移（如+08:00），解析时可能被误判为 UTC 时间 -
"s"（可排序格式）无时区、无文化依赖：2026-04-10T16:21:00，适合数据库存储或 API 传输，但不包含毫秒 - 避免用
"U"（本初子午线长格式）：它强制转成 UTC 再格式化，但输入若已是本地时间且未标注Kind，结果会错位 8 小时
自定义格式字符串（如 "yyyy-MM-dd HH:mm:ss"）常见踩坑点
自定义格式灵活，但大小写敏感、字面量需转义、分隔符易混淆——写错一个字母，输出就完全不对，而且编译期不报错，运行时才发现。
-
"MM"是月份（04），"mm"是分钟（21）：大小写反了会导致时间显示成2026-21-10这种诡异值 - 中文文字必须用单引号包裹：
"yyyy年'MM'月'dd'日"→ 正确；"yyyy年MM月dd日"→ 把 MM/dd 当作格式符，输出变成2026年04月10日（但“年”“月”“日”三字消失） - 斜杠
/和冒号:是文化相关分隔符，实际输出可能变成2026.04.10或2026-04-10；要绝对固定，改用横杠或点："yyyy-MM-dd HH:mm:ss" - 12 小时制必须配
"tt"："hh:mm:ss tt"→04:21:00 下午；漏掉tt会丢失 AM/PM，且hh在 0~11 范围内循环，逻辑混乱
为什么 Cultureinfo.InvariantInfo 经常比 CurrentCulture 更合适
多数业务场景不需要“按用户语言自动适配”，反而需要稳定、可预期的输出。比如 API 返回 JSON、写入日志文件、生成导出 Excel 表头——这些地方一旦格式漂移，下游系统就解析失败。
- 用
DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss", CultureInfo.InvariantCulture)，永远输出2026-04-10 16:21:00，不随系统语言变 -
CultureInfo.InvariantCulture不等于英文文化（"en-US"），它禁用所有本地化规则：星期/月份名全用英文缩写（Mon,Jan），数字不用千分位，小数点固定为. - 如果真要中文化输出（如给终端用户看），别靠
CurrentCulture猜，显式传new CultureInfo("zh-CN")，并确保该 culture 已加载（Linux 容器里可能缺失） - Web 应用中，不要在全局线程上设
Thread.CurrentThread.CurrentCulture，它影响整个请求生命周期，容易污染其他模块
ToString() 不抛异常，但格式字符串非法时会在运行时报错
DateTime.ToString(string) 本身不会 throw，但格式字符串若含未闭合单引号、非法占位符（如 "XX"）、或大小写混用（"HHh"），会在调用时触发 FormatException。
- 调试时优先用
"o"或"s"快速验证值是否正常：DateTime.Now.ToString("o") - 生产代码中，若格式来自配置或用户输入，务必 try/catch，或先用正则校验格式字符串（如匹配
^[a-zA-Z'/\-: ]+$并排除非法组合） - 封装扩展方法时，别直接拼接字符串：
dt.ToString($"{{format}}")易注入；应预定义白名单，如public static string ToApiFormat(this DateTime dt) => dt.ToString("s", CultureInfo.InvariantCulture); - 注意
DateTime.MinValue.ToString("d")在某些 culture 下会抛异常（如"ja-JP"），最小安全做法是统一用ToString("s")或加空值判断
真正麻烦的不是写错格式，而是格式看起来对、跑本地没问题，一上测试环境就因 culture 或时区差异崩掉——所以凡涉及跨系统交互的时间字符串，必须显式指定 culture 和 kind，不能赌默认值。
