算法和数据结构是什么关系？

为什么有的课程叫“算法”，有的叫“数据结构”，还有的干脆叫“算法与数据结构”？

如果只看名字，它们像是三门不同的课。但学着学着你就会发现，这几个词几乎总是一起出现。学排序时会碰到数组、堆、树；学图论时会碰到队列、优先队列、并查集；做题时更常常不是单独考“会不会某个算法”，而是考你能不能选对数据结构，再把算法设计出来。

算法和数据结构分别是什么

如果用最朴素的话来说，数据结构回答的是“数据该怎么放”，算法回答的是“问题该怎么解”。

数据结构是组织数据的方法。数组把一批元素连续放在一起，适合按下标快速访问；链表把元素一个接一个串起来，适合某些插入删除场景；栈强调后进先出，队列强调先进先出；树适合表达层级关系，图适合表达连接关系，哈希表适合快速按键查找。

算法则是解决问题的步骤。比如怎样排序，怎样查找，怎样从一个地点走到另一个地点，怎样在很多选择中找到最优方案，怎样判断一段字符串是否满足某种规则。这些都属于算法关心的事情。

算法和数据结构的侧重点

叫数据结构的课，往往更强调“数据怎么存、怎么组织”。它会带你认识数组、链表、栈、队列、树、图、哈希表、堆这些常见结构，让你理解不同组织方式分别适合什么操作，也让你意识到，同样是一份数据，存法不同，程序效率可能差很多。

叫算法的课，往往更强调“问题怎么解、步骤怎么设计”。它会更多讲排序、查找、分治、贪心、动态规划、回溯、图算法、字符串算法这些思路，让你逐渐建立起一种解决问题的框架感。

而叫算法与数据结构的课，其实最接近真实世界。因为在真正写程序时，你几乎不可能只想算法，不想数据怎么存；也不可能只想数据结构，却不考虑要怎样处理它。大多数时候，这两件事本来就是一起发生的。

所以，这三种命名方式并不冲突。它们只是从不同角度切入同一个核心能力：如何高效地表示问题，并高效地解决问题。

算法和数据结构分不开

很多初学者一开始会把算法想得很“高”，把数据结构想得很“基础”。但真正写程序时，你很快就会发现，算法的效率经常直接取决于数据结构的选择。

比如最简单的查找问题。假设你要判断数字 42 是否存在于一组数据里。如果数据只是乱序放在数组中，那你往往只能一个一个检查过去，复杂度通常是 O(n)。如果这组数据已经有序，你就可以用二分查找，把复杂度降到 O(log n)。如果数据是存在哈希表里，那么平均情况下查找甚至可以接近 O(1)。

反过来，没有算法，数据结构也并没有太大意义。栈、队列、堆、树、图本身都不会自动帮你解决问题。它们之所以重要，是因为某些算法恰好能借助它们的特性。

比如说，为什么要有先进先出的栈？因为他的思想和栈常用于括号匹配、函数调用、表达式求值这样的问题能对应上。为什么要有堆？因为 Dijkstra 等其他算法需要快速的取出集合的最小值。

所以，算法和数据结构的关系，不是“谁更高级”，而是“一个决定怎么组织，一个决定怎么操作”。它们是程序设计里天然配套的两部分。

真实世界里，到处都是“数据结构 + 算法”

在我们每天在用的软件里，到处都是这两者的配合。

地图导航就是一个非常典型的例子。地图上的地点可以看成点，道路可以看成边，整张地图就是一张图。图是数据结构，寻找最短路径的过程是算法。你需要正确表示图这种数据结构，再在这个数据结构上，运用最短路径算法得到导航结果。

搜索框的自动补全也是类似。你在输入法、电商平台或搜索引擎里输入几个字，系统马上给出很多候选。表面上看，这是一个“联想”功能，背后其实是如何组织大量词条，以及如何快速完成前缀匹配（这需要用到各种各样的字符串匹配算法）。而组织这些字符串又一定会用到哈希表、字典树这类结构。

浏览器的“返回”和“前进”同样是很好的例子。你访问页面的过程是有顺序的，点击“返回”时，你总是先回到最近访问的页面。这背后就很符合栈的思想。

再比如缓存系统。很多程序为了提速，会把最近常用的数据先放到缓存里。但缓存空间有限，满了以后该淘汰谁？这就会引出经典的 LRU 问题。为了同时做到“查得快”和“删得快”，常常会把哈希表和双向链表配合起来使用。

消息队列、任务调度、社交关系推荐、搜索排序、数据库索引，这些工程场景背后，也几乎都离不开“合适的数据结构 + 合适的算法”这组组合。

为了特定的算法目的选取数据结构

频繁判断某个元素是否存在时，用数组可能就不如用哈希表；频繁维护一组数据中的最大值或最小值时，堆往往比每次重新排序更自然；要表示层级关系时，树比一堆零散变量清晰得多；要表示网络连接关系时，图比临时拼凑的数据更合理。

也就是说，很多所谓“算法题”的第一步，其实并不是立刻想步骤，而是先问一句：这份数据，到底应该怎么存？

一旦结构选对了，很多算法思路会变得顺理成章。结构没选对，再努力优化，往往也只是局部修补。

为什么算法竞赛 / ACM 并不只是“算法”

说到这里，就很自然能理解“算法竞赛”这个名字为什么也容易让初学者产生误会。

很多人第一次听到算法竞赛，会觉得那大概就是比谁会更多算法模板。其实并不是。像 ACM、ICPC、NOI 这一类竞赛，本质上考察的是综合解决问题的能力。这里面通常至少同时包含三部分：算法、数据结构和数学。

先说数据结构。很多竞赛题表面看是在考最短路、区间查询、连通性判断，真正做起来却离不开并查集、堆、线段树、树状数组、Trie、邻接表这些结构。题目不会专门问你“什么是并查集”，但它可能会要求你在很多次操作后快速判断两个元素是否属于同一个集合。这时候，数据结构不是背景知识，而是解题核心。

再说数学。很多初学者会意外地发现，算法竞赛里并不只是写代码，数学能力也非常重要。数论、组合计数、概率、递推、离散数学、几何、模运算，这些内容在竞赛里都非常常见。因为很多题真正的难点不在“代码怎么写”，而在“你能不能先看出规律，完成抽象”。

所以，“算法竞赛”这个名字虽然叫算法，但实际考察的从来不是狭义的算法本身，而是你能不能把问题抽象成合适的模型，选对结构，设计出可行的算法，并且完成稳定实现。

从这个角度看，算法竞赛恰恰最能说明：算法和数据结构不是两门各自独立的手艺，而是一种需要同时运用的能力。再往上走一步，它还会和数学一起结合起来。

总结：程序 = 数据结构 + 算法。对初学者来说，随着你不断学习，你就能慢慢体会它为什么成立。