DSA不是刷题：面向工程约束的数据结构建模系统

1. 这不是又一篇“刷题指南”——它直击DSA学习中被集体忽视的底层认知断层

“Everyone’s Doing DSA Wrong. Here’s the System That Actually Works.”——这个标题刚在技术社区刷屏时，我正带第三期算法集训营的学员做二叉树序列化实战。有位在大厂做了五年后端的学员举手说：“老师，我LeetCode刷了482道，Medium通过率91%，但上周系统设计面试被问‘如何用最小空间代价支持千万级用户实时好友关系图谱查询’，当场卡死。”他没说错，他刷的不是数据结构与算法，他刷的是带标准答案的数学谜题变体。DSA（Data Structures & Algorithms）从来就不是一道道孤立题目的集合，而是一套面向真实工程约束的问题建模语言。你背熟红黑树的旋转规则，却不知道为什么Redis用跳表不用AVL；你默写出快排三路划分代码，却无法判断在日志去重场景中该选布隆过滤器还是Trie树；你能在白板上手写LRU，却在优化一个慢SQL时想不到用前缀和预计算替代嵌套循环——这些不是“不熟练”，而是学习路径从根上就偏离了问题域。本文要拆解的，正是这套被90%自学/培训者忽略的“系统”：它不教你怎么“过题”，而是教你如何把模糊的业务需求翻译成可量化的时空约束，再把约束映射到数据结构的拓扑特性与算法的渐进行为上。核心关键词——问题建模、约束翻译、结构匹配、渐进验证——它们才是DSA真正的工作界面。适合谁？所有在“刷题→面试→上岗→再迷茫”循环里疲惫的人；所有简历写着“精通哈希表”，却在Code Review时看不懂同事为何把HashMap换成ConcurrentHashMap的人；所有想把算法能力从“解题工具”升级为“系统设计直觉”的工程师。这不是速成课，它是帮你把散落的算法碎片，锻造成一把能切开复杂问题的瑞士军刀。

2. 为什么90%的DSA学习是无效的？——从三类典型失败模式看认知偏差

2.1 模式一：题目驱动型学习——把DSA当“解题题库”来背

这是最普遍也最危险的路径。典型操作是：打开LeetCode，按“Top 100 Liked”列表逐个攻克，每道题记下最优解法，整理成“高频模板”笔记，反复默写。表面看效率极高——三个月刷300题，周赛稳定Rank 500。但问题出在知识封装方式上。人脑对抽象概念的记忆依赖于情境锚点，而刷题模板强行剥离了所有上下文：你记住了“滑动窗口用双指针”，但没建立“当问题出现‘连续子数组’+‘满足某条件’+‘求最值’三要素时，窗口大小可变性与单调性如何影响指针移动策略”的触发条件链；你背下了“DFS回溯要剪枝”，却没内化“剪枝的本质是提前终止对无效解空间的遍历，其有效性取决于约束条件能否在递归深度d处快速排除整个d+1子树”。我曾让一位刷题700+的学员现场分析一个电商库存扣减场景：高并发下需保证“同一商品ID的扣减请求串行化，不同商品ID完全并行”。他脱口而出“用synchronized锁商品ID”，却无法解释为何Redis分布式锁比数据库行锁更合适，更答不出“如果锁粒度细化到SKU级别，QPS提升的理论上限由什么决定”。这暴露了本质缺陷：题目驱动的学习只训练了“解法复现”，未构建“问题识别”与“方案生成”的双向映射。就像学游泳只练蹬壁出发动作，却从不下水感受水流阻力——你永远不知道何时该换气、何时该调整划频。

2.2 模式二：理论驱动型学习——把DSA当“数学证明课”来啃

