CAST是跨数据库兼容的标准函数，仅做类型映射，不支持格式化；CONVERT是SQL Server特有函数，支持style参数实现日期数字格式化，但不可移植。
CAST 是跨库安全的底线，别指望它能格式化
只要 SQL 脚本要跑在 PostgreSQL、MySQL 8.0+、SQL Server 甚至 SQLite 上，CAST 就是你唯一能无条件依赖的类型转换函数。它语法统一：CAST(expression AS target_type)，不带 style、不带额外参数，只做“类型映射”。这意味着你在 pgAdmin 里写的 CAST('2026-06-06' AS DATE)，粘到 SQL Server Management Studio 或 MySQL Workbench 里也能直接执行——前提是字符串是 ISO 格式。但别指望它能把日期转成 '2026年06月06日' 这种带中文的字符串，它根本不处理格式。
CONVERT 只在 SQL Server 里有用，换库就炸
CONVERT 是 SQL Server 的专属函数，MySQL 虽然也认 CONVERT(expr, type)，但参数顺序反了、不支持 style、行为也不一致；PostgreSQL 则会直接报错：ERROR: function convert(unknown, unknown) does not exist。所以如果你看到别人写的 CONVERT(VARCHAR, GETDATE(), 120)，千万别复制进跨库脚本里。它真正的价值只在 SQL Server 内部：用第三个参数 style 锁定解析逻辑，比如 CONVERT(DATE, '15/06/2026', 103) 明确告诉引擎这是 DD/MM/YYYY，避免因登录语言设置不同导致 '15/06/2026' 被误判成 2026-15-06（非法）或自动转成 1900 年。
字符串转数字失败？先清理，再用 TRY_CAST
报错 Conversion failed when converting the varchar value 'N/A' to data type int 或 invalid input syntax for integer: "123.45"，根本原因不是函数写错了，而是数据里混着空格、单位、字母、小数点、空字符串。硬套 CAST(col AS INT) 必崩。正确做法是：
- SQL Server：用
TRY_CAST(TRIM(col) AS INT)，TRIM去空格，TRY_CAST容错返回NULL - PostgreSQL：没
TRY_CAST，得靠正则预过滤：CAST(NULLIF(REGEXP_REPLACE(col, '[^0-9.-]', '', 'g'), '') AS NUMERIC)，但要注意负号位置和多个小数点 - MySQL：用
CAST(REPLACE(REPLACE(col, 'kg', ''), ' ', '') AS SIGNED)，但必须配合WHERE col REGEXP '^[0-9. ]+$'先筛一遍，否则静默截断不可控
日期字符串最危险，ISO 格式是唯一共识
所有数据库都认 '2026-06-06'，但对 '06/15/2026' 或 '15-06-2026' 解析规则完全不同。SQL Server 默认按 MDY，PostgreSQL 按 YMD（除非改 datestyle），MySQL 可能直接返回 NULL。你不能靠 CAST 或 CONVERT 去“猜”用户输入格式。真正可控的做法只有两个：
- 上游系统统一输出 ISO 格式（
YYYY-MM-DD），下游直接CAST(col AS DATE) - SQL Server 中非 ISO 输入，必须用
TRY_CONVERT(DATE, col, 103)显式指定样式码，失败返回NULL而非中断查询
别在 WHERE 条件里写 CAST(date_str AS DATE) > '2026-01-01'——只要一列里有非法值，整条语句就挂。容错必须前置，不是补救。
