CURRENT_TIMESTAMP能直接用于INSERT VALUES，问题在于默认值定义、类型匹配与时区精度未对齐导致审计不可靠：MySQL需显式CURRENT_TIMESTAMP(3)配TIMESTAMP(3)，PostgreSQL应选TIMESTAMP WITH TIME ZONE配CURRENT_TIMESTAMP，SQL Server需用SYSDATETIME()替代以获更高精度。
为什么 CURRENT_TIMESTAMP 不能直接用在 INSERT 的 VALUES 里做审计时间？
因为 CURRENT_TIMESTAMP 是一个“运行时求值”的函数，不是常量。当你写 INSERT INTO log (id, created_at) VALUES (1, CURRENT_TIMESTAMP)，它确实能工作——但问题出在更常见的场景：你可能想把它设为列的默认值，或者用于触发器中自动填充。这时候如果表定义没配对，就会漏掉精度或时区信息。
- MySQL 5.6+ 默认只保留秒级（
CURRENT_TIMESTAMP等价于CURRENT_TIMESTAMP(0)），要毫秒得显式写CURRENT_TIMESTAMP(3) - PostgreSQL 的
CURRENT_TIMESTAMP默认带微秒，但如果你用timestamp without time zone类型，时区信息就丢了，审计溯源时可能跨时区错乱 - SQL Server 的
CURRENT_TIMESTAMP实际是GETDATE()别名，只有毫秒精度，且不带时区；要用更高精度得换SYSDATETIME()
怎么让审计时间字段真正“自动、精确、可追溯”？
关键不是调用函数本身，而是把类型、默认值、约束三者对齐。否则同一句 INSERT 在不同环境结果不一致，审计日志就不可信。
- PostgreSQL：用
timestamp with time zone DEFAULT CURRENT_TIMESTAMP，别用now()——后者虽等价，但语义模糊，且某些 ORM 会误判为非确定性函数 - MySQL：声明列时必须带精度，例如
created_at TIMESTAMP(3) DEFAULT CURRENT_TIMESTAMP(3)；如果建表后改，得用ALTER TABLE ... MODIFY COLUMN ...，单纯ALTER TABLE ... DEFAULT CURRENT_TIMESTAMP(3)不生效 - SQLite：没有原生
CURRENT_TIMESTAMP默认值支持，得用触发器或应用层生成；若强行写DEFAULT CURRENT_TIMESTAMP，它只支持秒级，且不响应strftime('%Y-%m-%d %H:%M:%f')这类格式化
审计时间被覆盖或重复更新怎么办？
CURRENT_TIMESTAMP 默认行为在某些数据库里会“自动更新”，比如 MySQL 的 ON UPDATE CURRENT_TIMESTAMP，这在审计场景下是陷阱——只要行一改，原始创建时间就被冲掉了。
- MySQL 中，如果只想要创建时间不更新，必须显式禁用：
created_at TIMESTAMP(3) DEFAULT CURRENT_TIMESTAMP(3) NOT NULL（不加ON UPDATE子句） - 如果还要记录最后修改时间，另建一列：
updated_at TIMESTAMP(3) DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3)，和created_at分开 - PostgreSQL 没有隐式
ON UPDATE，但如果你写了触发器或用了DEFAULT now()而不是CURRENT_TIMESTAMP，可能在批量更新时意外重写审计字段
应用层插入时手动传 CURRENT_TIMESTAMP 安不安全？
不推荐。客户端本地时间不可信，时钟漂移、时区配置错误、NTP 同步延迟都会导致审计时间偏移甚至倒流。
- Java JDBC 插入时传
java.time.Instant.now()，如果数据库用的是timestamp without time zone，JDBC 驱动可能按 JVM 时区转成本地时间再入库，和服务器时间对不上 - Python 的
datetime.now()默认是本地时区，传给 PostgreSQL 的timestamp with time zone字段前没调.astimezone(timezone.utc)，就会存错 - 最稳的方式：让数据库自己算，SQL 写成
INSERT INTO audit_log (event, created_at) VALUES ('login', CURRENT_TIMESTAMP)，而不是拼字符串或传参数
