CURRENT_DATE返回DATE类型值，非字符串，直接拼接会导致跨数据库兼容性问题；应显式转换为字符串，如PostgreSQL用TO_CHAR、MySQL用DATE_FORMAT、SQL Server用FORMAT或CONVERT。
CURRENT_DATE 返回什么类型，为什么不能直接当字符串拼接用
CURRENT_DATE 返回的是 DATE 类型值，不是字符串。很多新手在写 WHERE date_col = '2024-05-20' 时，想替换成 CURRENT_DATE 就直接拼： 'today is ' || CURRENT_DATE —— 这在 PostgreSQL 里能过，但在 MySQL 或 SQL Server 里会报错或静默转成意外格式。
真正安全的做法是显式转换：
– PostgreSQL / Oracle：用 TO_CHAR(CURRENT_DATE, 'YYYY-MM-DD')
– MySQL：用 DATE_FORMAT(CURRENT_DATE, '%Y-%m-%d')
– SQL Server：用 FORMAT(CURRENT_DATE, 'yyyy-MM-dd')（需 SQL Server 2012+）或更兼容的 CONVERT(VARCHAR(10), CURRENT_DATE, 120)
在 WHERE 条件中比较日期时，CURRENT_DATE 和 NOW() 有什么区别
CURRENT_DATE 只返回日期部分（年-月-日），NOW()（或 CURRENT_TIMESTAMP）返回带时分秒的时间戳。如果你查当天所有订单，用 order_date = CURRENT_DATE 是对的；但若字段是 DATETIME 类型且存了时间，比如 '2024-05-20 14:30:00'，那 = CURRENT_DATE 就会不匹配——因为数据库会把 CURRENT_DATE 隐式转成 '2024-05-20 00:00:00'。
- 安全写法是：
DATE(order_date) = CURRENT_DATE（MySQL/PostgreSQL） - 或范围查询：
order_date >= CURRENT_DATE AND order_date （PostgreSQL） - SQL Server 推荐：
CAST(order_date AS DATE) = CAST(GETDATE() AS DATE)
不同数据库对 CURRENT_DATE 的支持和行为差异
标准 SQL 定义了 CURRENT_DATE，但各数据库实现细节有出入：
- PostgreSQL：严格按会话时区返回，受
timezone参数影响 - MySQL：不依赖系统时区设置，但受
time_zone会话变量控制；注意CURRENT_DATE()带括号是函数调用形式，CURRENT_DATE不带括号是标准语法，两者等价 - SQL Server：没有
CURRENT_DATE，必须用CAST(GETDATE() AS DATE)或CAST(SYSDATETIME() AS DATE) - SQLite：支持
CURRENT_DATE，返回格式为'YYYY-MM-DD'字符串（不是 DATE 类型！），所以可直接拼接，但类型不一致可能影响索引使用
为什么在 INSERT 或 DEFAULT 约束里直接写 CURRENT_DATE 是安全的
在建表时设默认值，比如 created_date DATE DEFAULT CURRENT_DATE，这是最稳妥的用法之一。数据库会在插入行时求值，且不依赖客户端时钟或连接参数。
要注意的坑：
- MySQL 中如果字段是
DATETIME类型，DEFAULT CURRENT_DATE会报错，必须用DEFAULT CURRENT_TIMESTAMP或显式指定类型 - PostgreSQL 允许
DEFAULT CURRENT_DATE用于DATE字段，但不能用于TIMESTAMP字段（会提示类型不匹配） - 避免在 UPDATE 语句里写
SET updated_at = CURRENT_DATE而不加 WHERE —— 容易误更新整张表
时区、类型隐式转换、字段定义约束这三点，比记住语法更容易出问题。实际写 SQL 时，先看字段类型，再选函数，最后确认数据库版本是否支持——比查文档更快的办法，是直接 SELECT CURRENT_DATE, NOW(), VERSION(); 看一眼。
