算法：基础知识

刚开始写代码的时候,我一直觉得算法是竞赛选手才需要的东西,平时写业务用不上。后来发现不是这样:接口慢、列表卡、数据量一大就超时,这些日常问题背后往往就是算法问题。这篇先把最基础的概念理一遍。

什么是算法？

算法，本质上就是 解决问题的一套步骤。

只要是：

输入一组数据
按照一定规则处理
得到结果

这整套处理过程，就是算法。

它不一定要多高深。按字母顺序查字典是算法,菜谱也是算法——都是一套明确的、可重复执行的步骤。写程序时区别只在于:这套步骤要交给计算机执行,所以每一步都必须写得足够精确,不能有含糊的地方。

算法的理解

为什么程序员需要关心算法？因为同样一个问题，不同的算法效率可能差很多。有的做法可能几秒就能算出来，有的可能要跑好几分钟甚至更久。当数据量变大时，这种差距会越来越明显，所以很多系统性能好不好，其实和算法设计关系很大。

这种差距通常用「时间复杂度」来描述,也就是常见的大 O 记法。它关心的不是某次运行花了几毫秒,而是数据量增长时,运算量以什么速度增长:线性扫描是 O(n),数据翻倍工作量也翻倍;二分查找是 O(log n),数据翻倍只多查一次;而两层嵌套循环的 O(n²),数据翻倍工作量就变成四倍。数据量小的时候大家都很快,一旦到了十万、百万级,增长曲线的差别就是「能用」和「不能用」的差别。

算法通常不会单独存在，它往往和数据结构一起使用。数据结构负责把数据组织好，比如数组、链表、树、哈希表这些；而算法则负责对这些数据进行操作。简单来说，一个负责存数据，一个负责处理数据，两者配合起来，程序才能高效运行。

这两者的选择是互相影响的。同样是「查一个元素在不在」,放在数组里要从头扫到尾,放在哈希表里基本一步就能定位;同样是「频繁在中间插入」,数组要整体挪动元素,链表只需要改指针。所以很多时候,换一个更合适的数据结构,算法自然就快了——问题建模的方式,决定了后面能用什么算法。

在现实系统中，算法其实无处不在。比如搜索引擎要根据算法排序网页，短视频平台要用算法推荐内容，导航软件要用算法计算最短路线，电商平台也会用算法做商品推荐和排序。很多我们每天使用的软件，其实背后都有各种算法在工作。

学习算法并不是为了刷多少题，而是为了培养解决问题的思路。当遇到一个问题时，能快速想到几种解决方式，然后选择效率更高的一种，这才是算法真正的价值。很多经验丰富的工程师，其实都是在不断优化解决问题的方法。

算法学习应该关注什么？

很多人学习算法时容易陷入刷题。

但实际上更重要的是理解：

1.问题如何建模

把一个模糊的现实需求,翻译成清晰的输入、输出和约束条件。建模建对了,问题往往就解决了一半;建错了,后面写得再快也是白费。

2.数据结构如何设计

根据访问模式选结构:查得多用哈希表,要有序遍历考虑树,先进先出用队列。结构选对了,代码会自然变简单。

3.时间复杂度如何优化

先估算当前做法在目标数据量下能不能扛住,再考虑要不要优化。不是所有代码都值得优化,但要知道瓶颈在哪。

4.算法思路如何演进

从暴力解法出发,观察哪里做了重复计算,再一步步改进到更优的解法。这个推导过程比直接背最优解有价值得多。

真正的算法能力，不是记住多少题。而是：看到问题，能快速想到解决思路。

踩坑与注意

• 不要一上来就追求最优解。先写出能跑通的暴力解法,确认理解了问题,再谈优化。很多时候暴力解在实际数据量下已经够用。
• 复杂度分析要结合数据量。n 只有几百的场景,O(n²) 和 O(n log n) 的差别可以忽略;别为了炫技把简单代码改复杂。
• 刷题只记结论、不推过程,过两周就忘。合上题解自己重新推一遍,才算真的会了。
• 别忽略空间复杂度。用空间换时间是常见手段,但缓存、哈希表也会吃内存,要清楚代价在哪。

小结

算法就是解决问题的步骤,数据结构负责组织数据,两者配合决定了程序的效率。衡量算法好坏的核心工具是复杂度分析,它描述的是数据量增长时运算量的增长趋势。学算法的重点不在题量,而在建模、选结构、推导思路这几件事——把它们练熟,遇到新问题时自然知道从哪里下手。