sfsDb：嵌入式单文件时序数据库实战，解决边缘存储与云边同步难题

搞设备数据接入这些年，我见过不少团队在处理边缘侧时序数据时被卡住：网关盒子就在现场，每秒涌进来成千上万条测点，云端链路一抖就断，数据一断就是几个小时。想先在边缘把数据存好、算完再上送，但本地的存储方案要么太重、要么太糙，要么把自己写成一个不可维护的文件堆，最后往往又回到“先传云端再说”的老路上。sfsDb 就是在这个背景下冒出来的一个新选择，它没有把“边缘优先”当成口号，而是把嵌入式、单文件、自带查询引擎这几个能力直接做进了数据库内核。这篇文章我就结合自己在某条模拟产线项目里的完整试用过程，把 sfsDb 的架构思路、实操写法和云边同步方案一次说清楚，也把我在使用中踩过的坑原样分享出来。对正在选型边缘数据底座、或者还在纠结“边缘数据到底怎么存”的人，应该会有直接帮助。

1. 边缘侧的时序数据，到底难在哪里

1.1 一台设备的日常数据量就能让你改方案

很多没做过工业数据接入的人，对“时序数据量”是没有体感的。我举个例子：假设现场一台设备上有 50 个测点，采集频率 1Hz，一天下来就是 50×86400 = 432 万条记录。这只是一台设备，而且只是 1Hz，实际上很多振动测点、电能质量测点会做到 10Hz、100Hz，数据量直接再翻几十倍。

我参与的那个模拟产线项目，一共 30 台设备，其中一半做了 5Hz 采集，另一半还是 1Hz。按最保守估算，一天新增记录在 8000 万条以上。如果全量存成文本日志，一天就是 6~8GB，一个月 200GB 起步。边缘网关的存储通常就 64GB 到 512GB，照这个速度根本撑不了几天。而且这些数据并不是“存了就完”，产线质量回溯、设备劣化分析、故障定位，都需要几个月甚至几年的历史数据随时反查。也就是说，不止要存得下，还得查得快、查得到。单靠日志文件或者普通数据库的堆盘模式，是撑不住这种量级的。

1.2 云端方案搬不过来，自研方案撑不住

遇到这种问题，很多团队的直觉是把云端那一套时序库直接搬到边缘。确实，业界主流的服务端时序数据库功能很全、查询很强，但它的问题是运行态太重：要常驻进程、要单独配置内存池、要按集群规划容量，这一套对一台 2 核处理器、512MB 内存的 ARM 网关来说，别说跑起来，光是安装和运维就已经劝退了。

也有人用通用关系库来硬扛。关系库的优势是生态熟、上手快，但它的存储模型是按行组织的，对时间范围的扫描性能天然不友好，一旦表里数据量到了千万级，“先建索引再查询”的路径就越走越慢。而且关系库通常不会自动压缩历史分区、不会自动做降采样、不会按时间线清理过期数据，结果就是磁盘一天天膨胀，最后运维的人陷入手工维护的噩梦。

还有人选择自己写文件存储，按天按小时把数据切成文本文件，再用脚本封装读写接口。这个方案最灵活，但坑最深：坐标跳变、时区错乱、乱序写入、文件句柄泄露、聚合查询要全表扫描……我见过不止一个团队最后被自研方案拖进泥潭。前前后后对比了这么多方案，我把边缘侧对时序数据底座的需求归纳成了一张清单，一共七项，每一项都对应我真实踩过的坑。

1.3 边缘时序库的明确需求列表

这七点不是按优先级排序的，缺任何一条，在真实边缘项目里都会在某一天变成一个隐蔽的坑。比如没有自动生命周期管理，看起来没事，三个月后磁盘被撑爆；没有幂等同步，看起来没事，一次断网就产生一堆重复数据；没有高压缩能力，看起来也没事，等你想留存一年数据时才会猛然发现容量完全不够。sfsDb 之所以让我愿意花时间写这篇东西，恰恰就是因为它把这七条当成默认约束，而不是后期打补丁。

2. sfsDb 的设计思路：把数据库做成一个文件

2.1 第一个取舍：嵌入式还是独立服务

