current_time 返回数据库服务器当前本地时间，仅含时分秒、不带日期，精度默认到秒（部分支持毫秒），时区由操作系统决定，非客户端或utc时间。
CURRENT_TIME 返回的是什么时间？
CURRENT_TIME 返回的是数据库服务器当前的本地时间，精确到秒（部分数据库支持毫秒），不带日期，只含时分秒。它不是客户端时间，也不是 UTC 时间，而是由数据库服务进程所在操作系统时区决定的值。
- PostgreSQL 中
CURRENT_TIME默认带时区（如14:23:56.123+08），可用CURRENT_TIME(0)截断小数秒 - MySQL 没有标准
CURRENT_TIME，实际用的是CURTIME()，返回无时区的HH:MM:SS - SQL Server 不支持
CURRENT_TIME，应改用CAST(GETDATE() AS TIME)或SYSTIMEZONE配合GETUTCDATE()转换 - SQLite 支持
CURRENT_TIME，但底层依赖系统时钟，且不记录时区信息
在 WHERE 条件里直接用 CURRENT_TIME 安全吗？
不安全——尤其当字段是 TIME 类型且含毫秒时，容易因精度不一致导致查不到数据。比如表中存的是 '09:30:45.123'，而 CURRENT_TIME 返回 '09:30:45'，严格等于会失败。
- 推荐用范围判断代替等值：
WHERE event_time BETWEEN CURRENT_TIME - INTERVAL '1 SECOND' AND CURRENT_TIME + INTERVAL '1 SECOND'（PostgreSQL） - MySQL 中可统一转为字符串再截断：
WHERE TIME(event_time) = TIME(CURTIME()) - 避免在大表上对
CURRENT_TIME做函数索引依赖，它无法利用普通TIME列上的 B-tree 索引
CURRENT_TIME 和 NOW() / CURRENT_TIMESTAMP 有什么区别？
CURRENT_TIME 只返回时间部分，NOW() 和 CURRENT_TIMESTAMP 返回完整时间戳（日期 + 时间）。三者都基于同一时刻快照，但类型和用途不同。
- 插入仅需记录“几点发生的事件”时，用
CURRENT_TIME更语义清晰，也节省存储（相比TIMESTAMP） - 如果字段定义为
TIME WITH TIME ZONE（PostgreSQL），CURRENT_TIME自动带时区，而NOW()是TIMESTAMP WITH TIME ZONE，类型不兼容需显式转换 - MySQL 中
NOW()和CURTIME()是独立函数，不能混用；误写CURRENT_TIME()会报错FUNCTION does not exist
跨数据库写法怎么尽量兼容？
没有完全通用的写法，但可通过条件化 SQL 或应用层兜底降低风险。硬写 CURRENT_TIME 在 MySQL 和 SQL Server 上会直接报错。
- 建表时若需时间字段默认值，PostgreSQL 可用
DEFAULT CURRENT_TIME，MySQL 必须用DEFAULT CURTIME()，SQL Server 用DEFAULT CAST(GETDATE() AS TIME) - 应用代码中建议把“获取当前时间部分”逻辑收口到 DAO 层，不同方言走不同分支，而不是拼 SQL 字符串
- 测试时务必在目标数据库上验证，比如 SQLite 的
CURRENT_TIME不支持参数，而 PostgreSQL 支持CURRENT_TIME(precision)，传参会导致语法错误
时区和精度是实际用起来最常翻车的地方，尤其是把开发环境（UTC）和生产环境（CST）混在一起测试的时候。
