1. 为什么 frozenset 不是“鸡肋”而是你代码里缺的那块安全垫你有没有在写 Python 时遇到过这种场景一个本该代表“固定权限组”的变量在某个深夜调试时突然发现它被某个毫不起眼的辅助函数悄悄.add()了一条新权限或者你精心设计了一个基于用户角色组合的缓存键结果因为传入的是普通set程序直接抛出TypeError: unhashable type: set而你花了二十分钟才定位到问题根源又或者你在重构一个大型配置模块时反复检查文档、加日志、甚至写单元测试就为了确认某个全局的“允许操作类型集合”真的没被任何地方意外修改——结果发现最省心的办法其实是从一开始就不给它修改的机会这就是frozenset存在的真实语境。它不是教科书里一个用来凑齐“不可变类型全家桶”的摆设也不是面试官用来考察你是否读过官方文档的冷知识。它是一把精准的手术刀专治“本不该变却变了”、“本该能当钥匙却不能用”、“本该一眼看懂意图却要靠注释解释”这三类在中大型项目里高频出现的顽疾。它的核心价值从来不在“它能做什么”而在于“它坚决不做什么”。当你把一个set变成frozenset你不是在增加功能而是在向整个代码库发出一个无法被忽略的契约声明“此数据结构的生命周期止于其创建完成之时。任何后续的修改企图都是逻辑错误而非实现疏漏。” 这种由语言原生机制强制保障的契约比十行注释、一百个assert或者一套复杂的封装类都更可靠、更轻量、也更符合 Python 的哲学——简单、明确、且让错误尽早暴露。它解决的不是语法层面的问题而是工程层面的可维护性与可预测性问题。如果你的项目里还没有一个frozenset那很可能不是你不需要它而是你还没遇到那个让你不得不把它请出来的“临界点”。2. 核心设计思路为什么 Python 要为 set 单独造一个“冰冻版”2.1 从“能改”到“不能改”一场关于信任的底层重构理解frozenset的设计必须回到 Python 最根本的数据模型。Python 中一个对象能否被用作字典dict的键或者被放入另一个集合set中取决于它是否是“可哈希的”hashable。而可哈希性的黄金法则只有一条对象的哈希值在其整个生命周期内必须保持不变。这个哈希值本质上就是 Python 为该对象计算出的一个唯一数字指纹用于在哈希表如字典的底层实现中快速定位。现在我们来看一个普通set。假设你创建了s {1, 2, 3}Python 会为它计算一个哈希值h1。但紧接着你执行s.add(4)集合的内容变成了{1, 2, 3, 4}。此时它的哈希值理应变成一个新的h2因为内容已经不同了。问题来了如果这个set此前已经被用作某个字典的键比如cache {s: expensive_result}那么当s的内容和哈希值都变了之后Python 就再也无法通过原来的h1在哈希表里找到它对应的expensive_result了。这会导致缓存失效、数据丢失甚至引发难以追踪的逻辑错误。因此Python 的设计者做出了一个极其务实的决定所有可变对象一律禁止哈希。list、dict、set全部被划入“不可哈希”的黑名单从根本上杜绝了这种灾难性场景的发生。frozenset的诞生正是对这一限制的优雅解法。它没有试图去“修复”set的可变性而是另起炉灶创造了一个全新的、从出生起就被“封印”了修改能力的类型。它的内部实现可以理解为在创建时就将所有元素“快照”下来并基于这个静态快照计算出一个永久不变的哈希值。由于它天生就无法被add、remove、update等任何方法所改变所以它的哈希值天然就是稳定可靠的。这就像给一个普通的、随时可能被涂改的便签纸set换成了一个用防伪油墨印刷、并加盖了钢印的正式文件frozenset。你不需要额外的流程去保证它的内容不被篡改因为篡改这个动作本身在物理层面或者说Python 的语法层面就是被禁止的。这种设计思路体现了 Python “显式优于隐式”和“简单胜于复杂”的核心哲学——与其提供一堆复杂的运行时保护机制不如用一个清晰、不可绕过的语法约束来一劳永逸地解决问题。2.2 与 tuple 的本质分野不是“谁更不可变”而是“谁在表达什么”很多人第一次接触frozenset时会下意识地把它和tuple比较觉得它们都是“不可变的容器”似乎可以互相替代。这是一个非常危险的误解它混淆了数据结构的“形态”form与“语义”semantics。tuple和frozenset的不可变性服务于完全不同的目的。tuple的不可变性是为了保护其结构。一个tuple代表一个有序的、位置敏感的元组。例如point (x, y)中的x必须是第一个元素y必须是第二个元素。交换它们的位置得到(y, x)这个新元组就代表了一个完全不同的点。tuple的语义是“我是一个有固定顺序和固定含义的复合值”。它的不可变性确保了这个复合值的结构完整性。frozenset的不可变性则是为了保护其内涵。一个frozenset代表一个无序的、只关心“成员资格”的集合。frozenset({read, write})和frozenset({write, read})是完全等价的它们表达的都是“拥有读和写两种权限”这个概念。frozenset的语义是“我是一个固定的、无序的、唯一的元素集合”。它的不可变性确保了这个集合所代表的概念不会被歪曲。你可以这样类比tuple像是一份带编号的座位表1号座是张三2号座是李四这个编号顺序就是它的全部意义而frozenset像是一份参会人员名单上面写着“张三、李四”至于谁的名字排在前面完全无关紧要重要的是这份名单上有没有这两个人。如果你用tuple来表示权限(read, write)和(write, read)在 Python 看来是两个完全不同的键这会导致你的权限系统出现莫名其妙的 bug。而frozenset则天然地消除了这种歧义。因此选择frozenset还是tuple不是一个技术可行性问题而是一个设计意图的清晰度问题。当你想表达“一组东西顺序不重要只关心有没有”frozenset是唯一正确的答案。3. 实操细节解析从创建到使用每一步都藏着经验之谈3.1 创建那些你必须知道的“坑”与“捷径”创建frozenset看似简单但其中的门道足以让一个新手在调试时抓耳挠腮。第一大坑空集合的创建陷阱这是最经典、最高频的错误。很多初学者会想当然地写empty {}然后惊讶地发现type(empty)居然是class dict。这是因为{}在 Python 语法中被明确地定义为“空字典”的字面量literal而不是“空集合”的字面量。set本身也没有自己的字面量创建空set必须用set()。同理创建空frozenset唯一的、标准的、且被所有 Python 版本支持的方式就是frozenset()。没有任何捷径也没有任何替代方案。看到代码里出现frozenset()你应该立刻意识到这是一个经过深思熟虑的、明确的、空的、不可变的集合声明。它不是偷懒而是一种宣言。第二大坑从可变集合“冻结”的最佳时机frozenset的强大之处往往体现在它与set的配合上。一个非常实用的模式是先用set构建再用frozenset锁定。例如定义一个全局的权限常量# ✅ 推荐构建期灵活使用期安全 ADMIN_PERMISSIONS_SET {read, write, delete, admin} # ... 可能还有其他地方会往里面添加比如根据配置动态加载 ADMIN_PERMISSIONS_SET.update(load_extra_permissions_from_config()) # 一切准备就绪后将其“冻结” ADMIN_PERMISSIONS frozenset(ADMIN_PERMISSIONS_SET)这个模式的好处是巨大的。在构建阶段你享受了set的所有便利可以add、update、difference_update可以轻松地进行各种集合运算来组装最终的权限集。一旦组装完成frozenset(ADMIN_PERMISSIONS_SET)这一行代码就像按下了“确认”按钮将这个动态构建的结果永久地固化为一个不可变的常量。此后任何试图修改ADMIN_PERMISSIONS的代码都会在运行时立即报错而不是在某个遥远的、难以复现的分支逻辑里悄悄引入 bug。这是一种“延迟冻结”的智慧它平衡了开发的灵活性与生产的稳定性。第三大捷径利用frozenset的构造器自动去重frozenset的构造器接受任何可迭代对象并且会像set一样自动帮你去除重复元素。这意味着如果你有一个包含大量重复项的列表或元组用frozenset来处理是既简洁又高效的# 假设你从数据库或 API 获取了一堆可能重复的标签 raw_tags [python, web, python, backend, web, python] # 一行代码得到一个去重、无序、且不可变的标签集合 unique_tags frozenset(raw_tags) # frozenset({python, web, backend})这比先set(raw_tags)再frozenset(...)要少写一个括号更重要的是它清晰地表达了你的意图你想要的不是一个临时的、可变的中间结果而是一个最终的、稳定的、去重后的集合。3.2 使用读取、运算与嵌套一切皆可唯独不能“动”frozenset的使用体验几乎与set完全一致除了那个最核心的限制你永远无法修改它。所有“读取”和“查询”操作都畅通无阻。成员检查read in ADMIN_PERMISSIONS返回True或False和set一样快。遍历for perm in ADMIN_PERMISSIONS:可以正常循环只是你无法预知元素的顺序这恰恰是frozenset的特性而非 bug。集合运算这是frozenset最闪耀的地方。所有的二元运算符|并集、交集、-差集、^对称差集都完美支持并且它们的行为是“纯函数式”的输入是两个frozenset输出是一个全新的frozenset原始的两个输入对象丝毫无损。例如user_roles frozenset({editor, viewer}) required_perms frozenset({read, write}) # 计算用户是否拥有所有必需权限交集等于必需权限 has_all_required (user_roles required_perms) required_perms # 或者计算用户实际拥有的必需权限交集 actual_perms user_roles required_perms # frozenset({read})这段代码的健壮性极高。无论user_roles和required_perms被多少次复用、传递到多少个函数里它们的值都坚如磐石。你不需要担心某个函数会在背后偷偷user_roles.add(admin)从而污染了其他地方的逻辑。这种确定性是编写可维护、可测试代码的基石。提示frozenset的所有运算符返回的都是新的frozenset对象而不是set。这意味着frozenset({1, 2}) | frozenset({2, 3})的结果依然是frozenset你可以放心地将其作为字典键或放入另一个set中无需二次转换。4. 实操过程四个真实世界场景的完整实现与深度剖析4.1 场景一构建一个坚不可摧的权限控制系统在一个 Web 应用中权限管理是核心且高风险的模块。我们需要定义不同角色如admin,editor,viewer所拥有的具体权限如read,write,delete,admin并能快速判断一个用户是否拥有执行某项操作所需的全部权限。传统set方案的风险# ❌ 危险全局可变状态 ROLES_PERMISSIONS { admin: {read, write, delete, admin}, editor: {read, write}, viewer: {read} } # 某个不相关的业务逻辑不小心修改了它 ROLES_PERMISSIONS[editor].add(delete) # Oops! 编辑者现在也能删了frozenset方案的实现# ✅ 安全所有权限集均为不可变常量 ADMIN_PERMISSIONS frozenset({read, write, delete, admin}) EDITOR_PERMISSIONS frozenset({read, write}) VIEWER_PERMISSIONS frozenset({read}) # 角色到权限的映射值也是 frozenset确保映射关系本身也不可变 ROLES_PERMISSIONS { admin: ADMIN_PERMISSIONS, editor: EDITOR_PERMISSIONS, viewer: VIEWER_PERMISSIONS } def user_has_permission(user_role: str, required_perms: frozenset) - bool: 判断用户角色是否拥有所有必需权限。 :param user_role: 用户的角色字符串 :param required_perms: 一个 frozenset包含所有必需的权限 :return: 如果用户拥有所有必需权限则返回 True if user_role not in ROLES_PERMISSIONS: return False # 关键使用交集运算检查必需权限是否是用户权限的子集 # (A B) B 等价于 B.issubset(A) user_perms ROLES_PERMISSIONS[user_role] return (user_perms required_perms) required_perms # 使用示例 print(user_has_permission(editor, frozenset({read, write}))) # True print(user_has_permission(editor, frozenset({read, delete}))) # False深度剖析这个方案的威力在于其“传染性”的安全性。ADMIN_PERMISSIONS等常量是frozensetROLES_PERMISSIONS字典的值也是frozenset而函数参数required_perms的类型提示也强制要求是frozenset。这意味着从数据定义、到数据存储、再到数据消费整个链条都被frozenset的不可变性所贯穿。任何试图在函数内部修改user_perms的尝试都会在user_perms.add(...)这一行就失败错误信息清晰明了AttributeError: frozenset object has no attribute add而不是等到某个用户真的执行了删除操作才发现权限被错误授予。4.2 场景二用作字典键实现多维、语义化的缓存在数据处理中我们经常需要缓存一些昂贵的计算结果。但如果缓存的“键”本身是一个集合比如计算某个用户组的所有共同好友用list或set都不行因为它们不可哈希。frozenset方案的实现from functools import lru_cache # 模拟一个昂贵的数据库查询函数 def expensive_db_query(user_ids: frozenset) - list: 模拟根据用户ID集合查询共同好友 # 实际逻辑JOIN 多张表聚合计算... print(fExecuting expensive query for users: {user_ids}) # 这里返回一个模拟结果 return [common_friend_1, common_friend_2] # ✅ 使用 frozenset 作为 lru_cache 的参数使其可哈希 lru_cache(maxsize128) def cached_common_friends(user_ids_frozen: frozenset) - list: return expensive_db_query(user_ids_frozen) # 使用示例传入一个 frozenset group_a frozenset({101, 102, 103}) group_b frozenset({102, 103, 101}) # 顺序不同但内容相同 print(cached_common_friends(group_a)) # 第一次调用执行查询 print(cached_common_friends(group_b)) # 第二次调用命中缓存 # 输出 # Executing expensive query for users: frozenset({101, 102, 103}) # [common_friend_1, common_friend_2] # [common_friend_1, common_friend_2]深度剖析lru_cache装饰器内部依赖于函数参数的哈希值来构建缓存键。frozenset({101, 102, 103})和frozenset({102, 103, 101})的哈希值是完全相同的因为frozenset的哈希算法只与元素的集合本身有关与插入顺序无关。这使得我们的缓存逻辑变得极其健壮和智能。无论前端如何组织用户ID列表按注册时间、按姓名拼音、甚至随机打乱只要最终的用户集合是相同的缓存就能正确命中。这极大地提升了系统的性能和用户体验而这一切都建立在frozenset的哈希一致性之上。4.3 场景三在集合中存储集合构建复杂的配置模型想象一个微服务架构每个服务都有一个它所依赖的“上游服务集合”。我们需要一个全局的、去重的、所有可能的依赖关系集合。frozenset方案的实现# 定义各个服务的依赖 service_a_deps frozenset({database, auth-service}) service_b_deps frozenset({cache, auth-service}) service_c_deps frozenset({database, cache}) # ✅ 将这些 frozenset 放入一个 set 中自动去重 all_dependency_patterns { service_a_deps, service_b_deps, service_c_deps, # 注意如果我们再加一个和 service_a_deps 完全一样的它会被自动去重 frozenset({database, auth-service}) # 这个会被忽略 } print(len(all_dependency_patterns)) # 输出3证明去重成功 print(all_dependency_patterns) # 输出{frozenset({database, auth-service}), frozenset({cache, auth-service}), frozenset({database, cache})} # 进阶我们可以轻松地查询某个特定的依赖模式是否存在 pattern_to_check frozenset({database, auth-service}) print(pattern_to_check in all_dependency_patterns) # True深度剖析这个例子展示了frozenset如何解锁了set数据结构的更高阶用法。一个普通的set只能包含不可变对象而frozenset本身就是不可变的因此它可以成为另一个set的元素。这让我们能够用一种极其自然、符合数学直觉的方式来建模“集合的集合”。如果没有frozenset我们只能退而求其次用tuple(sorted(...))来模拟但这不仅丑陋破坏了语义而且效率低下每次都要排序。frozenset提供了一种零成本、零歧义、且完全符合直觉的解决方案。4.4 场景四作为复合键的一部分实现细粒度的策略路由在一个风控系统中决策引擎需要根据“用户ID 用户所属的权限组”来查找匹配的风控策略。权限组是一个集合因此必须是不可变的。frozenset方案的实现# 定义一个策略字典键是 (user_id, permissions_frozen) 的元组 # 因为 permissions_frozen 是 frozenset整个元组就是可哈希的 risk_policies { (123, frozenset({vip, premium})): {max_withdrawal: 10000}, (456, frozenset({basic})): {max_withdrawal: 1000}, (789, frozenset({vip})): {max_withdrawal: 5000}, } def get_risk_policy(user_id: int, user_permissions: frozenset) - dict: 根据用户ID和权限组查找对应的风控策略。 key (user_id, user_permissions) return risk_policies.get(key, {max_withdrawal: 500}) # 默认策略 # 使用示例 print(get_risk_policy(123, frozenset({vip, premium}))) # {max_withdrawal: 10000} print(get_risk_policy(123, frozenset({vip}))) # {max_withdrawal: 500} (默认)深度剖析这里的关键在于frozenset使得(user_id, user_permissions)这个复合键成为可能。user_id是一个整数可哈希user_permissions是一个frozenset可哈希因此它们组成的元组也是可哈希的可以完美地作为字典的键。这比将权限组序列化为 JSON 字符串json.dumps(sorted(list(permissions)), sort_keysTrue)要高效得多也比用tuple(sorted(permissions))更加语义清晰。它直接告诉阅读代码的人“我们关心的是用户属于哪个权限组而不是权限组里权限的排列顺序。”5. 常见问题与排查技巧实录那些只有踩过才知道的坑5.1 问题速查表从报错信息反推根本原因报错信息根本原因排查与解决思路AttributeError: frozenset object has no attribute add代码试图对frozenset执行修改操作。立即检查报错行附近的代码是否误将frozenset当作了set。解决方案要么将该frozenset替换为set如果业务逻辑确实需要修改要么在修改前先用set(frozen_set)创建一个可变副本修改完后再转回frozenset如果只是临时需要。TypeError: unhashable type: set尝试将一个普通的set用作字典键或放入另一个set。立即检查出错行的变量是否本应是frozenset却被错误地初始化为了set。解决方案将set(...)替换为frozenset(...)。这是一个典型的“类型错配”通常发生在从外部数据源如 JSON加载数据后忘记进行类型转换。TypeError: frozenset object is not subscriptable尝试用索引如my_frozen[0]访问frozenset的元素。立即检查代码是否错误地假设frozenset是有序的、可索引的。解决方案frozenset是无序的不支持索引。如果需要获取某个元素可以用next(iter(my_frozen))获取任意一个或sorted(my_frozen)[0]获取排序后的第一个。如果需要按顺序处理请始终使用sorted(my_frozen)。KeyError: frozenset({...})尝试从字典中获取一个frozenset键但该键不存在。注意这不是frozenset的问题而是字典查找失败。但frozenset的无序性可能导致你“以为”键存在。例如你打印frozenset({a, b})看到的是frozenset({b, a})然后你手动写了frozenset({b, a})去查却发现查不到。解决方案永远不要手动拼写frozenset字面量来作为键。应该用同一个变量或者确保用于创建键的可迭代对象是完全一致的如都用sorted(list)后再frozenset。5.2 独家避坑技巧来自生产环境的血泪教训技巧一“冻结点”前置检查法在大型项目中一个frozenset可能被层层传递最终在某个深处的函数里被使用。如果它在中途被意外地“解冻”再“重冻”就会失去其本意。我的做法是在关键的、作为“事实来源”的frozenset常量定义处加上一个断言# 在模块顶部定义全局常量 ADMIN_PERMISSIONS frozenset({read, write, delete, admin}) # ✅ 加上这个断言确保它真的是 frozenset且内容符合预期 assert isinstance(ADMIN_PERMISSIONS, frozenset) assert read in ADMIN_PERMISSIONS and delete in ADMIN_PERMISSIONS这个断言在模块导入时就会执行任何对ADMIN_PERMISSIONS的非法重赋值比如ADMIN_PERMISSIONS set(...)都会在启动时立即暴露而不是等到业务高峰期才崩溃。技巧二frozenset的“伪排序”调试法在调试时看到frozenset({c, a, b})这样的输出有时会让人困惑不确定它是否真的包含了所有预期的元素。虽然frozenset本身无序但我们可以通过一个简单的技巧让它“看起来”有序方便肉眼核对# 调试时用这个代替直接打印 def debug_frozenset(fs): return ffrozenset({sorted(fs)}) # 使用 roles frozenset({admin, editor, viewer}) print(debug_frozenset(roles)) # frozenset([admin, editor, viewer])这个技巧不会改变frozenset的任何行为只是让它的字符串表示更友好极大提升了调试效率。技巧三与typing.Final的协同作战在 Python 3.8 中typing.Final可以用来标注一个变量是“最终的”不应该被重新赋值。将它与frozenset结合可以形成双重保险from typing import Final # ✅ Final[frozenset] 表示这个变量引用的是一个 frozenset且这个引用本身也不应该被改变 ADMIN_PERMISSIONS: Final[frozenset] frozenset({read, write, delete, admin}) # 下面这行代码会在静态类型检查器如 mypy中报错提示“Cannot assign to final attribute” # ADMIN_PERMISSIONS frozenset({read})这不仅在运行时提供了frozenset的不可变性保障还在编码阶段就通过类型检查器给出了强提示将潜在的错误消灭在萌芽状态。这是一种“防御性编程”的高级实践。6. 工具选型与生态位分析frozenset 在 Python 集合家族中的精准定位6.1 一张表看清所有集合类型的核心差异特性 / 类型listtuplesetfrozensetdictcollections.namedtuple可变性✅ 可变❌ 不可变✅ 可变❌ 不可变✅ 可变❌ 不可变有序性✅ 有序✅ 有序❌ 无序❌ 无序❌ 无序 (Py3.7 保持插入顺序但非语义保证)✅ 有序唯一性❌ 允许重复❌ 允许重复✅ 元素唯一✅ 元素唯一✅ Key 唯一❌ 允许重复可哈希性❌ 不可哈希✅ 可哈希❌ 不可哈希✅ 可哈希❌ 不可哈希✅ 可哈希主要语义有序的、可变的序列有序的、不可变的结构无序的、可变的唯一集合无序的、不可变的唯一集合键值对映射有命名字段的不可变元组典型用途存储需要频繁增删改的序列数据表示一个固定结构的复合值坐标、RGB颜色动态收集、过滤、去重表示一个固定的、逻辑上的集合权限、配置存储键值对表示一个有明确字段名的轻量级数据对象这张表清晰地表明frozenset并非set的一个冗余副本而是set在“不可变性”维度上的必然延伸。它填补了set与tuple之间的一个关键空白当你需要一个无序的、唯一的、不可变的数据结构时frozenset是唯一、且最自然的选择。tuple虽然不可变但它强调顺序set虽然无序唯一但它强调可变。frozenset则完美地结合了后两者的优点同时规避了它们的缺点。6.2 何时该用何时不该用一份清晰的决策指南✅ 强烈推荐使用frozenset的场景定义全局常量如权限集、状态码集合、支持的协议列表等。这是frozenset最经典、最无争议的用武之地。作为字典键或集合元素当你需要一个集合set来作为另一个集合的元素或者作为字典的键时frozenset是唯一合法的选择。需要集合语义的不可变数据当你的业务逻辑天然地将一组东西视为一个“整体概念”并且这个概念一旦形成就不应改变时例如“本次请求所涉及的所有租户ID”frozenset是最贴切的模型。❌ 应该避免使用frozenset的场景需要频繁修改的集合如果你的集合需要在运行时不断地add、remove、update那么frozenset会给你带来无穷无尽的AttributeError。请毫不犹豫地使用set。需要保持插入顺序虽然frozenset的sorted()结果是稳定的但frozenset本身不保证任何顺序。如果你的业务逻辑依赖于元素的插入顺序例如一个“操作历史记录”那么list或collections.OrderedDict才是正解。需要索引或切片访问frozenset不支持my_frozen[0]或my_frozen[1:3]。如果你需要按位置访问元素list或tuple是唯一的选择。⚠️ 需要谨慎权衡的灰色地带小规模、一次性使用的集合如果你只是在一个函数内部临时创建一个集合来做一次性的交集运算然后就丢弃它那么用set和frozenset的性能差异微乎其微。此时选择set可能更符合直觉因为它更“通用”。frozenset的价值更多地体现在其长期的、跨作用域的、作为契约的使用场景中。7. 我的个人体会从“不知道有它”到“离不开它”的转变我第一次真正理解frozenset的价值是在一个上线前的紧急修复中。我们有一个核心的配置模块里面定义了所有支持的 API 版本号它被设计为一个全局的set以便在运行时可以根据配置动态启用或禁用某些版本。然而在一次灰度发布中我们发现部分用户的请求被错误地路由到了一个尚未完全测试的新版本上。经过长达六个小时的排查我们最终发现问题出在一个被遗忘的、用于本地开发调试的 monkey patch 脚本里它偷偷地API_VERSIONS.add(v3-beta)。这个脚本本该只在本地运行却因为一个配置错误被部署到了生产环境。那一刻我深刻地意识到可变性本身就是最大的安全隐患。一个本该是“只读”的配置仅仅因为它的类型是可变的就给了任何代码包括那些本不该存在的代码一个修改它的机会。从那天起我开始系统性地审视项目中所有定义为
与value_counts()原理与选型指南)