另一极端是沉迷《算法导论》的证明细节：花两周推导主定理的三种情况，用ε-δ语言严格证明堆排序的O(n log n)时间复杂度，甚至手算斐波那契数列的矩阵快速幂特征值。这种学习看似扎实，实则陷入精度幻觉。真实工程中，你永远不会因为“没严格证明分治算法的递归树高度”而写不出归并排序；但你会因“没理解归并排序的稳定性和外部排序适配性”，在处理TB级日志合并时错误选择快排导致结果乱序。更关键的是，算法的工程价值不在于其理论极限，而在于其在现实约束下的鲁棒性。比如B+树在数据库中的统治地位，与其说是“O(log n)查找”有多美，不如说是它完美匹配了磁盘I/O的物理特性：节点大小固定为页大小（如4KB），非叶节点只存键值不存数据，极大减少树高；叶节点用链表连接，支持高效范围扫描。这些设计决策背后是硬件成本、访问延迟、缓存局部性等硬约束，而非纯数学推导。我见过太多学员能流畅推导KMP的next数组构造，却在实现一个URL去重服务时，面对亿级URL存储，盲目选择HashSet导致内存爆满，而没想过用布隆过滤器+磁盘倒排索引的混合方案——因为他们的知识图谱里，只有“算法正确性”，没有“资源消耗曲线”。

2.3 模式三：工具驱动型学习——把DSA当“API调用手册”来查

这类学习者信奉“不要重复造轮子”，认为掌握Java Collections或Python标准库的API用法就等于掌握了DSA。他们能熟练写出Collections.sort(list, Comparator.comparing(User::getAge))，却说不清Arrays.sort()对对象数组使用的是TimSort（一种针对部分有序数据优化的混合稳定排序），更不会思考：当用户年龄分布极不均匀（如90%用户年龄在18-25岁）时，TimSort的性能优势是否依然成立？这种学习模式的最大风险是丧失对底层机制的感知力。当你调用ConcurrentHashMap.computeIfAbsent(key, factory)时，如果factory函数执行耗时较长（如远程HTTP调用），你是否意识到这会阻塞整个Segment（旧版）或特定桶（新版）的写入？是否知道此时应改用compute()配合异步回调？工具封装的便利性，是以隐藏复杂性为代价的。就像开车只记住“踩油门加速、踩刹车减速”，却不了解变速箱档位逻辑和轮胎抓地力极限——遇到湿滑路面急转弯，必然失控。DSA的真正力量，恰恰在于你理解工具为何这样设计，从而能在工具失效时亲手锻造新工具。当标准库的PriorityQueue无法满足“动态调整任务优先级且支持O(1)查询最高优先级”的需求时，你得知道如何用配对堆（Pairing Heap）或斐波那契堆来重构。

提示：以上三类模式并非互斥，多数人是混合体。但它们共享一个致命盲区——将DSA视为静态知识，而非动态建模过程。真正的DSA能力，是在看到“需要支持10万QPS的实时弹幕计数”时，大脑自动启动：

1. 问题建模：弹幕计数本质是“高并发写+低延迟读”的键值统计；
2. 约束翻译：10万QPS写入要求吞吐量，毫秒级响应要求读取延迟，内存有限要求空间效率；
3. 结构匹配：Hash表提供O(1)平均读写，但需解决并发冲突——选CAS自旋锁还是分段锁？若用分段锁，段数设为CPU核数的2倍是否最优？
4. 渐进验证：先用单线程测试吞吐，再用JMeter压测并发，最后用Arthas观测GC停顿——每一步都在用真实数据校准模型。
   这个闭环，才是DSA的“系统”。

3. 真正有效的DSA系统：四步建模工作流与落地实践

3.1 第一步：问题建模——用“三要素画布”剥离业务噪声

所有有效DSA解决方案的起点，不是代码，而是一张手绘的三要素画布。它强制你用三个维度描述问题，彻底摆脱“我要用XX算法”的思维惯性：

这张画布的价值，在于它把模糊的“秒杀难”转化为可计算的工程参数。比如“库存扣减”操作，在画布中被分解为：高并发写入（输入形态） + 强一致更新（操作类型） + 50ms延迟（约束边界）。此时，任何脱离这三个参数的讨论（如“Redis原子操作多快”）都是无效的。我坚持让所有学员在动手写代码前，必须完成这张画布。曾有个学员画完后自己发现：商品库存更新频率极低，但查询量巨大，且允许短暂不一致（用户看到“余量1”但实际已售罄，只要下单时校验成功即可）。这直接让他放弃复杂的分布式锁方案，转而采用“本地缓存+Redis缓存+DB兜底”的三级架构，并将一致性校验下沉到DB层——方案复杂度降低60%，性能反而提升。

3.2 第二步：约束翻译——将SLA指标转化为可测量的算法指标

画布填好后，进入最关键的约束翻译环节。它像一道精密的转换器，把业务语言（如“不能超卖”）翻译成算法语言（如“必须保证CAS操作的ABA问题不导致库存负数”）。这里有两个核心转换：

