CAST函数严格遵循SQL标准语法，必须写成CAST(expression AS target_type)，AS不可省略，目标类型因数据库而异；转换失败会直接报错而非静默处理，且各数据库对合法输入的判定边界不一致。
CAST 不是万能的类型转换开关，它严格遵循 SQL 标准语法，写错括号、漏关键字或目标类型不支持，立刻报错——比如 CAST(column AS INT) 在 PostgreSQL 里会失败，得写成 CAST(column AS INTEGER)。
CAST 语法结构必须完整，缺一不可
SQL 标准要求 CAST 必须带 AS 关键字和明确的目标类型，不能省略括号或用等号替代。常见错误是照着编程语言习惯写成 CAST(col to VARCHAR) 或 col::text（后者是 PostgreSQL 的非标简写，不是通用 CAST）。
-
CAST(expression AS target_type)是唯一合法形式，expression可以是列名、计算式或字面量 - 目标类型名因数据库而异：
VARCHAR(50)在 MySQL/SQL Server 可行，但 SQLite 只认TEXT；DECIMAL(10,2)各库基本兼容，但精度超出范围会截断或报错 - 空值（
NULL）可被CAST，结果仍是NULL，不会触发错误
字符串转数字时，隐式截断和错误行为差异大
把 '123abc' 这类脏数据用 CAST 转 INT，各数据库反应完全不同：MySQL 可能静默截取前缀 123，SQL Server 直接抛出 Conversion failed 错误，PostgreSQL 则拒绝转换并报 invalid input syntax。
- 安全做法是先用
REGEXP（MySQL/PostgreSQL）或LIKE（SQL Server）预筛合规字符串，再CAST - SQL Server 可改用
TRY_CAST()，失败返回NULL而非中断查询 - 避免在
WHERE子句中对大字段频繁CAST，可能使索引失效——比如WHERE CAST(phone AS BIGINT) = 123456789无法走phone索引
日期时间转换最容易踩时区和格式坑
把字符串 '2023-10-05' 转 DATE 看似简单，但若源字符串含时间部分或使用非标准分隔符（如 '05/10/2023'），CAST 会直接失败，不自动识别本地格式。
-
CAST('2023-10-05T14:30:00' AS TIMESTAMP)在 PostgreSQL 和 SQL Server 中有效，在 SQLite 中需先去掉T或用datetime()函数 - MySQL 对
CAST('05-OCT-2023' AS DATE)完全不认，必须是'2023-10-05'或通过STR_TO_DATE()先标准化 - 跨库迁移时，
CAST的日期行为差异比数值更隐蔽——同一语句在开发环境（PostgreSQL）跑通，上线到生产（SQL Server）突然报错
真正麻烦的不是语法本身，而是不同数据库对“合法输入”的定义边界不一致，尤其在处理用户输入或日志导入这类不可控数据时，CAST 往往是第一个报错环节，而不是最后一个转换工具。
