应存入数据库的INTEGER/BIGINT字段，因time.time_ns()返回19位纳秒整数，用浮点类型会丢失精度；解析时须先转秒级再处理纳秒部分，避免直接用fromtimestamp()导致溢出或截断。
Python time.time_ns() 返回的值怎么存进数据库
直接存进 INTEGER 字段最稳妥。它返回的是自 Unix 纪元起的纳秒整数，典型值像 1717023456123456789（19 位），MySQL/PostgreSQL/SQLite 的 BIGINT 或 INTEGER 都能装下。
别用 FLOAT 或 DOUBLE 存——浮点数在 1015 以上就开始丢精度，纳秒级时间戳一存就偏几毫秒甚至更多。
- PostgreSQL：用
BIGINT，不是NUMERIC，后者虽准但慢、占空间 - MySQL：用
BIGINT SIGNED，UNSIGNED虽然能多存几年，但 Python 的time.time_ns()永远是正数，没必要徒增迁移风险 - SQLite：用
INTEGER，它本来就是 64 位有符号整型，完全匹配
用 datetime.fromtimestamp() 解析纳秒时间戳会出错
因为 datetime.fromtimestamp() 只接受秒级或最多微秒级浮点数，传入纳秒整数会报 OverflowError: timestamp out of range for platform time_t 或静默截断成错误时间。
正确做法是先除以 1_000_000_000 转成秒级浮点（保留小数），再传给 fromtimestamp()；或者更推荐——用整数除法和取模拆出秒+纳秒，再用 datetime.fromtimestamp(ts_sec, tz=timezone.utc).replace(microsecond=ts_ns % 1_000_000 // 1000) 手动拼，避免浮点误差。
立即学习“Python免费学习笔记（深入）”；
- 别写
datetime.fromtimestamp(ns_ts / 1e9)：1e9是 float，除法结果仍是 float，仍有精度风险 - 如果只要 UTC 时间且不关心本地时区，优先用
datetime.utcfromtimestamp(ns_ts // 1_000_000_000)+ 手动补纳秒部分到microsecond字段（注意纳秒转微秒要整除 1000） - 用
time_ns()记录的时间，本身不含时区信息，解析时别默认当成本地时间
SQLite 中用 strftime() 查纳秒时间戳很麻烦
SQLite 的 strftime() 函数只支持秒级时间，没有纳秒参数。直接对纳秒整数调用 strftime('%Y-%m-%d', ns_ts) 会当成“秒”处理，结果比真实时间早 109 倍——也就是回到公元前。
必须先换算：strftime('%Y-%m-%d', ns_ts / 1000000000, 'unixepoch')，而且得确保除法结果是浮点数（SQLite 会自动做类型推导，但显式写 1000000000.0 更稳）。
- WHERE 条件里比较纳秒时间戳，别写
ns_ts > strftime('%s', '2024-01-01')：这是把字符串转成秒再当纳秒用，逻辑全反了 - 想查“今天之后”的记录，得写
ns_ts > (strftime('%s', 'now') * 1000000000) - 如果频繁按日期范围查询，考虑额外加一个
date_day INTEGER字段存ns_ts // 86400000000000（当天 0 点纳秒），用整数索引加速
Pydantic v2 模型里字段类型选 int 还是 conint
存纳秒时间戳就用原生 int。Pydantic v2 对 int 的校验足够强，能拦住 float、str、None 等非法输入，而 conint(ge=0) 只是多一层冗余检查，还可能掩盖真正的问题——比如上游传了个超大负数，你本该报警，而不是让它静默变成 0。
- 别用
float字段接time.time_ns()：Pydantic 会尝试转换，但会丢失精度，且类型语义错误 - 如果字段可能为空，用
Optional[int]，别用int | None（v2 不识别这种联合写法） - 序列化输出时若需兼容前端 JS 的
Date.now()（毫秒级），记得在@field_serializer里手动除以1_000_000并转int，别依赖自动转换
纳秒时间戳看着只是多几个零，但每一步转换都卡在整数/浮点、秒/纳秒、本地/UTC 这三道缝里，漏掉任意一个，时间就悄悄漂移了。
