cast函数仅做显式、合法、可推断的类型转换，失败时直接报错而非静默处理；语法必须为cast(expression as data_type)，as不可省略；字符串转数值需显式指定decimal精度；日期转换依赖iso格式；null可安全转换，非法值须前置校验。
CAST 函数不是万能转换器，它只做显式、合法、可推断的类型转换；失败时直接报错，不静默处理。
CAST(expression AS data_type) 语法必须写全，不能省略 AS
很多初学者误以为 CAST('123' INT) 合法，实际会报语法错误。SQL 标准强制要求使用 AS 关键字分隔表达式和目标类型。
-
CAST('123' AS INT)✅ 正确 -
CAST('123' INT)❌ 报错：Incorrect syntax near 'INT' - PostgreSQL 支持简写
'123'::INT，但这是特例，非标准 SQL，跨数据库不可移植 - MySQL 8.0+ 和 SQL Server 都严格要求
AS，省略即语法错误
字符串转数值时，精度和小数位必须显式指定 DECIMAL
把带小数点的字符串（如 '12.5'）转成数值，用 INT 或裸 DECIMAL 极易踩坑：
-
CAST('12.5' AS INT)❌ 直接报错：cannot cast type text to integer -
CAST('12.5' AS DECIMAL)⚠️ 在 SQL Server 中可能四舍五入为13（默认小数位为 0），行为不稳定 -
CAST('12.5' AS DECIMAL(5,1))✅ 明确精度 5、小数位 1 → 得到12.5，安全可控 - 若源字符串含空格或不可见字符（如
' 12.5 '），先用TRIM()，否则 CAST 可能失败
日期时间转换要警惕隐式格式依赖
CAST 解析字符串为日期时，不接受任意格式，严重依赖数据库本地设置和输入格式是否匹配：
-
CAST('2026-08-27' AS DATE)✅ 标准 ISO 格式，通用安全 -
CAST('27/08/2026' AS DATE)❌ 在 SQL Server 默认设置下报错，除非设SET DATEFORMAT DMY -
CAST('2026-08-27 14:30:00' AS DATETIME)✅ 但CAST('2026-08-27 14:30' AS DATETIME)在旧版 SQL Server 可能截断秒部分或报错 - 更稳妥的做法：优先用
TRY_CAST('...' AS DATE)（SQL Server 2012+、Azure SQL），失败返回 NULL 而非中断查询
NULL 和非法值处理：没有容错，只有报错或拒绝
CAST 对非法输入零容忍，不会自动跳过或转成默认值：
-
CAST('abc' AS INT)→ 报错：invalid input syntax for type integer -
CAST(NULL AS VARCHAR(10))✅ 合法，结果仍是NULL，不报错 - 想规避报错？得前置判断：
CASE WHEN ISNUMERIC(col) = 1 THEN CAST(col AS INT) ELSE NULL END（注意ISNUMERIC有缺陷，慎用） - 或改用
TRY_CAST(col AS INT)（SQL Server）、SAFE_CAST（BigQuery）、NULLIF+ 正则预检（PostgreSQL）等方案
真正容易被忽略的是：CAST 不改变原始数据语义，只做“解释性重读”。比如把 '00123' 转成 INT 得到 123，前导零丢失是转换逻辑本身决定的，不是 bug —— 这种隐含语义变化，在报表取数或比对时经常引发数据一致性问题。
