MySQL用ON UPDATE CURRENT_TIMESTAMP最轻量可靠，需注意TIMESTAMP默认约束限制；PostgreSQL需触发器或GENERATED列；SQL Server须显式赋值或触发器；跨库应统一存UTC时间戳并禁用ORM自动时间戳。
MySQL中用ON UPDATE CURRENT_TIMESTAMP自动更新时间戳
MySQL原生支持在字段定义时添加ON UPDATE CURRENT_TIMESTAMP，只要该行被UPDATE（哪怕其他字段没变），就会自动刷新这个TIMESTAMP或DATETIME字段。这是最轻量、最可靠的方式，无需触发器或应用层干预。
常见错误是把字段类型设为TIMESTAMP却没加NOT NULL，导致插入NULL时触发隐式默认值覆盖；或者误用CURRENT_TIMESTAMP作为默认值又加了ON UPDATE，结果插入和更新都改时间——这通常不是想要的行为。
- 推荐写法：
last_modified TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 若需兼容微秒级，用
TIMESTAMP(6)并确保MySQL ≥ 5.6.4 - 注意：一个表里最多只能有一个
TIMESTAMP字段能用CURRENT_TIMESTAMP做默认值或更新值（MySQL 5.6以前限制更严） -
DATETIME类型从MySQL 5.6.5起也支持ON UPDATE CURRENT_TIMESTAMP，但不自动转换时区，适合需要UTC存储的场景
PostgreSQL中用GENERATED ALWAYS AS (now())或触发器
PostgreSQL不支持MySQL式的ON UPDATE语法，必须显式处理。最干净的做法是用GENERATED ALWAYS AS (now()) STORED（PG 12+），但仅适用于计算列且不能被UPDATE直接修改；更通用的是用触发器。
容易踩的坑是触发器函数里用NOW()而不是CURRENT_TIMESTAMP——二者在事务内行为一致，但NOW()是别名，可读性稍差；更大的问题是忘记在触发器中判断是否真有字段变更，导致无意义地更新last_modified，干扰MVCC版本判断。
- 安全写法：触发器函数内先比较
OLD.*和NEW.*（排除last_modified字段），仅当有差异才赋值NEW.last_modified := CURRENT_TIMESTAMP - 若用
GENERATED列，需确保应用层从不向该字段写入值，否则报错 - 时区统一靠
SET timezone = 'UTC'或建表时用TIMESTAMP WITH TIME ZONE，避免依赖客户端时区
SQL Server里靠DEFAULT约束 + UPDATE语句显式赋值
SQL Server没有自动更新时间戳的内置机制（ROWVERSION是二进制版本号，不是时间戳）。必须靠DEFAULT GETDATE()配合UPDATE时显式设置，或用AFTER UPDATE触发器。
最常被忽略的是：很多人给last_modified加了DEFAULT GETDATE()，却在UPDATE语句里完全不提这个字段，结果它永远停在插入时刻。SQL Server不会像MySQL那样“悄悄更新”。
- 推荐做法：所有UPDATE语句末尾统一加上
, last_modified = GETDATE() - 若无法控制所有SQL（如ORM生成），则必须用触发器，并注意触发器里用
GETUTCDATE()而非GETDATE()来保证UTC一致性 -
DATETIME2(3)比DATETIME精度更高、范围更大、时区无关，应作为首选类型
跨数据库统一时间格式的关键点
所谓“统一时间格式”，本质是统一时区基准和精度表达，不是字符串格式。应用层看到的"2024-03-15T14:22:08Z"只是展示层转换，数据库内部应始终存UTC时间戳。
最容易被绕过的细节是ORM框架（如Hibernate、TypeORM）的自动时间戳行为：它们可能用自己的逻辑覆盖数据库原生能力，比如Hibernate的@UpdateTimestamp会拦截SQL，导致MySQL的ON UPDATE失效；而TypeORM的@UpdateDateColumn默认用new Date()，受应用服务器时钟影响。
- 务必确认ORM是否禁用了数据库端自动更新，必要时关掉ORM的时间戳功能，回归数据库原生机制
- 所有数据库连接字符串里显式指定时区，例如MySQL加
&serverTimezone=UTC，避免JDBC驱动自动转本地时区 - 不要用
CONVERT(VARCHAR, GETDATE(), 126)这类函数存字符串时间——索引失效、无法计算、时区混乱
时区和精度问题往往在系统对接或日志排查时才暴露，等出问题再改成本很高。从建表那一刻就定死UTC + DATETIME/TIMESTAMP类型 + 显式约束，比后期补触发器或改ORM配置省力得多。
