优先用CAST，因其符合SQL标准、跨数据库兼容性好；CONVERT仅SQL Server和MySQL支持且行为不一，虽有style参数但移植性差。
CAST 和 CONVERT 用哪个？看数据库和可读性
CAST 是 SQL 标准函数，所有主流数据库（PostgreSQL、SQL Server、MySQL 8.0+、SQLite）都支持；CONVERT 是 SQL Server 和 MySQL 的扩展，语法更灵活但不跨平台。如果你写的是只跑在 SQL Server 上的报表脚本，CONVERT 支持样式参数（比如日期格式化），确实方便；但只要涉及迁移或兼容 PostgreSQL/MySQL，优先用 CAST，避免后期报 Invalid column name 'CONVERT' 这类错误。
-
CAST(expr AS type)更简洁，语义明确，适合类型强转场景（如CAST(id AS VARCHAR(10))） -
CONVERT(type, expr[, style])多一个style参数，在 SQL Server 里能控制日期/数字格式（如CONVERT(VARCHAR, GETDATE(), 120)得到'2024-05-21 14:30:00'），但 MySQL 的CONVERT不支持style，行为不一致 - 在 PostgreSQL 中用
CONVERT会直接报错：ERROR: function convert(unknown, unknown) does not exist
字符串转数字失败？先清理再转
CAST('123abc' AS INT) 或 CONVERT(INT, '123abc') 在 SQL Server 和 PostgreSQL 中都会报错：Conversion failed when converting the varchar value '123abc' to data type int. —— 它们不自动截断或忽略非法字符。
- 真实业务中常见字段是
varchar类型但混着空格、单位、符号（如'45.6 kg'、' 78 '），不能直接转 - SQL Server 可用
TRY_CAST('123abc' AS INT)或TRY_CONVERT(INT, '123abc')，失败返回NULL而非报错 - PostgreSQL 没有内置
TRY_CAST，得靠正则预处理：CAST(NULLIF(REGEXP_REPLACE(col, '[^0-9.-]', '', 'g'), '') AS NUMERIC)，但要注意小数点重复、负号位置等边界 - MySQL 8.0+ 可用
CAST(REPLACE(REPLACE(col, 'kg', ''), ' ', '') AS DECIMAL)，但没容错机制，建议先WHERE col REGEXP '^[0-9. ]+$'过滤
日期字符串转 DATE：格式不对就静默出错或错成 1900 年
CAST('21/05/2024' AS DATE) 在 SQL Server 默认语言为 English 时会报错；设成 British 才能认，但部署环境一换就崩。CONVERT(DATE, '21/05/2024', 103) 显式指定样式 103（dd/mm/yyyy）才可靠。
- 样式码必须匹配输入格式：101=mm/dd/yyyy，103=dd/mm/yyyy，120=yyyy-mm-dd hh:mi:ss（ODBC 规范，推荐）
- PostgreSQL 对
CAST('21-05-2024' AS DATE)会按当前datestyle解析，可能误判为 y-m-d 或 d-m-y；稳妥做法是统一用 ISO 格式：CAST('2024-05-21' AS DATE) - MySQL 的
STR_TO_DATE('21/05/2024', '%d/%m/%Y')更明确，但不是CAST/CONVERT体系，跨库时得重写
隐式转换陷阱：JOIN 或 WHERE 里别指望数据库帮你兜底
写 WHERE varchar_id = 123，数据库会悄悄把 123 转成字符串去比，表面没问题，但会导致索引失效（尤其 varchar 字段建了索引）。同理，JOIN t1 ON t1.code = t2.id，如果一边是 VARCHAR 一边是 INT，执行计划里常出现 CONVERT_IMPLICIT，CPU 升高、扫描变全表。
- 显式转换更可控：
WHERE varchar_id = CAST(123 AS VARCHAR(10))，且确保长度足够（别用CAST(123 AS VARCHAR(2))截断） - SQL Server 执行计划里看到
CONVERT_IMPLICIT就是警告信号，说明类型不匹配触发了运行时转换 - PostgreSQL 不允许
text = integer这种比较，直接报错，反而早暴露问题；但有人会绕成text::integer = integer，一旦 text 含非数字就崩
类型转换看着简单，真正卡住人的从来不是语法，而是数据质量不可控 + 数据库行为不一致 + 隐式转换藏在执行计划深处。动手前先 SELECT TOP 5 看原始值长什么样，比查文档还管用。
