本章进度 10 / 18
56%
正文已完成
L285查找不是只看速度，还要看前提
比较线性查找、映射查找与二分查找的输入条件和维护成本。
先用本课建立“查找与排序”的基本直觉，后面的判断和练习才不会只靠记结论。
建议按完整课程顺序先看上一课；如果术语陌生，可以随时回补。
- 无需安装新工具
- 直接阅读并完成本页理解检查
“二分查找更快”只在数据已按目标字段排序且能随机访问时成立；映射查找也依赖稳定键和额外索引。先检查前提，再谈速度，能避免为了偶尔查询付出持续维护成本。
能根据是否有序、是否有稳定键和更新频率选择基础查找方式。
核心概念
先把关键判断说清楚
线性查找前提最少
从头逐项检查无需预处理，适合小集合、一次性任务或查询条件经常变化的场景。
二分查找依赖有序
每次排除一半范围很高效，但排序字段必须与查找条件一致，并保持顺序。
映射查找依赖键和空间
按唯一键读取通常很快，但需要建立索引、占用空间并在数据变化时同步维护。
案例拆解
200 条配置为什么不必先排序
脚本启动时只检查一次 200 条配置中是否存在废弃字段，团队计划先排序再用二分查找。
- 01
确认任务只执行一次，且查找条件是多个可能变化的字段名。
- 02
直接线性遍历并对每条执行规则检查，不增加排序步骤。
- 03
只有当同一集合被大量重复按固定键查询时，才考虑建立 Set 或映射。
案例结果
实现更短且总工作量更低，没有为一次查询维护不必要的顺序。
提交前练习
现在轮到你
为一项真实查找任务选择线性、二分或映射查找。
选做练习：本节练习可用于加速你巩固，但不影响继续学习。
内容会自动保存在当前设备
查看参考答案与评分标准
参考答案
问题是每天按 SKU 查询同一份 5 万商品表数千次；前提是SKU 唯一但原表按更新时间排列；方法是启动时建立 SKU→商品映射，保留原列表顺序，后续按键读取。
评分标准
- 查找条件具体
- 前提检查完整
- 选择考虑了预处理和维护成本
本课收口 · 理解检查
用 30 秒确认你理解了
用 30 秒理解检查确认你抓住了重点；阅读标记、练习和总结都不设硬门槛。
你现在更接近哪一种状态？
尚有必填项未完成，请补齐后再继续。
资料来源
继续核对与延伸阅读
本课内容最近更新于 。
- MDN Web Docs↗reference · 核对日期 2026-08-23