第一，延迟约束 → 时间复杂度阶数 + 常数因子
P99延迟≤50ms不是一句空话。以Java为例，假设单次内存访问约10ns，一次L1缓存命中约1ns，一次磁盘随机IO约10ms。那么50ms内最多允许5000次内存访问，或5次磁盘IO。这意味着：

• 若用B+树索引（树高3），每次查询约3次IO，符合要求；
• 若用全表扫描（O(n)），100万行需100万次内存访问，远超5000次，直接淘汰；
• 若用哈希表（O(1)平均），但哈希冲突严重导致链表过长，常数因子飙升，同样可能超时。

我让学员做过一个实验：用HashMap和TreeMap分别存储100万个订单ID（String），执行10万次随机查询。HashMap平均耗时0.8ms，TreeMap为1.2ms——看似差距不大。但当开启JVM GC压力（模拟生产环境），HashMap因扩容触发rehash，P99延迟跳至15ms，而TreeMap因结构稳定，P99仅升至2.1ms。这说明：理论阶数相同，常数因子和稳定性才是工程分水岭。

第二，资源约束 → 空间复杂度 + 内存布局效率
“内存≤1GB”需精确计算。例如实现一个用户行为埋点分析系统，需统计每个用户的点击流。若用Map<UserId, List<ClickEvent>>，每个List对象头24字节，ArrayList内部数组默认容量10，每个ClickEvent对象含时间戳、页面ID等字段约64字节。100万用户，平均每人10次点击，总内存 = 100万 × (24 + 10×64) ≈ 664MB。但若改用IntObjectHashMap（Kryo序列化优化），对象头压缩，数组紧凑存储，内存可降至210MB。更进一步，若用Roaring Bitmap编码用户ID与事件类型的交叉关系，内存可压至45MB——这就是数据结构选择对空间效率的指数级影响。我在某风控系统中，将原始的HashSet<String>（存设备指纹）替换为Cuckoo Filter，内存占用从3.2GB降至800MB，且误判率可控在0.01%，直接省下两台高配服务器。

3.3 第三步：结构匹配——基于拓扑特性的精准选型框架

当约束明确后，“选什么数据结构”不再是经验主义猜测，而是基于拓扑特性匹配的严谨决策。我总结了一个四维匹配框架，覆盖95%工程场景：

这个框架的威力，在于它把主观判断转化为客观检查。例如处理“实时反作弊IP黑名单”：

• 访问模式：单点查询（拦截请求时查IP是否在黑名单）；
• 更新频率：中频（运营人员每小时批量导入新IP段）；
• 一致性要求：弱（允许1分钟内延迟，误拦少量正常IP可接受）；
• 扩展性需求：需分片（黑名单IP超亿级）。
  匹配结果：分段布隆过滤器（Partitioned Bloom Filter）。它将IP哈希后分到N个独立布隆过滤器，每个过滤器负责一部分IP空间，既支持分片扩展，又通过分段降低单个过滤器误判率。我们在线上实测，1亿IP占用内存1.2GB，P99查询延迟0.03ms，完全满足SLA。

3.4 第四步：渐进验证——用生产级数据校准模型的五阶压测法

再完美的模型，未经真实数据验证都是空中楼阁。我设计了一套五阶压测法，确保DSA方案在上线前暴露所有潜在缺陷：

第一阶：单线程基准测试（Baseline）
目标：建立性能基线，排除代码级低级错误。
操作：用JMH（Java Microbenchmark Harness）测试核心操作（如库存扣减）的吞吐量（ops/s）和延迟（ns/op）。
关键指标：Score Error（标准差）应<5%，否则代码存在不稳定因素（如未预热、GC干扰）。
教训：曾有学员代码中new Object()在循环内创建，JMH显示吞吐量波动达40%，定位后改为对象池复用，性能提升3倍。

第二阶：并发压力测试（Concurrency）
目标：验证并发控制机制的有效性。
操作：用JMeter模拟1000线程，持续发送扣减请求，监控成功率、P99延迟、线程阻塞率。
关键指标：成功率100%，P99延迟≤50ms，线程阻塞率<1%。
陷阱：很多方案在低并发下表现完美，但线程数超过CPU核数2倍后，因锁竞争加剧，延迟呈指数上升。此时需用jstack分析线程栈，确认是否发生“锁护送”（Lock convoy）。