单看 sfs 这几个字母，很多人都猜是某个存储相关的缩写，官方没给明确解释，我觉得不重要，重要的是它把时序数据库装进了一个文件里。sfsDb 做的第一个决定，就是彻底不做独立服务。它只有一个核心库文件，应用进程直接链接 SDK，打开数据库文件，剩下的读写查全在自己进程里完成。这个思想其实和单文件嵌入式数据库很像，但 sfsDb 把它平移到时序场景，而且处理得更彻底，压缩、降采样、同步这些重功能都塞进了库文件内部。

为什么在边缘场景必须嵌入式？道理很简单：边缘节点上通常同时跑着采集程序、算法程序和运维代理，每个程序都要抢内存、抢CPU。如果时序库再起一个独立进程，一方面要分配独立的内存池，另一方面还多了一层进程间通信的序列化开销。嵌入式方案没有这两块成本，查询直接在内存里完成，进程退出即释放资源。

更关键的是可靠性。工业现场的边缘盒子经常面临突然断电，独立服务需要做崩溃恢复、WAL 重放，一套流程下来非常复杂。sfsDb 把存储文件本身设计成崩溃一致的：上一次成功提交的写入在重启后立即可读，没提交的半截写入会被自动丢弃，不需要额外修复步骤。这一点在无人值守的边缘场景里，价值远超在云端数据中心里能想象到的程度。

2.2 存储引擎：分段写、列式存、汇总压缩

sfsDb 的核心存储结构是“时间分段 + 列式布局 + 双层压缩”。存储文件内部，数据按固定的时间跨度切分成多个数据段，比如每个段覆盖 1 小时或者 1 天，具体跨度在建库时可按数据密度配置。每个段内部，同一列的数据被连续存放，这一布局对“按时间范围扫某几个字段”的查询非常有利，因为读出来的是连续内存，CPU 缓存可以充分命中。

写入路径上，sfsDb 只做 append-only 追加。新到的数据先落在内存缓冲区，达到阈值后按时间排序，再刷成一个不可变的数据段。由于是顺序写，机械硬盘和闪存盘都能拿到接近设备上限的写入带宽，这是它能在低配硬件上保持高吞吐的根本原因。

压缩则分两层。第一层是编码层：时间戳用增量编码，数值用 XOR 补偿编码或者固定 delta 编码，标签字串用字典编码；第二层是通用压缩层，统一交给 zstd 级别的算法再压一道。我实测里，一组 1Hz 的温度、压力测点混合数据，原始 CSV 文本约 5.2GB，导入 sfsDb 后只有 780MB，压缩比接近 6.7:1，这还没开高级编码选项。对边缘侧的存储容量焦虑来说，这种压缩比直接决定了一台设备能本地留存多久的数据。

2.3 自动数据生命周期：TTL 和降采样

边缘设备的数据生命周期管理，是普通数据库很少照顾到、但边缘场景里最刚需的能力。举个典型情况：产线要求设备数据保留 90 天，但高频率的原始测点保留 90 天成本太高，能不能只留 30 天的原始值，再留 90 天的分钟级聚合值？

sfsDb 把这种需求做成了声明式配置。建表时可以直接给一张表定义多级保留策略：比如原始数据 TTL 30 天，30 天后自动降采样到分钟级均值，分钟级数据再存活 60 天。整个过程由数据库自身在后台任务里完成，应用层完全不用感知。

这个机制的实现基础是前面说的分段文件。当某个时间段的原始数据超过设定的 TTL，数据库并不是去逐行删除记录，而是直接把整个数据段标记为“可替换”，并触发一次降采样合并：把段内同一分钟的数据聚合成一条，生成新的段，再丢掉旧段。整段替换比逐行删除效率高得多，这在千万级记录的库上差别非常明显。我见过不少团队因为在边缘侧没有这一类能力，最后不得不靠半夜定时任务去手工删表，那种方案既不安全也不可持续。

2.4 索引与查询：标签索引 + 时间游标

时序查询几乎总是用“时间范围 + 若干标签条件”来定位数据，比如“查设备 d-001 从昨天 8 点到 10 点的温度均值”。sfsDb 对标签建了稀疏索引，索引项是（标签值哈希，起始时间戳）的组合，落在磁盘上的是一张紧凑的倒排表，不需要像通用关系库那样去维护庞大的 B+ 树。

