CONVERT仅在SQL Server中有效且需严格匹配类型与style参数，仅日期格式化和字符集转换必须使用；其他场景优先用CAST；style对datetime/money转字符串有效，数值转字符串需确保目标长度足够。
CONVERT 不是万能类型转换工具，它只在 SQL Server 中有效，且对目标类型和输入表达式有明确兼容性要求。用错地方会直接报错，比如把含字母的字符串转 INT，或漏掉 style 却硬要格式化日期。
什么时候必须用 CONVERT 而不是 CAST
只有两类场景真正需要 CONVERT：一是要控制日期/时间输出格式（比如报表要 “MM/DD/YYYY”），二是要做字符集转换（如 varchar → nvarchar）。其他纯类型转换（INT ↔ VARCHAR、DATE ↔ DATETIME）用 CAST 更安全、更标准。
-
CONVERT(VARCHAR(10), GETDATE(), 101)输出08/11/2026；CAST(GETDATE() AS VARCHAR(10))输出不可控的默认格式（通常是Aug 11 2026） -
CONVERT(NVARCHAR(50), 'hello')显式指定 Unicode 编码；CAST无法指定字符集 -
style参数只对datetime→varchar或money→varchar有效，用在INT→VARCHAR上毫无作用
style 参数哪些值实际可用
常见错误是查到一堆 style 编号就全往里套，结果部分失效或返回空值。SQL Server 实际只认一部分，且区分「带世纪」和「不带世纪」：
- 日期转字符串时，
101（mm/dd/yyyy）、120（yyyy-mm-dd hh:mi:ss）、23（yyyy-mm-dd）最常用，也最稳定 - 想强制四位年份，选
101而不是1，选120而不是20——加 100 是保险做法 -
style = 0或未提供时，SQL Server 按当前语言环境决定格式，生产环境慎用 - 从
smalldatetime转字符串时，style中含秒（如120）的位置会补00，不是报错
字符串转日期时最容易踩的坑
看起来只是把 '20260811' 转成 DATE，但失败率极高。根本原因是 SQL Server 对输入格式极其敏感，且不自动推断：
- 用
CONVERT(DATE, '20260811', 112)才能正确识别yyyymmdd格式；直接CONVERT(DATE, '20260811')可能报错或误判为2026-08-11以外的日期 -
'08/11/2026'在美国语言环境下走101没问题，在英国环境可能被当成dd/mm/yyyy导致错误 - 含时间的字符串（如
'2026-08-11T10:51:00'）推荐用TRY_CONVERT，避免因格式不符直接中断查询 - 不要依赖隐式转换：写
WHERE order_date = '20260811'看似省事，实际触发隐式转换，可能让索引失效
数值转字符串时 length 设置不当的后果
CONVERT(VARCHAR(5), 1234567) 不会截断，而是报错：String or binary data would be truncated。这是因为目标长度小于实际字符数，SQL Server 默认拒绝静默截断。
- 字符串目标长度必须 ≥ 表达式最大可能字符数，比如
DECIMAL(10,2)最多占 13 位（含负号、小数点），VARCHAR(13)是底线 - 用
VARCHAR不指定长度（如VARCHAR）等价于VARCHAR(30)，但显式写出来更可控 - 对金额类字段，建议统一用
CONVERT(VARCHAR(20), amount, 1)，style = 1会自动加千分位和两位小数（1,234.56）
CONVERT 的灵活性来自 style 和字符集支持，代价是参数顺序固定、容错率低。真正麻烦的不是怎么写对，而是怎么预判输入格式是否匹配所选 style，以及是否真需要它——多数简单转换，CAST 更省心。 