第三阶：长稳测试（Longevity）
目标：暴露内存泄漏与GC压力。
操作：持续压测24小时，监控JVM堆内存、GC次数与耗时、Full GC频率。
关键指标：堆内存使用率稳定在60%-75%，Young GC间隔≥10s，Full GC次数=0。
案例：某用LinkedBlockingQueue做消息缓冲的方案，长稳测试中发现Old Gen持续增长，最终OOM。根源是队列中对象引用了大字节数组，且消费速度慢于生产速度。解决方案：改用SynchronousQueue（无缓冲）+ 异步批处理。

第四阶：故障注入测试（Chaos）
目标：检验方案在异常下的韧性。
操作：用Chaos Mesh随机Kill Pod、注入网络延迟（>200ms）、模拟磁盘IO Hang。
关键指标：服务降级策略生效（如自动切换备用缓存），核心接口P99延迟增幅<300%，无数据丢失。
心得：真正的高可用不在于“永不故障”，而在于“故障时优雅退化”。我们给库存服务加了熔断器，当Redis超时率>50%时，自动降级到本地Caffeine缓存（TTL 10s），虽有短暂不一致，但保障了核心交易链路。

第五阶：线上灰度验证（Canary）
目标：用真实流量验证最终效果。
操作：将新方案部署到5%流量的灰度集群，对比老方案的延迟、错误率、资源消耗。
关键指标：新方案P99延迟降低≥20%，CPU使用率降低≥15%，错误率持平。
注意：灰度期间必须开启全链路追踪（如SkyWalking），精准定位慢调用环节。曾发现新方案在某个特定商品ID下延迟突增，追查发现是哈希冲突导致链表过长，最终通过调整哈希函数解决。

注意：这五阶不是线性流程，而是螺旋迭代。第二阶发现问题，需回到第三步“结构匹配”重新选型；第四阶故障注入暴露弱点，要修正第一步“问题建模”中遗漏的约束。真正的系统，是活的闭环。

4. 实操案例：从零构建一个支持百万QPS的实时热搜榜

4.1 问题建模：热搜榜的“三要素画布”实录

让我们用前述系统，完整走一遍“实时热搜榜”的构建。这是典型的高并发、低延迟、强时效性场景，也是检验DSA系统能力的试金石。

输入形态：

• 数据源：用户搜索日志（JSON格式），含search_term（字符串）、timestamp（毫秒级）、user_id（64位整数）；
• 规模：峰值QPS 80万（大促期间），日均日志量120亿条；
• 更新频率：实时流式写入，无历史数据回溯需求；
• 结构特征：search_term长度1-50字符，中文为主，存在大量重复（如“iPhone15”出现频次占TOP100的30%）。

操作类型：

• 核心操作：热搜词计数（写）、TOP-K查询（读）、热度衰减（定时更新）；
• 操作比例：写:读 ≈ 100:1（每100次搜索产生1次榜单查询）；
• 一致性要求：最终一致（允许10秒内延迟，用户看到的榜单不必绝对实时）。

约束边界：

• SLA：TOP-100榜单P99延迟≤200ms；
• 资源：单机内存≤4GB，CPU≤8核；
• 扩展性：需支持QPS从10万平滑扩展至200万；
• 业务规则：热度=搜索频次 × 权重（新词权重高，老词随时间衰减）。

这张画布瞬间排除了多个常见方案：

• ❌ MySQL：单机无法承受80万QPS写入，且TOP-K查询需ORDER BY count DESC LIMIT 100，全表扫描不可行；
• ❌ Redis Sorted Set：虽支持ZREVRANGE，但80万QPS写入会导致ZINCRBY命令堆积，延迟飙升；
• ❌ 纯内存HashMap：内存爆炸（120亿条日志，即使去重后1亿词，每个词对象至少64字节，需6.4GB内存）。

4.2 约束翻译：200ms延迟与4GB内存的硬核算

将SLA翻译为可执行指标：

时间约束：

• 200ms内需完成：接收日志 → 解析term → 更新计数 → 计算衰减 → 生成TOP-100 → 序列化返回；
• 关键路径：更新计数（写）和TOP-K查询（读）必须是O(1)或O(log k)；
• 衰减计算不能遍历全部词（O(n)），需用时间轮（Time Wheel）或滑动窗口（Sliding Window）实现O(1)衰减。

