选对结构，代码才不“卡壳”
开发一个电商后台时，最常遇到的问题之一就是商品分类的展示。一级分类、二级分类、三级分类，甚至更多层级，如果直接用数据库查一层、再查下一层，页面加载慢得像老式拨号上网。这时候，用树形结构组织分类数据，一次查询全部读出来，前端递归渲染，体验立马提升。
树，是数据结构里最典型的层级模型。把分类数据构造成一棵树，每个节点存 ID、名称和子节点列表，后端返回 JSON 的时候就已经是嵌套结构，前端拿到就能直接用。比起反复查数据库，效率高了不少。
排队还是插队？看场景选结构
订单系统里经常要处理用户提交的请求。比如秒杀活动开始，成千上万的用户同时点“下单”，服务器不能一下子全接住，得排队。这时候用队列（Queue）最合适——先进先出，谁先点谁优先处理，公平又稳定。
但有些场景就得“插队”。比如系统里有个紧急任务需要立刻执行，普通任务就得先让一让。这时候换成优先队列（Priority Queue），给任务加个权重，系统自动挑最重要的先做。医院挂号系统也是这样，急诊病人当然不能按来的时间排，得优先处理。
查得快，靠的是“索引思维”
用户登录时验证账号密码，如果每次都要遍历所有用户一条条比对，等找到匹配的可能用户都走掉了。实际做法是用哈希表（Hash Table），把用户名作为键，用户信息作为值，查找时间几乎是固定的，不管数据有多少，都能快速定位。
这种思想也用在缓存设计里。Redis 存 session 数据，本质就是拿用户 token 当 key，对应的登录信息当 value，一查一个准。没有这层结构，每次访问都要查数据库，系统早崩了。
const userMap = {};
// 登录时存入
userMap[username] = { id: 123, role: 'admin' };
// 验证时取出
const user = userMap[inputUsername];
if (user && user.password === inputPassword) { /* 允许登录 */ }别小看一个“列表”的选择
前端展示一个动态列表，比如聊天记录，频繁地在末尾添加新消息，用数组就很自然。但如果要在中间插入一条撤回提示，或者删除某条消息，数组的性能就不太行——每次删除都要移动后面所有元素。
这时候链表（Linked List）的优势就出来了。每个消息节点只关心前一个和后一个，插入删除只要改指针，不用动其他数据。虽然随机访问慢一点，但在这种高频增删的场景下，整体更流畅。
现实问题，往往需要组合拳
物流系统要查某个包裹的实时位置，背后可能同时用了多种结构。路径规划用图（Graph）算法算最短路线，站点之间连成边，包裹移动就是节点间的转移；历史轨迹存在数组里按时间排序，方便前端画时间轴；而当前状态可能放在哈希表里，供快速查询。
没有哪一种结构能通吃所有问题。关键是在需求明确后，先想“我要查得多还是改得多”“数据有没有层级”“是否需要排序”，再决定用什么结构打底。好的设计不是炫技，而是让代码跑得稳、改得顺、看得懂。