MySQL、PostgreSQL、SQLite和SQL Server中NOW()与CURRENT_TIMESTAMP行为差异显著：MySQL二者等价但DDL仅认后者；PostgreSQL中NOW()是CURRENT_TIMESTAMP别名但不支持精度参数；SQLite不支持NOW()，仅用datetime('now')；SQL Server无NOW()，仅用GETDATE()或SYSDATETIME()。
没有本质区别——但具体到每个数据库，行为、语法限制和容易踩的坑完全不同。直接换着用，大概率在迁移或升级时出错。
MySQL里NOW()和CURRENT_TIMESTAMP()完全等价，但DDL中只认后者
二者底层共享同一实现，返回值、类型、时区行为完全一致。但建表时写CURRENT_TIMESTAMP（不带括号）是合法默认值，而NOW()或NOW会报错：Invalid default value for 'xxx'。
-
CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP支持自动更新，NOW()不能用于ON UPDATE子句 - 想带毫秒？必须显式写
CURRENT_TIMESTAMP(3)或NOW(3)，默认都只有秒级精度 - 漏括号如
NOW会被解析成列名，直接触发ERROR 1064 - 严格模式下，
CURRENT_TIMESTAMP()（带空括号）虽合法，但易被误读为可传参，建议统一用CURRENT_TIMESTAMP（无括号）作默认值、NOW()作查询函数
PostgreSQL中NOW()只是CURRENT_TIMESTAMP的同义词，但参数支持不一致
源码里NOW()被注册为CURRENT_TIMESTAMP的别名，调用同一函数timestamp_now()，事务内时间冻结行为也完全相同。但语法上不是“镜像”：
-
CURRENT_TIMESTAMP(3)合法，返回毫秒级timestamptz -
NOW(3)会报错：function now(integer) does not exist - 建表时
DEFAULT CURRENT_TIMESTAMP没问题，DEFAULT NOW()虽能通过，但部分ORM（如Django ORM早期版本）会解析失败 - 二者都返回
timestamptz，但NOW()更像函数调用，CURRENT_TIMESTAMP更接近SQL标准伪常量
SQLite和SQL Server根本不认NOW()
NOW()在SQLite里不存在，直接执行SELECT NOW()报错：no such function: NOW；SQL Server压根没有这个函数。
- SQLite只能用
datetime('now')或strftime('%Y-%m-%d %H:%M:%f', 'now') - SQLite的
CURRENT_TIMESTAMP仅限建表默认值，不能在SELECT中直接用 - SQL Server用
GETDATE()（精度3.33ms）或SYSDATETIME()（纳秒级），CURRENT_TIMESTAMP只是GETDATE()别名，NOW()语法错误 - 跨库写SQL时，如果混用二者又没做适配，部署到新环境第一句就挂
最危险的不是功能差异，而是“看起来一样”的假象——CURRENT_TIMESTAMP在MySQL里能当默认值，在SQLite里只能当字面量，在PostgreSQL里支持精度参数，在SQL Server里精度受限。写之前先查目标数据库的文档，别靠经验猜。
