list索引访问与dict键访问的技术差异及选型最佳实践

你同事的建议不是单纯的个人编码偏好，是有实际技术合理性的，哪怕你当前用的数据源格式完全固定，这个建议的参考价值依然存在，只是两种方案在你当前场景下的收益差距没那么大而已。

为什么键访问被普遍认为是更好的实践 #

核心原因从来不是“list可能缺元素”这么简单，本质是可维护性、容错性和协作效率的差异：

• 代码自解释能力天差地别。你写item[1]、item[2]的时候，除了刚写完代码的你，其他同事、甚至三个月后回头看这段代码的你自己，根本反应不过来这两个位置取的是什么值——是用户名？订单号？支付金额？必须回头翻数据文件的格式文档才能搞懂。换成item["user_id"]、item["pay_amount"]的写法，代码本身就把语义说清楚了，不需要额外查文档。
  哪怕你100%确定现在数据格式不会变，后续只要数据生成方调整一次字段顺序——比如在列表最前面加了个新字段，你所有写死的索引全要改，漏改一个不会报索引越界的错，只会悄咪咪把错的值传到下游，等发现问题的时候往往已经跑了一堆脏数据，排查成本极高。用键访问的话，字段顺序怎么调都不影响取值逻辑，根本不需要改代码。
• 错误定位效率更高。你觉得“数据格式固定所以不会出问题”的前提，在实际项目里往往比你想的脆弱：比如生成数据文件的团队换了人、某次迭代改了字段顺序忘了同步、某几行数据出了坏点缺了字段，索引用法要么直接报个没头没尾的“索引越界”，要么更糟的是取错位置的值完全不报错。键访问的话，你可以很明确地校验字段是否存在，出问题直接报“缺少pay_amount字段”，一眼就能定位问题。
• 协作成本更低。后续其他同事接手这段代码，看到item[2]根本不敢随便动，生怕改坏逻辑；看到item["pay_amount"]哪怕没接触过这块业务，也能大概知道代码在做什么。

什么时候用索引访问更合适 #

你当前选择用list实现完全是合理的，索引访问并不是不好，只是有它适用的场景：

• 处理同构的顺序集合时：也就是列表里每个元素的语义完全一样，不存在“某个位置对应某个特定字段”的情况，比如存了一堆用户ID的列表[1001, 1005, 1023]，你遍历取每个元素就是用户ID本身，这时候用索引完全没问题。
• 处理通用、定义稳定的短序列时：比如二维坐标[x, y]、RGB颜色值[r, g, b]，这类结构的位置定义是通用共识，几乎不会改动，用索引访问足够简洁，没必要硬套dict。
• 极端性能敏感场景：list的索引访问比dict的键访问有微小的性能优势，但这个差异在99%的业务场景里完全可以忽略，只有处理千万级以上数据、且压测确认这部分是性能瓶颈的时候，才需要把这个点纳入考量。

如果你最终还是决定用list实现，花1分钟给索引位置定义成语义化的常量就行，成本极低但能解决大部分可维护性问题：

# 数据字段索引映射
IDX_USER_ID = 1
IDX_PAY_AMOUNT = 2

other_arg = something
for item in data:
    other_method(other_arg, item[IDX_USER_ID], item[IDX_PAY_AMOUNT])

后续就算字段顺序调整，你只需要改这两个常量的值，不用满代码找魔法数字修改。

内容的提问来源于stack exchange，提问作者Abraham Esparza