current_timestamp是sql标准函数，返回数据库服务器当前日期和时间，类型为timestamp或timestamp with time zone；它不是字符串或unix时间戳，而是可直接存入对应类型字段的原生时间值。
CURRENT_TIMESTAMP 是什么，它返回什么类型
CURRENT_TIMESTAMP 是 SQL 标准函数，返回数据库服务器当前的日期和时间（带时区或不带时区，取决于具体数据库实现）。它不是字符串，也不是整数，而是一个 TIMESTAMP 或 TIMESTAMP WITH TIME ZONE 类型值——这意味着你可以直接存入 TIMESTAMP 类型字段，无需转换，但不能直接和 VARCHAR 字段拼接或比较。
常见误区是以为它返回 Unix 时间戳（秒数），其实不是：CURRENT_TIMESTAMP 返回的是可读时间值，比如 2024-06-12 14:30:22.123；要获取 Unix 时间戳得用 EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)（PostgreSQL）或 UNIX_TIMESTAMP()（MySQL）。
在 INSERT 语句中自动记录创建时间
最常用场景是插入新记录时自动填充 created_at 字段。直接把 CURRENT_TIMESTAMP 当作默认值写进 VALUES 即可：
INSERT INTO orders (id, product, created_at) VALUES (101, 'laptop', CURRENT_TIMESTAMP);
注意：不同数据库对默认值支持程度不同——PostgreSQL 和 MySQL 8.0+ 允许在列定义里设 DEFAULT CURRENT_TIMESTAMP，但 SQLite 需显式写出；SQL Server 用 GETDATE() 替代，不识别 CURRENT_TIMESTAMP 作为默认表达式（尽管语法上接受，但行为受限）。
- MySQL 中
CURRENT_TIMESTAMP可作为列默认值，且支持自动更新（ON UPDATE CURRENT_TIMESTAMP） - PostgreSQL 中推荐用
NOW()（语义等价，但更明确），CURRENT_TIMESTAMP在 DDL 中可用，但不能带精度参数如CURRENT_TIMESTAMP(3)（需写成CURRENT_TIMESTAMP(3)才生效，否则默认微秒精度） - SQLite 不支持列级默认函数调用，必须显式写入
VALUES(..., datetime('now'))
和 NOW()、SYSDATE() 的区别在哪
它们都返回当前时间，但语义和行为有差异：
-
CURRENT_TIMESTAMP是 SQL 标准函数，在多数数据库中表现一致，但实际值“冻结”时机可能不同：PostgreSQL 中在事务开始时确定，MySQL 中每行计算一次（除非在严格模式下） -
NOW()是 MySQL/PostgreSQL 的别名，行为与CURRENT_TIMESTAMP几乎相同，但 MySQL 中两者完全等价；PostgreSQL 中NOW()更常用，且支持更直观的时区调整，如NOW() AT TIME ZONE 'UTC' -
SYSDATE()是 Oracle 和 MySQL 特有函数——MySQL 中它返回执行时刻的时间（不受事务影响），而CURRENT_TIMESTAMP在同一事务内多次调用返回相同值；Oracle 中SYSDATE无括号，且始终返回系统时间，不考虑会话时区
如果你需要“每次调用都真实反映此刻”，而不是事务快照时间，MySQL 下应选 SYSDATE()；PostgreSQL 没对应函数，需用 CLOCK_TIMESTAMP() 替代。
时区问题怎么处理才不会出错
CURRENT_TIMESTAMP 默认返回数据库服务器本地时区的时间，不是 UTC，也不是客户端时区——这常导致日志时间混乱或跨时区应用逻辑错误。
解决方式取决于数据库：
- PostgreSQL：启动时设置
timezone = 'UTC'，或连接后执行SET timezone = 'UTC';，之后CURRENT_TIMESTAMP就返回 UTC 时间 - MySQL：全局变量
time_zone控制行为，建议设为'+00:00'，并确保表字段类型是TIMESTAMP（自动转为 UTC 存储），而非DATETIME（原样存储） - SQL Server：没有内置时区感知的
CURRENT_TIMESTAMP，改用SYSDATETIMEOFFSET()获取带偏移的时间，再用AT TIME ZONE转换
别依赖应用层“统一转 UTC”——时间在写入数据库前就可能被客户端时区污染，尤其 ORM 自动生成 SQL 时容易忽略这点。
