本页目录
先确认你在解什么问题，再确认你会什么算法。
很多选型失误都不是知识不够，而是顺序反了。脑子里先冒出来熟悉的算法，需求就会被硬拗成它能处理的形状。开工前先把输入、输出、约束说清，才知道该去哪个算法桶里找答案。
需求听起来差不多，问题类型可能差得非常远。
“找一群关系最紧密的人”和“找所有互相连着的人”在会议上像一回事，落到算法上可能一个是图遍历，一个是组合优化。场景里一旦出现“最优”“最少”“最大”这类词，别急着兴奋，先怀疑问题是不是已经换了类型。
当你想继续优化之前，先问一句：这件事会不会本来就很难算。
这是 NP-hard 提醒句，不是理论名词卡。排班、路径、覆盖、组合分配，只要迟迟找不到精确做法，就该先检查是不是撞上了复杂度墙。识别出来，动作就该切到近似、启发式，或者回去改需求。
先写一个笨办法，不是认输，是给后面的判断找地板。
暴力解法最重要的价值不是最终上线，而是给你一个能跑、能对、能比较的基线。没有这个基线，你很容易在花哨优化里迷路，最后既不知道快了多少，也不知道值不值得继续投时间。
别拿自己熟悉的算法当答案库，要拿问题分类当索引。
工程现场最常见的误判，是把“我会什么”误当成“问题该怎么解”。Skiena 后半本目录改变人的地方，就在这句提醒里。遇到陌生需求时，先把它归类，再去看这一类通常有哪些候选方法，而不是先从记忆里抓最顺手的那一个。
理论复杂度告诉你方向，实测才告诉你代价。
两个候选算法的大 O 写在纸上，不能替你回答线上到底谁更合适。数据规模、分布、常数因子、缓存命中、实现复杂度，都会把纸面优势改写掉。选型走到最后一步时，要拿真实数据跑一次，而不是拿公式替现场拍板。
什么时候该翻回这页
- 需求描述里出现“最优”“最省”“最短”“最紧密”这类词时，先看第 2 句和第 3 句。
- 团队讨论一上来就在报算法名时，先看第 1 句和第 5 句。
- 你已经写到第三版优化，还说不清快了多少时，先看第 4 句和第 6 句。
- 方案会上有人说“再调一调应该就行”时，先把第 3 句单独拎出来。