优先用 CAST，因其跨数据库兼容性更好；CONVERT 仅 SQL Server 支持且含 style 参数，MySQL/PostgreSQL 不识别，跨库迁移时易出错。
CAST 和 CONVERT 用哪个？先看数据库类型
MySQL 不支持 CAST 的某些语法（比如带样式参数），SQL Server 和 PostgreSQL 支持但行为不同；CONVERT 是 SQL Server 独占函数，MySQL 和 PostgreSQL 根本不认——写之前得先确认你连的是什么库。
- SQL Server：两个都行，
CONVERT多一个style参数，适合日期/数字格式化 - PostgreSQL：只认
CAST或::语法，CONVERT直接报错ERROR: function convert(unknown, unknown) does not exist - MySQL：支持
CAST，但不支持CONVERT(expr AS type)这种标准写法，得用CONVERT(expr, type)（参数顺序反的）
字符串转数字失败？检查隐式截断和非法字符
把 '123abc' 转成 INT，MySQL 会静默截成 123，SQL Server 直接抛 Conversion failed when converting the varchar value '123abc' to data type int.；PostgreSQL 更严格，连 '123 '（尾部空格）都会报 invalid input syntax for integer。
- 安全做法：先用
REGEXP（MySQL/PostgreSQL）或ISNUMERIC()（SQL Server，注意它对'.'也返回 1）过滤掉脏数据 - 别依赖自动截断——显式用
TRIM()清空格，再用正则确保全数字：WHERE col ~ '^[0-9]+$'（PostgreSQL） - MySQL 中
CAST(' 42 ' AS SIGNED)能成功，但CAST('42.5' AS SIGNED)得到42，小数部分直接丢，不是四舍五入
日期字符串转 DATE 类型，格式不匹配就崩
CAST('2023-01-01' AS DATE) 在三者中都稳，但换成 '01/01/2023' 就各奔东西：SQL Server 默认按 MDY 解析，PostgreSQL 按 YMD（除非改 datestyle），MySQL 可能直接返回 NULL 或警告。
- SQL Server 推荐用
CONVERT(DATE, '01/01/2023', 101)，101明确指定美式格式 - PostgreSQL 别硬 CAST，用
TO_DATE(col, 'MM/DD/YYYY')更可控 - MySQL 中
STR_TO_DATE('01/01/2023', '%m/%d/%Y')比CAST可靠得多 - 所有数据库里，时区信息（如
'2023-01-01T12:00:00Z'）都不能靠基础 CAST 解析，得用各自专用函数
性能差异其实很小，但嵌套 CAST 容易触发隐式转换
单层 CAST(col AS VARCHAR(10)) 几乎没开销，但写成 CAST(CAST(col AS CHAR(5)) AS VARCHAR(10)) 就可能让优化器放弃索引——尤其在 WHERE 或 JOIN 条件里。
- 避免在索引列上做任何转换，宁可提前建计算列或物化表达式
- SQL Server 中
CONVERT(VARCHAR, date_col, 120)比CAST(date_col AS VARCHAR)生成更短、确定的字符串，利于后续比较 - PostgreSQL 的
::语法（如col::TEXT）和CAST完全等价，选哪个纯看团队习惯，但别混着用 - 跨库迁移时，
CONVERT是最大雷区——它不存在于多数其他系统，硬搬过去就是语法错误
事情说清了就结束。真正麻烦的从来不是语法怎么写，而是同一段 SQL 在不同环境里“看起来一样，跑起来不同”。
