CONVERT的style参数是强制解析规则而非美化开关，它严格定义日期字符串的字段顺序、分隔符及格式要求，缺失时依赖会话DATEFORMAT导致跨环境行为不一致。
CONVERT的style参数本质是格式模板，不是“美化开关”
很多人以为style只是控制日期“看起来什么样”，其实它定义的是**输入/输出双方必须严格遵守的解析规则**。比如CONVERT(date, '03/25/2024', 101)能成功，是因为101明确告诉SQL Server：“按mm/dd/yyyy顺序拆这个字符串，斜杠是分隔符，不许乱猜”。而省略style时，SQL Server会去查当前会话的DATEFORMAT设置（可能是mdy、dmy或ymd），一旦环境变了，同一句SQL在测试库跑通，在生产库就报Msg 241。
常见style代码对应的真实解析逻辑
不同数字背后是完全不同的字段顺序和分隔符容忍度：
-
101：强制按“月/日/年”切分，只认/，'03-25-2024'直接失败（除非加110） -
103：强制“日/月/年”，'25/03/2024'能过，但'03/25/2024'会被当成“月=03，日=25，年=2024”→错位解析 -
112：只接受纯数字yyyymmdd，连-都不允许，'2024-11-02'报错，'20241102'才对 -
120和126：都支持ISO标准，但120输出带空格和冒号（'2024-11-02 15:43:00'），126用T分隔且无空格（'2024-11-02T15:43:00'），后者更适合作为API返回值
为什么你写的CONVERT有时“碰巧能用”，有时突然崩
根本原因在于style缺失时的fallback行为不可控：
- 同一句
CONVERT(date, '15/03/2024')，在英国服务器上走dmy规则成功，在美国服务器上按mdy解析→“月=15”非法→Msg 241 -
CONVERT(varchar, GETDATE(), 1)输出03/25/24（两位年份），但CONVERT(varchar(8), GETDATE(), 1)会静默截断成03/25/2——因为varchar(8)只够存8个字符，末尾4被砍掉，还不报错 - 用
CONVERT(date, '2024年11月02日')这种含中文的字符串，所有style代码都无效，SQL Server根本不识别中文分隔符，必须先用REPLACE清理
跨环境部署前必须检查的三件事
避免上线后才发现日期转换集体失效：
- 所有
CONVERT调用必须显式带上style参数，禁止依赖默认值 - 目标类型长度要留余量：
CONVERT(varchar(10), GETDATE(), 23)够存'2026-11-02'，但CONVERT(varchar(9), ..., 23)就会截断 - 字符串转日期前，先用
TRY_CONVERT(date, @input)兜底，返回NULL而不是炸掉整个查询
style代码不是菜单选项，是契约。写死它，才能让SQL在任何服务器上都按你预期的方式拆解和组装日期字符串。
