选对时序数据库比写对代码更关键：TDengine适合设备量大、聚合查询多的物联网场景，需用超级表、正确配置TAGS和ts字段；InfluxDB适合Grafana集成的监控系统，须严格配置TOKEN、bucket、org及时间精度；LiteDB仅适用于单机边缘原型，无原生时序能力；ProcessDB未在资料中展开。
选对数据库比写对代码更关键——C#项目里用时序数据库，不是“能不能用”，而是“用哪个、怎么绕过它的坑”。TDengine、InfluxDB、LiteDB、ProcessDB 四类方案实际落地差异极大，不能套模板。
TDengine + SqlSugar：适合设备量大、查询聚合多的物联网场景
超级表（STABLE）是核心，别再为每个传感器建子表。建表语句里 TAGS 必须包含设备标识类字段（如 device_id），否则后续按设备分组查会失效。
-
taos.cfg中firstEp要写服务端真实 IP，客户端连不上八成是这里填了localhost - SqlSugar 的
.AS("device_001")必须和子表名完全一致，大小写敏感 - 时间字段必须叫
ts且类型为TIMESTAMP，否则INSERT会静默失败或时间错乱 - 批量写入别用循环
Insertable，改用InsertRange+ 原生 SQL 绑定参数，实测 1000 条数据耗时从 1.2s 降到 80ms
InfluxDB v2.x：适合已有 Grafana、需要灵活标签查询的监控系统
TOKEN 是硬性依赖，不是可选项。环境变量 INFLUX_TOKEN 没设或拼错，InfluxDBClient 构造时不会报错，但后续所有写操作都返回空响应。
- 写入必须指定
bucket和org，二者在 UI 初始化时创建，名字含空格或特殊字符会导致WritePoint失败 -
PointData.Measurement("mem")中的"mem"是 measurement 名，不是表名，不支持点号、斜杠等符号 - 时间戳精度默认是纳秒级，
DateTime.UtcNow直接传进去会丢毫秒，要用.AddTicks(-DateTime.UtcNow.Ticks % 10000)对齐 - 实体类映射需严格标注
[Column(IsTimestamp = true)]，漏掉这个属性，时间字段会被当普通field存，查询时无法用range()
LiteDB：适合单机部署、无运维能力的边缘设备或原型验证
它根本不是时序数据库，只是能存时间序列数据的文档库。别指望它支持降采样、滑动窗口或按 tag 分组聚合。
- 用
BsonDocument存数据最稳，强转实体类容易因字段缺失崩在反序列化阶段 - 索引只对
_id和显式EnsureIndex字段生效，timestamp字段不建索引，查最近 1 小时数据会全表扫 - 文件锁机制导致多进程写入必冲突，同一时刻只能一个
LiteDatabase实例持有写权限 - 没有原生时间范围查询语法，得靠
.Where(x => x["ts"].AsDateTime >= start && x["ts"].AsDateTime ，性能随数据量线性下降
ProcessDB：适合工业 SCADA 场景，但 C# SDK 文档极简、字段命名反直觉
它的 nMilliSecond 和 nSecond 是分离存储的，时间戳要手动拼： new DateTime(1970, 1, 1).AddSeconds(nSecond).AddMilliseconds(nMilliSecond)，直接用 nTime 字段会错 8 小时（时区没处理）。
-
connect()成功不代表可用，必须紧接着调init()，否则所有读写返回错误码 -1 - 点名（
name）最大长度 32 字节，超长截断不报错，但后续查不到数据 - 实时数据写入用
add_realtime_data_by_name，历史数据查用get_history_data_by_name，两个接口底层协议不同，混用会返回乱码 - SDK 不支持异步，高并发写入必须自己加
ConcurrentQueue+ 后台线程批处理，否则连接池会耗尽
真正麻烦的不是语法，而是每个库对“时间”的理解不同：TDengine 认为时间就是主键，InfluxDB 把时间当元数据维度，LiteDB 当普通字段，ProcessDB 拆成两个整数。选型前先拿真实数据跑一轮时间范围查询和 1000 点并发写入，比读十篇文档管用。
