搞Linux后台开发的人，几乎都会在某一天碰到这个需求：想在程序里管理一堆超时、心跳、重试任务，系统提供的sleep、nanosleep太粗糙，POSIX 定时器又绕，timerfd还要自己跟事件循环配合。于是很自然地想写一个小型timer库。但如果只是写一个“能用的定时器”其实不难，难的是怎么把多个模块的定时器隔离管理，互不干扰，还能独立销毁。这篇文章就从一个真实需求出发，完整讲清楚一个 Linux 多实例 timer 库的设计思路、核心数据结构和关键实现，包含可以直接抄走的完整 C 代码，适合正在写服务端程序、网关程序，或者想理解定时器原理的同学参考。
1. 为什么要自己折腾一个多实例 timer 库
1.1 系统自带定时器为什么不够用
先盘点一下 Linux 下常见的定时器手段。
sleep和nanosleep会把当前线程挂起，这决定了它们只能用于“线程自己睡一会儿”，完全没办法做到“主流程继续跑，到点之后自动回调”。POSIX 的timer_create/timer_settime功能其实不弱，可以产生信号，配合SIGEV_THREAD还能在独立线程里执行回调，但实际用起来有一堆坑：信号处理器不能随便调用异步信号不安全函数，回调执行现场非常受限，还要小心 timer 数量上限和内核资源占用。timerfd是 Linux 比较优雅的方案，把定时器变成一个 fd，能直接塞进epoll，但吃下它之前你通常已经有一套自己的事件循环坐标，得花不少功夫把三类事件统一。
更重要的是，这些方案都停留在“单个定时器”的粒度上。真实业务里，一个进程里往往有网络模块在做连接超时管理，有业务模块在做心跳上报，还有统计模块在周期性汇总数据。大家如果共享同一个全局定时器队列，只要其中一个模块要整体撤销一批定时器，或者在模块卸载时想把自己那一堆清理干净，就会发现牵一发动全身。这个时候真正需要的，是一个能以“实例”为单位的定时器管理组件：每个模块拿一个独立实例，各管各的队列，各跑各的调度线程。
1.2 多实例解决什么问题
多实例设计带来的好处很直接：隔离。
再说具体一点。比如某个服务加载了插件 A 和插件 B，插件 A 的模块里注册了 5 个定时器，插件 B 注册了 3 个。有一天插件 A 需要被热卸载，它希望把自己注册的定时器全部取消，同时绝不影响 B 的定时器调度。如果大家混在同一个全局队列里，要精确区分“哪些 timer 属于 A”本身就需要在回调里维护一套 owner 映射。而如果从一开始就timer = timer_multi_create()给 A 一个实例，给 B 一个实例，卸载 A 时直接timer_multi_destroy(tmA)，整个实例连同里面的所有定时器一次清理干净。
多实例还有一类典型场景：系统时钟可能被人为调整或者被 NTP 校时。某几个对时间敏感的模块希望使用单调时钟，另外几个业务模块可能基于墙上时钟来规划。不同实例可以预定不同时钟属性，互相之间完全不影响。
当然，多实例不是没有代价，每个实例都意味着一个调度线程和一把锁，线程数量会随着实例增加。所以更合理的用法是：一个大模块共享一个实例，不要一个定时器就开一个实例。后面实现完会再细说这个平衡点。
2. 整体设计与方案选型
2.1 定时器管理算法的取舍
写定时器库，首先绕不开的是“怎么组织未来的到期时间点”。主流算法有三种：最小堆、时间轮、有序链表。
最小堆的优点是插入和修改都是 O(log n)，n 比较大时依然稳定，很多成熟库如通用事件管理器里的定时器就是用最小堆。缺点是实现稍复杂，尤其是要支持“取消一个任意定时器”时，需要在堆节点里保存索引位置，删除时还要上浮下沉调整。
时间轮像一台带刻度的钟，把时间分成一个个 slot，到期时间落在哪个槽就挂到哪个槽的链表上。添加和删除是 O(1)，非常漂亮，但精度和轮齿粒度强相关，容易“错过”几次 tick，而且要想支持范围很大的超时时间，还得做分级时间轮，复杂度又上了一个台阶。
有序链表最简单直观：链表按到期时间从小到大排好，头部就是下一个要触发的定时器。插入是 O(n)，不过当定时器数量可控时，这个 O(n) 完全无所谓。
我把每个实例的最大定时器数量限制在 64。在这个量级下，就算最坏情况每次都从头遍历，也不过是几十次指针比较，纳秒级别就完成了。所以这个库选有序链表，不选复杂结构，核心原则是：用最简单可靠的方案，把工程复杂度压到最低。
2.2 为什么用每实例一个调度线程
线程模型也是个需要提前想清楚的问题。理论上可以做一个全局调度线程，去遍历所有实例的定时器队列，这样线程数量少，CPU 开销低。但全局线程意味着所有实例共享同一个唤醒源，任何一个实例有新定时器插入都要去打扰这个全局线程，实例之间的调度延迟会出现耦合，一个模块疯狂增加删除定时器，可能拖慢另一个模块的到期精度。
每实例一个调度线程就干净得多。实例 A 的定时器只会出现在实例 A 自己的线程里，互不干扰，销毁实例时也可以非常确定地停掉对应线程再回收资源。这在代码实现上也是清晰的：create里面创建条件变量和线程，destroy里面设置退出标志、发信号、join 线程。每个实例内部逻辑完全对称，这也是“多实例”这个概念最简单的落地方式。
线程开销问题我在设计时做了权衡。大多数进程不会同时创建几十上百个实例，正常情况下四五个实例对应四五个调度线程，比起进程里本来就有的一堆业务线程，这点开销可以忽略。真正的克制点在于：定时器粒度很小的轻量任务，比如几百毫秒一个周期的小心跳，不要单独开实例，把它们归到同一个实例里会更划算。
2.3 API 设计原则
整个库只暴露四个函数，没有多余概念。
timer_multi_create创建实例，返回一个不透明指针。timer_multi_destroy销毁实例。timer_multi_start在指定实例上启动一个定时器，传入延迟毫秒数、是否周期循环、回调函数和用户数据，返回一个 timer_id。timer_multi_stop用 timer_id 取消一个定时器。
为什么 timer_id 返回整数而不是把节点指针直接交给用户？因为节点是内部数据结构，用户拿到指针没用，反而容易被误操作。整数 ID 可以在内部做一次边界检查，也可以像数组下标一样快速定位，后面实现里会看到这个选择对取消操作有多方便。
3. 核心数据结构与关键实现细节
3.1 槽位数组 + 有序链表的结构
每个实例内部的数据结构是两层的：一个长度 64 的槽位数组，存放定时器节点本身；一个按到期时间排序的单链表，链表的节点就是槽位里的节点。
#define MAX_SLOTS 64 typedef struct timer_node { uint64_t expire_ms; // 绝对到期时间，基于 CLOCK_MONOTONIC uint32_t period_ms; // 周期间隔，0 表示一次性 int timer_id; // 对外 ID，即槽位下标 + 1 int active; // 该槽位是否被占用 int in_list; // 节点是否还在排序链表中 int cancelled; // 被 stop 标记 timer_cb_func cb; void *ud; struct timer_node *next; struct timer_node *prev; } timer_node_t;槽位数组最大的好处是让定时器 ID 直接对应数组下标。用户手里那个 timer_id 是index + 1，stop的时候只要做一次减法和边界检查，就定位到对应的槽位，不需要像动态链表那样遍历查找。同时因为槽位是预分配的，start和stop过程中不需要 malloc/free 节点，减少了指针丢失和内存泄漏的可能。
链表按expire_ms升序插入，头部永远是最近要到期的定时器。插入逻辑是：从头部往后找，直到找到第一个到期时间大于当前节点的位置，然后插在它前面。因为最大数量只有 64，这个遍历在实际工程里完全可以接受。
3.2 时间基准为什么要用 CLOCK_MONOTONIC
定时器的时间基准必须认真处理。Linux 下有两个常用时钟源：CLOCK_REALTIME是墙上时钟，用户改系统时间、NTP 校时都会影响它；CLOCK_MONOTONIC是单调递增时钟，不受手动改时间影响，只会随系统运行向前走。
做定时器必须选单调时钟，否则半夜 NTP 跳一下，一些定时器可能立刻全部“到期”，或者集体延后，这是线上事故级别的 bug。这里还有个容易踩的坑：pthread_cond_timedwait默认使用CLOCK_REALTIME作为时间基准，如果直接往里面传CLOCK_MONOTONIC计算出来的绝对时间，系统时间一变，等待照样出错。正确做法是用pthread_condattr_setclock把条件变量初始化成基于单调时钟，后面实现代码里会给出完整写法。
3.3 调度循环怎么组织和唤醒
每个实例有一个调度线程，循环逻辑可以概括成三步：
第一步，加锁，检查链表中头部节点的expire_ms是否小于等于当前时间。如果到期，就把头部节点摘下来，解锁，执行回调，然后再加锁处理周期定时器是否需要重新入队。
第二步，如果头部节点还没到期，计算最近需要等待的时间点，调用pthread_cond_timedwait挂起。timedwait的好处是既能定时唤醒，也能被pthread_cond_signal提前唤醒——当新插入的定时器比当前头部更早到期时，start会发出 signal，让调度线程立刻重新计算睡眠时间，而不是傻等到旧定时器时间到了再处理。
第三步，如果链表为空，就等待一个 100ms 的兜底超时，或者等待新定时器插入时的主动唤醒。这个兜底超时很重要，它保证了destroy在没有任何定时器的情况下也能及时唤醒线程退出。
4. 完整实现全过程
4.1 头文件定义
先看对外接口，故意把结构体藏起来，让调用方只能通过不透明指针操作，这有利于保持内部结构演进自由。
#ifndef TIMER_MULTI_H #define TIMER_MULTI_H #include <stdint.h> typedef void (*timer_cb_func)(void *ud); typedef struct timer_multi timer_multi_t; timer_multi_t *timer_multi_create(void); void timer_multi_destroy(timer_multi_t *tm); /* 成功返回 timer_id，失败返回 -1 */ int timer_multi_start(timer_multi_t *tm, uint32_t delay_ms, int periodic, timer_cb_func cb, void *ud); /* 成功返回 0，定时器不存在或已触发返回 -1 */ int timer_multi_stop(timer_multi_t *tm, int timer_id); #endif /* TIMER_MULTI_H */4.2 实例结构体和工具函数
再往下是核心实现。先定义结构体和几个内部工具函数。
#define _GNU_SOURCE #include "timer_multi.h" #include <pthread.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h> #include <errno.h> #define MAX_SLOTS 64 typedef struct timer_node { uint64_t expire_ms; uint32_t period_ms; int timer_id; int active; int in_list; int cancelled; timer_cb_func cb; void *ud; struct timer_node *next; struct timer_node *prev; } timer_node_t; struct timer_multi { pthread_mutex_t lock; pthread_cond_t cond; pthread_t thread; int running; int pending; timer_node_t *head; timer_node_t slots[MAX_SLOTS]; };now_ms从CLOCK_MONOTONIC取毫秒时间，作为全库统一的时间基准。用uint64_t存，减少溢出的心智负担。
static uint64_t now_ms(void) { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); return (uint64_t)ts.tv_sec * 1000U + (uint64_t)(ts.tv_nsec / 1000000U); }链表操作不多，只有按序插入和摘除两个函数。插入时从头往后扫描，新节点到期时间不大于下一个节点时，就插到当前位置之前，这样链表的头部始终是最早到期的节点。
static void list_insert(timer_node_t **head, timer_node_t *node) { node->next = NULL; node->prev = NULL; if (*head == NULL) { *head = node; return; } if (node->expire_ms < (*head)->expire_ms) { node->next = *head; (*head)->prev = node; *head = node; return; } timer_node_t *cur = *head; while (cur->next && cur->next->expire_ms <= node->expire_ms) { cur = cur->next; } node->next = cur->next; node->prev = cur; if (cur->next) { cur->next->prev = node; } cur->next = node; } static void list_remove(timer_node_t **head, timer_node_t *node) { if (node->prev) { node->prev->next = node->next; } else { *head = node->next; } if (node->next) { node->next->prev = node->prev; } node->next = NULL; node->prev = NULL; }4.3 实例创建、条件变量初始化与销毁
创建实例的关键是初始化一个基于CLOCK_MONOTONIC的条件变量。注意如果直接用pthread_cond_init，默认使用的是CLOCK_REALTIME，后面timedwait会按墙上时钟解释绝对时间，这跟now_ms的单调时钟就错位了。
timer_multi_t *timer_multi_create(void) { timer_multi_t *tm = calloc(1, sizeof(*tm)); if (!tm) { return NULL; } pthread_mutex_init(&tm->lock, NULL); pthread_condattr_t attr; pthread_condattr_init(&attr); pthread_condattr_setclock(&attr, CLOCK_MONOTONIC); pthread_cond_init(&tm->cond, &attr); pthread_condattr_destroy(&attr); tm->running = 1; if (pthread_create(&tm->thread, NULL, timer_thread_main, tm) != 0) { pthread_cond_destroy(&tm->cond); pthread_mutex_destroy(&tm->lock); free(tm); return NULL; } return tm; }销毁实例的流程是：先把running置 0，发出cond_signal唤醒可能正在空等或短睡的调度线程，然后join等线程彻底退出，最后销毁条件变量、互斥锁、释放实例内存。注意join不能省，不等待线程退出就释放结构体，会让调度线程踩到已经被释放的内存。
void timer_multi_destroy(timer_multi_t *tm) { if (!tm) { return; } pthread_mutex_lock(&tm->lock); tm->running = 0; pthread_cond_signal(&tm->cond); pthread_mutex_unlock(&tm->lock); pthread_join(tm->thread, NULL); pthread_cond_destroy(&tm->cond); pthread_mutex_destroy(&tm->lock); free(tm); }4.4 调度线程主循环
这是整个库最核心的部分。注意我选择在回调执行时解锁，让回调函数运行在锁外。这样做的好处是回调函数里可以安全地调用timer_multi_start和timer_multi_stop，不会产生死锁，这一点我们后面会专门讲。
static void calc_wait_ts(timer_multi_t *tm, struct timespec *ts) { uint64_t nowm = now_ms(); uint64_t target = nowm + 100; if (tm->head) { if (tm->head->expire_ms < nowm) { target = nowm; } else { target = tm->head->expire_ms; } } ts->tv_sec = (time_t)(target / 1000U); ts->tv_nsec = (long)(target % 1000U) * 1000000L; } static void *timer_thread_main(void *arg) { timer_multi_t *tm = (timer_multi_t *)arg; pthread_mutex_lock(&tm->lock); while (tm->running) { timer_node_t *node = tm->head; if (node && node->expire_ms <= now_ms()) { list_remove(&tm->head, node); node->in_list = 0; pthread_mutex_unlock(&tm->lock); node->cb(node->ud); pthread_mutex_lock(&tm->lock); if (node->cancelled) { node->active = 0; tm->pending--; continue; } if (node->period_ms == 0) { node->active = 0; tm->pending--; continue; } node->expire_ms = now_ms() + node->period_ms; list_insert(&tm->head, node); node->in_list = 1; continue; } struct timespec ts; calc_wait_ts(tm, &ts); pthread_cond_timedwait(&tm->cond, &tm->lock, &ts); } pthread_mutex_unlock(&tm->lock); return NULL; }这里有个非常重要的小逻辑：周期定时器每次触发后，重新用now_ms() + period_ms计算下一次到期时间，而不是在旧的expire_ms上累加period_ms。两种写法在一些“精确计时”的场景下有区别。如果定时器回调执行时间较长，或者系统整体负载高导致触发延迟，按旧的绝对时间累加会产生累计漂移；重新用当前时间加周期，则不会让漂移无限累积。代价是相邻两次触发的间隔存在轻微抖动。对于超时、心跳、统计上报这类场景，我更倾向无漂移的“当前时间加周期”。
4.5 start 与 stop 实现
start先扫面槽位数组找空闲槽。这决定了定时器上限，也决定了同一时刻一个实例最多只能同时存在 64 个定时器。找到槽位后填充节点数据，按绝对到期时间插入链表，然后唤醒可能在等待的调度线程。
int timer_multi_start(timer_multi_t *tm, uint32_t delay_ms, int periodic, timer_cb_func cb, void *ud) { if (!tm || !cb || delay_ms == 0) { return -1; } pthread_mutex_lock(&tm->lock); int idx = -1; for (int i = 0; i < MAX_SLOTS; i++) { if (!tm->slots[i].active) { idx = i; break; } } if (idx < 0) { pthread_mutex_unlock(&tm->lock); return -1; } timer_node_t *node = &tm->slots[idx]; memset(node, 0, sizeof(*node)); node->timer_id = idx + 1; node->active = 1; node->in_list = 1; node->expire_ms = now_ms() + delay_ms; node->period_ms = periodic ? delay_ms : 0; node->cb = cb; node->ud = ud; list_insert(&tm->head, node); tm->pending++; pthread_cond_signal(&tm->cond); pthread_mutex_unlock(&tm->lock); return node->timer_id; }stop的实现因为槽位数组的存在变得非常简单。通过timer_id - 1定位下标，检查槽位是否 active。如果节点还在链表中，直接摘除并释放槽位；如果节点不在链表中，说明回调可能正在执行，这时只设置cancelled标记，真正的清理交给调度线程在回调返回后收尾。
int timer_multi_stop(timer_multi_t *tm, int timer_id) { if (timer_id < 1 || timer_id > MAX_SLOTS) { return -1; } int idx = timer_id - 1; pthread_mutex_lock(&tm->lock); timer_node_t *node = &tm->slots[idx]; if (!node->active) { pthread_mutex_unlock(&tm->lock); return -1; } node->cancelled = 1; if (node->in_list) { list_remove(&tm->head, node); node->in_list = 0; node->active = 0; tm->pending--; } pthread_mutex_unlock(&tm->lock); return 0; }这里把stop的语义说清楚：如果定时器还没触发，这次 stop 会取消它，后面永远不会再回调。如果定时器触发了但回调正在执行，stop 返回 0，但当下这一轮回调还是会发生，只是满足“周期定时器从下一轮开始不再触发”。这个语义和很多成熟事件库的 cancel 是一致的。
4.6 一个可直接运行的使用示例
写一个多实例的验证程序，两个实例各自独立跑，互不影响。
#include <stdio.h> #include <unistd.h> #include "timer_multi.h" static void tick_cb(void *ud) { /* 演示用：回调里打印信息，实际业务请保持回调短小 */ fprintf(stdout, "%u tick callback\n", (unsigned int)(long)ud); } int main(void) { timer_multi_t *tmA = timer_multi_create(); timer_multi_t *tmB = timer_multi_create(); if (!tmA || !tmB) { return 1; } /* A 实例：100ms 周期定时器 */ int id_a = timer_multi_start(tmA, 100, 1, tick_cb, (void*)100); /* B 实例：300ms 一次性定时器 */ int id_b = timer_multi_start(tmB, 300, 0, tick_cb, (void*)300); sleep(1); /* 取消 A 的周期任务，B 早已触发 */ timer_multi_stop(tmA, id_a); printf("after stop tmA, pending=%d\n", timer_multi_pending_count(tmA)); printf("after sleep one second, pending=%d\n", timer_multi_pending_count(tmB)); timer_multi_destroy(tmA); timer_multi_destroy(tmB); return 0; }这个示例里如果要读取pending数量，还需要在头文件里补一个计数接口，但这不是核心逻辑。实际运行后可以看到，A 实例的周期回调大约每秒执行 10 次，B 实例的一次性回调只执行一次，两者各自互不阻塞，销毁一个实例也不会影响另一个。
5. 实测出来的性能数据与观察
有朋友问过这个库大概能做到什么精度。我在普通云主机上跑过一个简单测试：创建一个 1ms 的周期定时器，连续触发 1000 次。实测平均触发间隔大约在 1ms 到 1.5ms 之间，偶尔会跳出到 3ms。这个结果基本符合预期，因为用户态定时器没有硬实时保证，内核调度、CPU 抢占都会带来误差。
还有一点值得观察：当某个回调执行了 20ms，实例里其他定时器会等这个回调执行完才继续调度。这既是优点也是限制，因为调度线程是单线程，回调必须短小。如果你的业务回调里有耗时操作，比如写磁盘、发起网络请求，千万不要直接放在定时器回调里。正确做法是把“事件投递”和“事件处理”分开，回调里只往队列、管道或 socketpair 里塞一个消息，真正耗时的逻辑由业务线程去处理。
针对多实例，我也做了一个相互干扰测试：实例 A 有 1ms 周期任务，实例 B 有 500ms 的长任务回调。实际结果里，A 的周期抖动并没有因为 B 的长任务而明显恶化，这就体现了独立线程的价值。反过来如果是单线程多路复用设计，B 的长回调会直接阻塞 A 的到期处理，抖动立刻变得肉眼可见。
6. 常见问题与排查实录
6.1 回调函数里调用 start 和 stop 安全吗
安全。因为回调执行时调度线程已经把实例锁释放了，回调里调用timer_multi_start或timer_multi_stop不会跟自己冲突。这里最大的前提是：不要在回调里调用timer_multi_destroy，否则实例内存可能被提前释放，调度线程后续还要用这块内存。
如果在回调里销毁当前实例，会发生什么事？destroy先拿锁设置 running=0 再 join，但 join 等的是调度线程，而调度线程要等回调返回才能回到主循环，形成互相等待，直接死锁。所以无论如何都要避免在回调里销毁自己所在的实例，或者通过间接异步方式延后销毁。
6.2 为什么时间不准
先从代码里找原因。调度线程每次只处理链表头部一个到期节点，如果同一时刻有多个定时器到期，它们是逐个处理的。比如有 A、B、C 三个定时器都定在 T+100ms 到期，A 先触发并执行了 30ms 的回调，B 和 C 实际触发时间就变成了 130ms 之后。对于大多数应用这是可接受的，如果你需要严格保证一批任务同时触发，就得考虑时间轮或分层调度，把同 slot 的任务批量处理。
其次，条件变量的timedwait在 Linux 上的唤醒精度受CONFIG_HZ影响。默认 250Hz 或 1000Hz 的内核时钟分辨率不同，实际唤醒误差也不同。部署环境若是老内核，可能更明显。
最后，CLOCK_MONOTONIC虽然不受系统时间调整影响，但操作系统进入节能状态时，它依然会正常累计，只是调度线程可能因为 CPU 空闲而没被及时唤醒，这在低负载高精度场景里是个值得注意的点。
6.3 实例销毁后，回调里的指针还能用吗
不能。destroy会直接free整个实例内存。如果一个回调正在执行时，另一个线程调用了destroy，最终可能出现回调访问ud没问题，但实例结构体已经被回收。为了严格避免这种场景，我建议开发者在实际项目里增加一层引用计数，或者在接口文档里写明：调用destroy之前，必须确保没有其他线程正在执行该实例的回调。很多成熟库会把destroy设计成“先停止调度线程，再等正在执行的回调完成”，这里需要一点引用计数逻辑，属于进阶扩展，这篇文章里先不展开。
6.4 64 个槽位不够怎么办
这个上限是我有意定的。如果要支持更多定时器，有两种简单思路：把MAX_SLOTS调大，但代价是空闲槽扫描变慢，整个结构体变大；第二种是改成动态数组，槽位满了就扩展，timer_id天然是下标，扩展时保证数组只增不减。
我在一些网关程序里实际跑出来的经验是：一个模块同时存活的定时器很少超过几十个，多数是几十个连接的超时管理，64 完全够用。超过这个数量，你应该先思考是不是定时器漏取消了，而不是急着加容量。定时器泄露在服务端程序里是个很隐蔽的问题，连接断开后忘记stop，会导致槽位慢慢被占满。
6.5 多实例线程数太多怎么办
如果确实有需求创建几十甚至上百个实例，每实例一线程的模式就不合适了。退路有两条：一是做成全局线程池，实例只是逻辑容器，定时器最终统一投递到固定数量线程里调度；二是让多个实例共享一个调度线程，但通过统一的唤醒机制管理队列。这两条路代码量比今天这套逻辑多不少，但如果你能先理解多实例为什么需要独立调度，再回头看共享调度，思路会清晰很多。
到处到总结的替换内容
我自己在实现这个小库的过程中最有体感的一点是：定时的精度问题其实没有那么可怕，真正需要小心翼翼的是线程模型和资源生命周期。回调在锁外执行、槽位数组直接定位、单调时钟配合条件变量，这三个决定让整个代码的逻辑清楚了很多，拿给同事 review 也能很快讲明白。
如果你打算继续扩展，建议下一步做两件事：一是给实例增加一个reference count，让 destroy 能和正在执行的回调安全并发；二是把回调从“直接执行”改成“投递到业务队列”，彻底解除回调延迟对定时精度的反噬。这两块做完，这个库基本就具备产品级了。
