都 2026 年了，为什么还要懂数据结构？

从「找钥匙」到会员名单：结构如何改变结果

「同样 36 件杂物，左边一股脑塞进大抽屉，右边按类别放进了分格收纳盒。现在钥匙 🔑 不见了——点下面的按钮，看两边各要翻多少次才能找到」先把数据结构变成了一个可以观察的动作：同样的东西，放在一个大抽屉里只能逐个翻，放进分格盒则可以先定位类别。接着，会员名单实验把这个差别搬进了真实的软件操作——用户只关心“在不在名单里”，但程序要决定每次查询究竟要重复多少工作。

两个版本都能运行，为什么代价不一样

版本 A 每次都从名单开头检查，名单有多少人，最坏就要比较多少次；这是一种随数据量线性增长的查找。版本 B 先把名单放进 Set，再用 has 查询，建立 Set 本身需要一次整理，但在重复查询时通常可以用近似固定的时间定位。若只有一次查询、名单很小，线性扫描完全够用；当同一份名单被反复访问，预先组织数据的成本才会被摊薄。

验收类似代码时，先问三件事

• 这段代码最常执行的动作是什么：按位置读取、判断是否存在、插入新记录，还是遍历关系？
• 数据会从几十条增长到多少？要看平均耗时，也要看最坏情况和重复调用次数。
• 更快的结构带来了什么代价：额外内存、建立索引的时间、更新数据时的同步，以及是否仍然保持原来的顺序？

所以“懂数据结构”并不等于手写所有实现，而是能把「你可能会说：收纳是程序员的事，AI 替我写代码，它收纳去。问题是—— AI 两种都可能写 。同一句需求「查用户是否在会员名单里」，AI 给出的两个版本都能跑通、界面上看不出任何差别。拖动名单人数，看看差别藏在哪」追问到底：代码为什么这样组织，随着数据和调用方式变化，结果会不会改变。这个问题正是 AI 生成代码最需要人工判断的地方。