CAST是SQL标准函数，兼容性好；CONVERT是SQL Server和MySQL特有非标准函数，SQL Server中支持样式参数，MySQL中仅为别名。
CAST 和 CONVERT 的核心区别在哪
CAST 是 SQL 标准函数，跨数据库兼容性好（PostgreSQL、MySQL 8.0+、SQL Server、SQLite 都支持）；CONVERT 是 SQL Server 和 MySQL 特有的非标准函数，SQL Server 中功能更全（支持样式参数），MySQL 中只是 CAST 的别名。如果你写的是可移植 SQL，优先用 CAST；如果只跑在 SQL Server 上且需要日期/数字格式化（比如把 datetime 转成 'yyyy-mm-dd'），才考虑 CONVERT。
什么时候会触发转换失败或静默截断
类型转换不是总能成功——尤其当源值超出目标类型范围，或格式不匹配时。例如把字符串 'abc' 转成 INT，SQL Server 报错 Conversion failed when converting the varchar value 'abc' to data type int.，而 MySQL 可能返回 0（开启严格模式才报错）。常见风险点：
-
CAST('2024-13-01' AS DATE)：多数数据库直接报错，不是返回 NULL -
CAST('123.456' AS DECIMAL(5,2))：可能四舍五入为123.46，也可能因精度溢出报错（取决于数据库和设置） -
CAST('12345678901234567890' AS INT)：整数溢出，SQL Server 报错，PostgreSQL 返回integer out of range
字符串转数字的实用写法与容错处理
真实业务中字段常是 VARCHAR 存数字（比如导出数据、用户输入），直接 CAST 很容易崩。安全做法是先过滤或兜底：
- SQL Server 可用
TRY_CAST('abc' AS INT)—— 失败返回 NULL，不报错 - PostgreSQL 用
NULLIF(regexp_replace(col, '\D', '', 'g'), '')::NUMERIC清除非数字字符再转（慎用，性能差） - MySQL 8.0+ 没有 TRY_CAST，可用
CAST(NULLIF(col REGEXP '^[0-9]+$', col) AS SIGNED)判断后转，但正则不索引友好 - 通用兜底：加
WHERE col ~ '^[0-9]+$'（PostgreSQL）或WHERE col REGEXP '^[0-9]+$'（MySQL）再 CAST
日期字符串转 DATE 时最容易忽略的隐式行为
不同数据库对模糊格式容忍度差异极大。比如 CAST('2024/05/10' AS DATE) 在 SQL Server 和 PostgreSQL 中通常成功，但在某些 MySQL 版本可能被解释为 2024-10-05（MDY vs YMD）。更危险的是两位年份：CAST('1/2/3' AS DATE) 在 SQL Server 默认按 MDY 解析，PostgreSQL 按 YMD（取决于 datestyle 设置）。务必显式指定格式：
- SQL Server 推荐用
CONVERT(DATE, '2024-05-10', 120)（120 = yyyy-mm-dd） - PostgreSQL 用
TO_DATE(col, 'YYYY-MM-DD')，比 CAST 更可控 - 避免依赖默认解析——哪怕看起来“能跑通”，换环境就翻车
类型转换看着简单，真正卡住人的永远是边界情况：空格、不可见字符、区域设置、隐式截断、NULL 处理逻辑不一致。别信“试了一下没问题”，得看它在异常输入、不同版本、不同服务器配置下是否还稳。