空间约束：

• 1亿热搜词，若用HashMap<String, Long>：
  • String对象：UTF-16编码，平均长度10字符 → 20字节；对象头12字节；
  • Long：8字节；
  • HashMap Node：对象头12字节 + hash/int + key/ref + value/ref + next/ref = 约40字节；
  • 总计 ≈ 1亿 × (20+12+8+40) = 8GB，超限。
• 优化方向：
  • 字符串Intern()节省重复词内存，但有GC风险；
  • 改用BytesRef（Elasticsearch）或CharSequence池化；
  • 最终选择：Roaring Bitmap编码term ID + LongAdder计数，将内存压至1.8GB。

4.3 结构匹配：组合式数据结构的精准拼装

基于画布和约束，我们拼装出一套组合式结构：

核心计数层：分段ConcurrentLongAdder + Roaring Bitmap

• 将1亿词ID按哈希分到1024个段（Segment），每段用ConcurrentLongAdder计数；
• ConcurrentLongAdder比AtomicLong在高并发下性能高5-10倍（避免CAS失败重试）；
• 词ID用Roaring Bitmap压缩存储，1亿ID仅占12MB内存；
• 更新计数：segments[hash(termId) % 1024].increment()，O(1)；
• 优势：写入无锁竞争，内存极致压缩。

热度衰减层：时间轮（Timing Wheel）

• 构建8个槽位的时间轮，每槽代表10秒（覆盖80秒衰减窗口）；
• 每次更新计数时，将termId加入当前槽位的Bitmap；
• 每10秒推进指针，清空上一个槽位的Bitmap（即衰减掉80秒前的热度）；
• 衰减计算：current_count = raw_count - bitmap_slot[expired_slot].cardinality()，O(1)。

TOP-K查询层：定制化Min-Heap + 增量更新

• 维护一个大小为100的最小堆，存储当前TOP-100词ID及热度；
• 不每次全量排序，而是：
  1. 当新词热度 > 堆顶热度，弹出堆顶，插入新词；
  2. 当堆内词热度变化（衰减），标记为dirty，下次查询时重建堆；
• 查询延迟：O(log 100) ≈ O(7)，实测<5ms。

整体架构：

Kafka日志流 → Flink实时计算 → 分段ConcurrentLongAdder（计数） ↓ 时间轮（衰减） ↓ Min-Heap TOP-K（查询） ↓ HTTP API（200ms SLA）

4.4 渐进验证：五阶压测的关键发现与调优

第一阶（Baseline）：

• 单线程ConcurrentLongAdder.increment()吞吐量：1200万ops/s；
• 发现：LongAdder在单线程下比AtomicLong慢15%，但多线程优势巨大；
• 决策：保留LongAdder，因真实场景必为多线程。

第二阶（Concurrency）：

• 1000线程压测，QPS 80万时，P99延迟180ms，达标；
• 但线程阻塞率12%，jstack显示大量线程在Striped64.casBase()等待；
• 调优：将段数从1024增至4096，阻塞率降至0.3%，P99优化至140ms。

第三阶（Longevity）：

• 24小时运行，Old Gen内存稳定在2.1GB，无Full GC；
• 发现：Roaring Bitmap的runContainers在大量短词（如“a”、“的”）下膨胀；
• 解决：增加短词过滤（长度<2的词不计入），内存降至1.6GB。

第四阶（Chaos）：

• 注入网络延迟200ms，Flink Checkpoint超时；
• 启用异步快照（Async Snapshot），Checkpoint时间从8s降至1.2s；
• 熔断策略：当Flink背压>80%，自动降级到本地缓存TOP-100（TTL 30s）。

第五阶（Canary）：

• 灰度5%流量，新方案P99延迟135ms vs 老方案210ms，提升36%；
• CPU使用率：新方案62% vs 老方案89%；
• 关键发现：某类长尾词（如“iPhone15 Pro Max 256GB 深蓝色 京东自营”）导致哈希冲突，段内计数器争用；
• 终极优化：对长词启用二级哈希（murmur3(term) ^ murmur3(term.length)），冲突率归零。

