由 dawei Ruby工程师常因语言优雅而轻视底层细节，结果在算法实现中栽跟头。避开这些坑，关键不在背诵公式，而在培养三重心法：耐心读清约束、敬畏数据规模、信任边界测试。
“时间复杂度O(n)就一定快？”未必。Ruby中Array#find与Enumerable#select表面相似，但前者遇到首个匹配即返回，后者必遍历全集——若数据来自ActiveRecord::Relation，#select甚至触发全量数据库拉取。未细读文档和方法签名，可能把本该O(1)的哈希查找写成O(n)的数组扫描，只因误用includes?而非has_key?。
2026AI生成图像,仅供参考
Ruby的“开箱即用”易掩盖性能断崖。比如用Hash.new([])初始化默认值，看似简洁，实则每次键缺失都会新建空数组对象；高频调用下内存暴涨。又如递归求斐波那契时未加记忆化，n=40便陷入指数级重复计算——Ruby解释器不自动优化尾递归，栈溢出前先耗尽CPU。
边界测试常被忽略：空数组、单元素、nil值、超长字符串、负数索引……Ruby允许负索引和灵活切片，但Array[-1]取末项、str[100]返回nil，若后续逻辑未防御性判空，便悄然引入隐性bug。某支付服务曾因未校验金额字符串是否为空而解析出0元，酿成资损。
真正的算法功底，不在炫技式的一行代码，而在克制地选对容器：需要频繁查存在？用Set而非Array；需保持插入顺序且去重？用require ‘set’; Set.new保留唯一性，再转Array可维持序——而非手动uniq!再sort!；处理大文本流？别load进内存，改用IO.foreach逐行处理。
写完算法，静默三秒：这个输入规模，Ruby GC扛得住吗？这个nil，是正常空值还是bug信号？这个“快”，是开发时快，还是上线后真快？答案不在IDE里，在日志、监控与凌晨三点的报警电话中。