昨天写 Python 小脚本，脑子一抽想把列表当成字典的 key 存数据，敲完回车控制台直接甩来一个报错，当时我人dou傻了盯着屏幕kan了半天愣是没明白为啥字符串Neng当 key，列表就不行。

截图就是当时控制台报的 unhashable type: 'list'，就是这行破代码，逼得我把字典、哈希表、可变不可变对象全啃了一遍。

说实话，我之前对字典的理解就停留在 “存键值对的容器”，啥底层原理、使用限制一概不知，这次踩坑后才算真的吃透，趁热乎把我的思考过程分享给大家。

# 两个列表，下标一一对应，纯纯笨方法 names = score = # 想查蔡徐坤的分数？得遍历列表找下标，数据多了直接慢死

这就是列表的硬伤：查找、插入的速度会跟着元素变多越来越慢。

然后 Python 的字典就登场了我给它打个Zui贴切的比方：字典就是书本Zui前面的索引目录。你想找某一页内容，不用从头翻到尾，kan目录直接定位页码；字典底层是哈希表，key 通过哈希算法算出一个唯一的索引，直接找到 value 的存储地址，所以查找速度是 O ，不管多少数据，dou是秒查。

# 字python典：key-value键值对 d = {'周杰伦': , '蔡徐坤': , '周星驰': } # 直接查找，瞬间出结果 print # 核心大坑：为啥列表绝对不Neng当字典的 key？

绕回Zui开始的报错，我第一反应是：“Python 歧视列表？凭啥字符串就行？”后来翻了哈希表的设计规则，才恍然大悟：字典的 key 必须是可哈希的，也就是不可变类型。

哈希算法的硬性要求：key 必须固定不变！Ru果 key 是可变的，你改一下列表内容，哈希计算的结果就变了字典直接找不到 value 的位置，整个哈希表就乱套了。

字符串、数字、元组是不可变的，所以Neng当 key；列表、字典是可变的，Python 直接禁止它们当字典的 key。

本来以为字典搞定就收工了结果又被列表sort和字符串replace坑了一把，这俩的效果完全不一样！

# 列表：可变对象 a = print) # None！坑！sort直接修改原列表，不返回新对象 print # # 字符串：不可变对象 str_obj = 'abc' # replace不会改原字符串，只会返回新的字符串！ print) # Abc print # abc 原对象纹丝不动

现在彻底理清了：

也别神话字典，小数据量、不需要快速查找的场景，用列表geng省内存。

字典和集合的工作原理字典和集合Neng如此高效,和它们内部的数据结构密不可分。不同于其他数据结构,字典和集合的内部结构dou是一张......

# . 修改Yi有的key d = print # # . 千万别直接访问不存在的key！会直接报错 # d # KeyError，血的教训 # . 安全访问：用in判断 / get方法 print # False print) # None，不报错 print) # Ke以指定默认值，太香了 print) # # . 删除key d.pop

# 两种创建set的方式 s = {, , } # 列表转set，自动去重 s = set print # {,,,} # 增删元素 s.add s.remove # 集合运算：交集、并集，处理数据超好用 s1 = {, , } s2 = {, , } print # 交集 {,} print # 并集 {,,,}

sometimes 我想，为啥有人会问“为什么百度不收录我的文章”呢？害，你得先kankan是不是你的文章本身质量就不高，你dou说了这么多废话，那当然不收录嘛，对吧？咱就是说要想人家收录，你自己起码是个有价值的内容，不然你说你那叫优质原创，人家凭啥收你呀？你得让搜索引擎觉得你的内容是有用的才行～说实话，现好内容太多了没人会在乎那些敷衍了事的东西。这才是关键所在你要Zuo的就是不断提高自己的写作水平，让你的文章有血有肉，有自己的见解，这样才Neng吸引人，也geng容易被收录。对不对？所以啊，与其抱怨百度不收录，不如静下心来好好优化自己的内容～这才是Zui根本的方法嘛～

这次踩坑爬坑的过程还挺有意思的，你们平时用字典还遇到过啥奇葩问题？评论区一起聊聊～

搞懂字典后kan Set 集合简直是降维打击！Set 和字典的底层原理一模一样，唯一区别：set 只存 key，不存 value,而且 key 不Neng重复，天生自带去重功Neng。

日常用字典的增删改查，我也把踩过的小坑整理好了:

这才是字典正确的打开方式:

顺便记一下字典优缺点,别把它当万Neng药:

直接上Ke以运行demo代码:

Zui后一下收获,不枉我折腾这么久:P