真正查询时，数据库先通过标签索引过滤出候选设备列表，再为每个候选设备沿着时间轴做游标扫描。因为数据段本身是有序的，扫描过程不会产生随机 IO。聚合算子比如 mean、max、min、count、rate 都是在扫描过程中直接累计的，不需要把原始记录全部读回内存再算。这意味着即使查询跨度很大，实际扫描量仍然可控，这是 sfsDb 能保持轻量的重要原因。

我在模拟项目里做过一个统计：从 2000 多万条记录里，查某 3 台设备近 24 小时的均值，返回 72 万条原始点参与的 12 行聚合结果，耗时约 120ms。对边缘侧这种查询场景来说，已经是相当可用的水平。当然这个数字只代表我自己的环境，具体性能还是要按实际设备验证。

3. 实操上手：建库、写入、查询全流程

3.1 编译嵌入式 SDK 与命令行工具

sfsDb 的部署形态让我印象深刻：它跟普通嵌入式项目完全一致，先把 SDK 编译进目标平台的库文件，再链接进业务程序即可。官方工具链不开独立后台，启动后不产生任何守护进程。部署的第一步是把源码包拉下来，解压之后进入目录，执行 CMake 构建。我用的命令大致是这样：

cd sfsdb cmake -B build \ -DCMAKE_BUILD_TYPE=Release \ -DSFSDB_BUILD_TOOLS=ON cmake --build build -j4

构建产物包含两个部分：一个静态库和一个命令行工具sfsdb-cli。命令行工具主要用于验证环境和手工查数，生产环境里我基本只使用 SDK 提供的 C API。

如果目标设备是 ARM 架构，思路也一样：在交叉编译环境里把CMAKE_TOOLCHAIN_FILE指向对应的工具链文件，再指定CMAKE_CROSSCOMPILING=ON，编译一次得到目标平台的.a文件，然后丢进边缘盒子的编译链。我第一版踩过的坑是漏掉给编译器传-mfpu=neon选项，导致某些 ARMv7 设备上的编码路径退回到标量实现，性能掉了一大截。后来把编译参数对齐到 SDK 文档推荐的默认值就正常了。

另外提醒一句：虽然我演示的是源码构建，但如果只是想在电脑上快速体验，直接用 release 页面的预编译二进制包完全可以，没必要从源码折腾一遍。源码构建更多是为了排查可疑的编译配置，或者定制底层编码选项。

3.2 建库建表：字段类型和 TTL 怎么选

连接数据库并创建第一张表，可以直接在sfsdb-cli里执行：

sfsdb-cli /opt/edge/data/plc_01.sfsdb

然后创建一张测点数据表：

CREATE TABLE device_metrics ( ts TIMESTAMPTZ NOT NULL, device_id VARCHAR(32) TAG, metric VARCHAR(32) TAG, value DOUBLE PRECISION, status SMALLINT ) TTL INTERVAL '15 days' COMPRESSION 'auto' PARTITION BY DAY;

这里有几个字段类型的设计细节值得聊一聊。首先是 ts 字段，它是每张时序表的强制字段，存储的是 Unix 毫秒时间戳，默认按时间戳排序写入。其次，device_id和metric被声明成 TAG 类型，这和我前面讲的标签索引是直接对应的，凡是查询条件里会出现的高频过滤字段，都应该声明成 TAG，而不是普通列。普通列走的是列式存储，适合数值型数据和状态量。

TTL 参数这里我写的 15 天，是针对“原始全量数据”的保留时长。我建议先按业务要求定一个最小值，再结合降采样层级做多级保留。PARTITION BY DAY 决定了数据段的切分粒度，如果数据密度特别大，比如每秒上千条，可以改成 PARTITION BY HOUR，这样 TTL 清理和降采样触发会更频繁，单段体积更可控，回收空间也更及时。

3.3 批量写入：别一条一条来

边缘采集程序拿到的数据，通常都是批量到达的，很少是一条一条地来——采集线程从设备总线上拉一批、解析一批，攒成一个数据块再往下游送。所以 sfsDb 的写入接口专门为这种模型做了设计，核心思路就是攒批提交，避免每一次写入都触发刷盘事务。下面是一段用 Python SDK 写入的简化示例，我把几个关键参数都写在注释里：