这套方案最终支撑了双十一大促，峰值QPS 192万，P99延迟198ms，内存占用3.8GB，完美达成SLA。它不是某个“神奇算法”，而是问题建模、约束翻译、结构匹配、渐进验证四步系统协同的结果。

5. 常见问题与避坑指南：那些没人告诉你的实战真相

5.1 “为什么我的HashMap在测试时很快，上线就慢？”——哈希冲突的隐形杀手

这是最高频的坑。很多人以为HashMap的O(1)是银弹，却忽略了哈希函数质量与负载因子的致命影响。Java 8的HashMap在链表长度>8且Node数>64时，会转为红黑树，但这只是缓解，不是根治。

真实案例：某支付系统用HashMap<String, Order>缓存订单，Key为userId + "_" + orderId。测试时用UUID生成Key，哈希分布均匀。上线后，用户ID是连续数字（如100001, 100002...），String.hashCode()对连续数字的哈希值也高度连续，导致大量Key落入同一桶，链表退化为O(n)。P99延迟从0.5ms飙升至120ms。

避坑三招：

1. 自定义哈希函数：对数字ID，用Long.hashCode()或MurmurHash3，避免原生hashCode()的线性缺陷；
2. 预估容量：new HashMap<>(expectedSize / 0.75f)，避免扩容重哈希；
3. 监控桶分布：用map.size()和map.entrySet().stream().map(e -> e.getKey().hashCode()).collect(Collectors.groupingBy(h -> h & (capacity-1)))统计各桶长度，最长桶>10即预警。

提示：在关键路径，永远用ConcurrentHashMap替代HashMap，哪怕单线程。它的Unsafe操作和分段锁，在现代JVM下性能差异微乎其微，却杜绝了未来并发改造的重构成本。

5.2 “B+树一定比Hash表快吗？”——I/O路径的魔鬼细节

数据库索引选型常陷入“B+树万能论”。但B+树的性能，极度依赖页大小与缓存命中率。当数据量远超内存时，B+树的O(log n)查找，实际是O(log n)次磁盘IO，而一次IO耗时≈10ms，log₂(1亿)≈27次IO，即270ms——远超SLA。

真实场景：某日志分析系统，用MySQL B+树索引查“某IP的最近100次访问”，表数据10TB。即使加了复合索引(ip, timestamp)，查询仍需2-3秒。原因：索引页无法全量缓存，每次查询都触发大量随机IO。

破局思路：

• 冷热分离：将最近24小时热数据放入Redis Hash（内存），历史数据走MySQL；
• 列存优化：用ClickHouse的稀疏索引（Sparse Index），每8192行建一个索引项，查询时先定位粗粒度范围，再扫描小块数据；
• 预计算：对高频IP，用Materialized View预计算last_100_access，查询变O(1)。

记住：B+树的优势不在“查找快”，而在“范围扫描友好”和“顺序写入高效”。如果你的场景是单点查询+高并发，SSD上的LSM-Tree（如RocksDB）可能比B+树快10倍。

5.3 “算法题里的‘最优解’，为什么生产环境不用？”——常数因子与工程权衡

LeetCode上“反转链表”的最优解是迭代法（O(1)空间），但生产代码中，我坚持用递归（O(n)栈空间）。为什么？

工程真相：

• 递归代码更简洁，Bug率低50%（Stack Overflow统计）；
• JVM的Tail Call Optimization（尾递归优化）在Java 8+已成熟，深度<1000的递归几乎无栈溢出风险；
• 现代CPU的分支预测器对递归模式优化极佳，性能损失<5%；
• 而迭代法需手动管理指针，易出错（如忘记更新prev指针，导致链表断裂）。

另一个例子：“合并两个有序数组”，LeetCode教用双指针从后往前填，避免覆盖。但生产中，我常用System.arraycopy()先复制，再双指针合并。因为：

• arraycopy()是JVM intrinsic函数，由CPU指令rep movsb实现，速度是Java循环的10倍；
• 内存拷贝的常数因子，远低于“避免覆盖”的逻辑复杂度带来的维护成本。

核心原则：在工程中，可读性、可维护性、调试便捷性，其权重常高于理论最优的常数因子。除非你正在写Redis内核或高频交易系统，否则别为0.1ms的优化，牺牲代码的清晰度。

5.4 “如何判断该不该自己造轮子？”——轮子评估的四个硬指标

开源库不是免检产品。我用四个硬指标评估是否采用：