为什么程序员总在聊数据结构？
你有没有遇到过这种情况：写好的程序一跑起来就卡，数据量稍微大点，响应时间直接从1秒跳到十几秒。其实问题不一定出在代码写得差，而是“放东西的方式”不对。
就像整理衣柜，把所有衣服堆在一起最省事，但找一件T恤得翻半天。如果按季节、类型挂好，取用效率立马提升。数据结构干的就是这个活——它决定数据怎么存、怎么拿、怎么处理。
数组：最基础也最容易踩坑
数组就像一排编号的储物柜，每个位置固定，通过下标快速访问。比如你要查第5个学生成绩，arr[4]直接拿到，速度飞快。
但它也有短板：想在中间插入一个新学生？后面所有人得分全往后挪，代价不小。所以频繁增删的场景，数组不是最优选。
链表：灵活的“接力队”
链表像一串钥匙环，每块数据带着下一环的线索。插入删除特别方便，改改指针就行，不用搬动整体。
但想访问第10个节点？只能从头一个个传下去，没法“瞬移”。这就像微信群里传文件，虽然加人退人都容易，但消息不能跳着看。
struct ListNode {
int val;
struct ListNode* next;
};栈和队列：有规矩的数据流
栈是“后进先出”，像自助餐厅的托盘架，最后放的最先被取走。函数调用、括号匹配都在用它。
队列是“先进先出”，像排队买奶茶，先来的先服务。任务调度、广度优先搜索都靠它维持秩序。
树：分层管理的高手
二叉树是最常见的树结构，每个节点最多两个分支。它能把查找效率从O(n)降到O(log n)。
想象一下公司组织架构：CEO下面两个副总，每人再管几个部门。信息传递层层递进，比所有人直接向老板汇报清晰多了。
二叉搜索树更聪明，左小右大，查一个数跟二分查找一样快。
struct TreeNode {
int val;
struct TreeNode* left;
struct TreeNode* right;
};哈希表：键值对的快递系统
哈希表就像快递柜，输入手机号（键），马上定位到格子（值）。理想情况下，查询接近O(1)。
但它怕“撞柜”——不同人手机号算出同一个格子号，就得拉链或开放寻址解决。设计好哈希函数，才能避免拥堵。
图：复杂关系的建模工具
社交网络、地图路线、网页链接，这些关系错综复杂，用图来表示最合适。节点是用户或地点，边是关注或路径。
用邻接表存储稀疏图省空间，邻接矩阵适合密集连接。选对结构，算法才能跑得顺。
实际开发中的选择建议
别死记理论，结合场景判断。比如：
要频繁随机访问？选数组或动态数组（vector）。
经常在中间插删？链表或双向链表更合适。
需要快速查找且数据有序？平衡二叉搜索树或跳表。
只是存配置项，按key取值？哈希表闭眼选。
搞算法题时，先想清楚操作类型：读多写少？还是写多读少？再挑对应优势的数据结构，效率自然上来。