import time import sfsdb db = sfsdb.connect("/opt/edge/data/plc_01.sfsdb") batch = db.batch("device_metrics") now = int(time.time() * 1000) for i in range(5000): batch.add( ts=now - i, # 允许乱序，引擎会自动排序 device_id="d-001", metric="temperature", value=36.5 + i * 0.01, status=0 ) batch.commit()

有三个关键点要敲黑板。第一，必须用批量接口，不要一条一条写。边缘现场的采集频率很高，如果每条数据都触发一次提交，事务和文件同步的开销会占掉大量 CPU。我这里 5000 条一个批次，提交后统一刷盘，实际吞吐比逐条写高了不止一个数量级。

第二，允许乱序写入。我演示的代码里特意用now - i制造了乱序时间戳，sfsDb 会先在内存里排序，再统一落段。这个设计非常实用，因为现场的采集程序经常因为网络重传、设备缓存回放导致数据错序，如果数据库不处理乱序，应用层就要自己做一整套队列排序，那才是真的麻烦。

第三，status 字段我给了 0 值，这是设备状态码。状态码类型建议用 SMALLINT 或更小的整数类型，不要用字符串，占用的列空间和压缩耗时差别很大。字符串状态码写起来方便，但数据量一大，字典编码和压缩的开销都会变成肉眼可见的性能成本。

3.4 查询与聚合：几个高频场景实测

写入这关过了之后，真正决定用户体感的是查询。下面贴几个我在模拟项目里高频执行的查询，都是监控看板、报表导出、告警排查里最常见的形态。时序查询和传统关系查询最大的差异在于，几乎所有操作都围绕时间轴展开，写法的好坏直接影响响应速度，我用代码块呈现的这几种写法，都是验证过可以直接抄的。

最基础的，按时间范围取原始值：

SELECT ts, value FROM device_metrics WHERE device_id = 'd-001' AND metric = 'temperature' AND ts >= '2024-06-01T00:00:00Z' AND ts < '2024-06-01T01:00:00Z' ORDER BY ts;

这个查询会走标签索引定位，再沿时间游标顺序扫描，所以返回结果天然有序，不需要真的做一次排序。我在程序里测试过，把 ORDER BY ts 去掉和保留，耗时几乎没差别，就是因为底层数据段已经按时间有序排列了，执行器可以直接复用这个序。

然后是聚合查询，比如统计一小时内的均值、最大值和样本数，这是设备状态评估最常用的口径。业务上最关心的就是“平均温度是否偏高、峰值是否越限、这一小时有多少有效样本”，对应的 SQL 长这样：

SELECT avg(value) AS avg_temp, max(value) AS max_temp, count(value) AS sample_count FROM device_metrics WHERE device_id = 'd-001' AND metric = 'temperature' AND ts >= '2024-06-01T00:00:00Z' AND ts < '2024-06-01T01:00:00Z';

这一查询里的聚合算子是在数据段扫描过程中原地完成的，不会先把原始记录拉出来再统计。对于数据量上千万的表，这个设计带来的性能差异是决定性的，因为它把扫描和计算合并成了一次线性操作，而不是先全量读取再在内存里做二次计算。

除了一次性聚合，监控看板还需要按时间窗分组的历史曲线，也就是把一天的数据切成等宽窗口，每个窗口算一个聚合值，画出平滑的折线图。对应的写法是：

SELECT ts, avg(value) FROM device_metrics WHERE device_id = 'd-001' AND metric = 'temperature' AND ts >= '2024-06-01T00:00:00Z' AND ts < '2024-06-02T00:00:00Z' GROUP BY time(5m);

GROUP BY time 是时序数据库的标配语法，sfsDb 会把一天的数据按五分钟一个窗口切片，返回 288 行均值结果。这类查询主要用于趋势曲线的绘制，调用端拿到的行数固定，前端渲染压力小。我实际拿近一个月的数据画过温升曲线，首屏加载基本在几百毫秒内完成，体验接近实时查询。

3.5 时区和时间精度：最容易踩的坑

写时序数据的人，十有八九被时区坑过，我自己最开始也没躲过。sfsDb 把时间字段设计成 TIMESTAMPTZ 是有原因的，它要求所有写入和查询都带上时区语义，而不是让数据库默默按系统时区解释。如果你不带时区字符串，它会把时间戳当成 UTC 处理，而现场设备往往跑的是本地时间，这么一错位，查出来的数据就会少一段。这个问题在早期调试时非常隐蔽，因为报错几乎不会出现，最多就是曲线中间缺了一块。

我刚开始测试时，直接把本地时间的字符串塞进查询条件，结果发现数据少了一段。排查了很久才意识到是时区偏移导致的边界错位。后来养成一个习惯：所有写入和查询统一用 UTC 时间戳，展示层再转成本地时间。这样做的理由是，边缘设备的系统时区经常被现场人员改来改去，如果数据库内部保存的是本地时间，一改时区，历史数据全部错乱，那时候想纠正就非常痛苦。

精确度方面，默认毫秒足够覆盖绝大多数边缘场景。如果业务需要微秒级别的时间分辨率，可以在建表时指定更高精度的时间类型，但要注意存储成本会上升。我的建议是先用毫秒，不够再调，别一上来就上高精度。高精度时间戳会让时间列的编码压缩率明显下降，对长期保留的数据来说，存储开销会放大得比想象中快。

4. 云边协同：断网续传 + 增量同步的落地做法

4.1 同步水位线（watermark）的作用

sfsDb 的价值不只是本地存储这一个点，它真正吸引我的，是“本地优先、云边同步”的整套数据通路设计。边缘节点把数据先写进本地库，云端再从本地把数据拉走，这个模型说起来简单，但真正要把断网、续传、去重、权限这些都处理好，复杂度相当高。sfsDb 把这一套做成了内置能力，省掉了我大量的自研工作。

我在项目里的实际做法是：边缘节点只把本地生成的原始数据存进 sfsDb，云端平台需要这些数据做总览分析，所以就产生了一个经典问题：边缘和云之间的网络时好时坏，怎么保证数据最终一致地抵达云端？

sfsDb 的方案是维护一个同步水位线。简单说，水位线就是一个持久化的游标，记录“本地数据已经成功同步到云端的最大时间点”。每次同步任务启动，数据库只从水位线之后的数据开始读取，而不是每次都从头扫描整个库。这个设计的直接价值是：同步过程不依赖云端返回结果的全量核对，也不依赖把整个文件拷贝上传，增量同步的成本和时间窗口都大大缩小。

水位线还有一个隐藏作用：断网的时候，本地写入照常进行，水位线不动；网络恢复后，同步任务从上次断点继续，不会重复同步已经确认过的那部分数据。这比依赖文件时间戳、依赖内存状态的各种自研方案都要可靠得多。

4.2 同步配置的完整示例

sfsDb 的同步配置在边缘节点的配置文件里完成。下面是我在一个模拟网关验证环境里实践过的配置片段：

[source] path = "/opt/edge/data/plc_01.sfsdb" [target] endpoint = "https://cloud.example.com/ingest" access_key = "edge-key-2024" bucket = "factory-plant-a" [sync] interval = "10s" batch_size = 5000 watermark_path = "/opt/edge/data/.sync_watermark" parallel = 4

这段配置的要点有几个。source.path 是 sfsDb 的文件路径；target 配置的是云端接入点的地址和认证信息；sync 段里的 interval 是同步任务的触发频率，batch_size 是每次同步的最大行数，watermark_path 是水位线文件的存储路径。

在实际项目里，interval 我一般建议设置为 10 秒左右。太频繁会让云端接入点压力变大，太慢则导致云端看到的业务数据延迟太高。batch_size 主要取决于单条数据的平均大小，我这边 5000 条一批，单批上传的压缩后体积大概在 2MB 左右，对工业现场的窄带宽网络比较友好。

值得留意的是 parallel 参数。边缘盒子如果有多核处理器，可以并行上传多个批次，大幅提高同步吞吐。但如果你的边缘设备只有单核，或者网络带宽本身很窄，parallel 应该保持默认值 1，否则反而会因为并发争夺带宽导致同步变慢。这个参数我在测试环境里反复试过，最终确定了对当前环境的最优值是 4。

4.3 断网恢复后的行为与幂等处理

据我观察，最多人担心的问题其实是断网恢复后的数据重复。因为自研同步方案的常见问题是：网络超时导致云端已经收到了数据，但边缘侧不知道，于是重传一次，云端就出现重复记录。所以测试云边同步的时候，我习惯把“断网→恢复→对比行数”当作一项必做验收，而不是可选动作。sfsDb 在端侧能做的，是通过幂等键来规避这一层重复。在同步数据写入云端之前，每条记录会附带一个由“分区键 + 时间戳 + 序列号”构成的幂等 ID，云端接入层根据这个 ID 判断某条记录是否已经处理过。这个设计能工作的前提是云端也实现了对应的去重逻辑，如果云端不认这个字段，端侧做得再多也是白搭。

我在项目里实际踩过这个坑：端侧配置没问题，但云端接入服务没有开启幂等模式，断网重启一次后，云端多出了 12 万条重复数据。那次排查花了整整一个晚上，最后从云端接入日志里看到重复的主键才定位到问题，过程相当痛苦。后来在云端补上幂等字段校验，问题彻底消失。因此，在验收边缘同步功能时，一定要设计一次“断网 1 小时 → 恢复网络”的测试用例，对比云端行数和端侧行数是否一致。只有这一步通过了，才能放心把同步功能交给现场。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

下面这张表，是我在实际项目中整理出来的高频问题速查表。每一行背后都对应一个真实场景，不是凭空写的。比如“写入延迟逐渐变高”这一条，我第一次压测时就碰到过，一开始以为 sfsDb 引擎有问题，后来查了一圈才发现是自己的用法不对——我没有用批量接口，每个采样点都单独 commit，每次 commit 都触发一次刷盘，写入吞吐自然上不去。排查过程虽然折腾，但至少让这张表里每一条都有据可依。如果你遇到类似症状，直接按表里的解决办法对照检查，比自己从头试要快得多。

表格里的第三行“磁盘占用增长异常快”也很典型，不少用户在测试阶段数据量小，感觉不到区别，等真正跑满一个月，才发现原始数据的 TTL 根本没人配。这里顺便提醒一句：TTL 是建表时就要想清楚的，不是事后补救能省心的。我在模拟项目里前两周也没配 TTL，后来磁盘占用曲线一路冲高，吓出一身冷汗，赶紧补了多级保留策略才压住。

5.2 几个来自实践的调优参数

参数调优这件事，每个项目环境都不一样，我给的建议谈不上最优解，只是一组可以复现的起点。如果你在一台 2 核 4GB 内存的工控机上跑 sfsDb，下面这几个方向大概率用得上。先说内存缓冲区，这是最容易见效的一项。sfsDb 默认的内存缓冲区大小比较保守，如果你的边缘盒子内存足够，把缓冲调大可以让写入吞吐明显改善。做法是在建库连接时指定对应的内存参数，或者在配置里把缓冲区从默认值调高一倍。我实测里，缓冲区调到 128MB 后，批量写入的峰值吞吐比默认值提升了大约 30%。

其次是压缩级别的权衡。COMPRESSION 我直接用了 auto，它会根据字段类型自动选择编码策略，省心且效果不差。CPU 比较紧张的场景，比如主业务程序占用了大量计算资源，可以把压缩级别调低一档，换回更快的写入速度；反过来，如果磁盘是明显的瓶颈，可以开高级压缩编码，体积还能再压 10%~15%，但 CPU 占用会明显上升。这个权衡没有标准答案，只能按现场资源的瓶颈来定。

还有同步频率与云端批次大小的匹配。建议端侧 interval 与云端 ingest 的批处理窗口对齐。我把 interval 从 5s 改成 10s，云端总的请求数反而降了一半，原因是每个请求携带的数据变多，服务端的批处理效率更高。如果你的云端接入层有批量写入接口，务必把它用起来，否则端侧再优，云端吞吐也会成为短板。

回到开头那个问题：边缘设备的时序数据到底该怎么存？我现在的答案是，别再把它当成一个“存储问题”去解决，而要当成一个“数据生命周期 + 云边协同”的问题去设计。sfsDb 最打动我的不是某个单项性能指标，而是它默认就把这些边缘特化能力做进了存储内核里，嵌入到业务进程里时，我几乎感觉不到它的存在。

最后分享一个小技巧：在正式接入真实产线之前，建议先用一份足够脏的数据做压测——乱序、缺测、时区混乱、单位混乱全上，把能踩的坑都踩一遍。我在模拟项目里就是这么过来的，后面真上现场时，反而轻松很多。sfsDb 这类新生代边缘时序库的成熟度还需要时间检验，但它的方向，我是认的。