C#字符串转日期需先校验格式、时区和容错性，优先用DateTime.TryParse或TryParseExact配合多格式数组与显式CultureInfo，严格匹配格式符并明确DateTimeKind。
字符串转日期在 C# 里不是“选一个方法就行”，而是得先看字符串格式是否规范、时区是否明确、失败能否容忍——直接用或在生产环境容易炸。
字符串格式不固定时，优先用
用户输入、日志解析、API 返回的日期字符串常常缺年份、混用横线/斜杠、甚至带空格或多余字母（比如
和
并存）。
遇到任何不匹配就抛
，而
返回
，安全可控：
始终检查返回值，不要只依赖
参数
若需支持多种格式，用
配合字符串数组，例如：
作为
参数时，使用当前线程文化；若需强制按美式/中式解析，显式传
或
和
的格式字符串必须严格匹配
常见坑：以为
能匹配
（单数字月/日），实际会失败。格式符大小写敏感、占位数刚性：
匹配 1–12（不补零），
必须是 01–12；
和
同理
带时间部分时，
是 24 小时制（00–23），
是 12 小时制（01–12），漏掉
会导致
解析失败
ISO 8601 带时区的字符串（如
）要用
标准格式或自定义
，其中
解析时区偏移
注意
和时区语义
字符串本身不含时区信息，但解析后
默认是
。这会影响后续转换（比如调用
时，.NET 会按本地时区解释它）：
C知道
CSDN推出的一款AI技术问答工具
下载
若原始字符串明确是 UTC（如 API 返回的
），用
，结果
若字符串来自用户本地输入（如
），且业务逻辑要求按服务器本地时区处理，用
避免对
类型直接调用
或
，先用
显式标注
性能敏感场景慎用
/
的重载版本
频繁解析同一格式字符串（如日志批量处理）时，反复构造
或格式数组有开销：
把常用格式字符串和
提前缓存为静态只读字段
考虑用
+
（.NET Core 2.1+），避免字符串分配
底层仍调用
，且不支持自定义格式，纯属多一层封装，无额外价值
最麻烦的从来不是“怎么转”，而是“转完这个
到底代表哪个时刻”——尤其当字符串没带时区、文化上下文模糊、又跨系统传递时。别省那几行标注
的代码。
DateTime.ParseConvert.ToDateTimeDateTime.TryParse"2023-05-12T14:30:00""12/05/2023 2:30 PM"ParseFormatExceptionTryParsebooloutDateTime.TryParseExactstring[] formats = { "yyyy-MM-dd", "dd/MM/yyyy", "M/d/yyyy h:mm tt" };
DateTime result;
bool success = DateTime.TryParseExact(input, formats, null, DateTimeStyles.None, out result);nullIFormatProviderCultureInfo.GetCultureInfo("en-US")new CultureInfo("zh-CN")ParseExactTryParseExact"yyyy-MM-dd""2023-5-12""M""MM""d""dd""HH""hh""tt""2:30 PM""2023-05-12T14:30:00+08:00""o""yyyy-MM-ddTHH:mm:ssK"KDateTimeKindDateTime.KindUnspecified.ToUniversalTime()"2023-05-12T06:30:00Z"DateTimeStyles.AssumeUniversal | DateTimeStyles.AdjustToUniversalKind == DateTimeKind.Utc"2023-05-12 14:30"DateTimeStyles.AssumeLocalUnspecified.ToLocalTime().ToUniversalTime()DateTime.SpecifyKind(dt, DateTimeKind.Local)ParseTryParseCultureInfoCultureInfoReadOnlySpanDateTime.TryParseExact(ReadOnlySpan, ...) Convert.ToDateTimeParseDateTimeKind