1. 为什么我坚持用 tuple 而不是 list一个十年 Python 开发者的真实选择逻辑你有没有遇到过这样的场景写完一段核心数据处理逻辑测试通过上线运行良好。结果某天同事在另一个模块里悄悄改了你传过去的列表——不是故意的只是他以为那是他自己的副本顺手.append()加了个调试日志或者.pop(0)拿走第一个元素做判断。程序没报错但第二天报表对不上排查三小时最后发现是“共享可变状态”在作祟。这就是我从写第一个 Django 项目起就刻意训练自己优先使用 tuple 的根本原因。它不是什么炫技而是用语言特性筑起的一道静默防线。Python 中的 tuple表面看只是个带括号的 list但它的不可变性immutability带来的价值远超语法糖它是函数式编程思维在 Python 里的落地锚点是多线程环境下的天然安全区更是 API 设计时最诚实的契约声明——“此数据只读请勿修改”。关键词里虽然写着“None”但实际贯穿全文的核心词是不可变性、内存安全、语义明确、性能优势、解包赋值。这五个词不是教科书定义而是我在金融风控系统、物联网设备数据聚合、以及高并发 Web API 开发中一次次被 bug 教会的硬经验。比如在处理用户权限元组(read, write, delete)时如果误用 list下游任意模块都可能把它改成[read, write]而 tuple 会在你第一次尝试修改时就抛出TypeError把问题拦在开发阶段而不是让错误潜伏到生产环境。很多人初学时觉得“不就是不能改吗那我全用 list 多省事”。但真实项目里90% 的数据结构其实根本不需要修改——配置项、状态码映射、枚举值、SQL 查询字段名、API 响应模板……这些本该是常量的东西用 list 就像给消防栓装了个易碎的玻璃盖子看着能用一碰就碎。而 tuple 就是那个铸铁阀门拧紧了就纹丝不动。更关键的是它的不可变性直接映射到内存模型tuple 在创建时就确定了所有元素的引用地址CPython 解释器可以做深度优化比如字符串 intern、小整数缓存复用甚至整个 tuple 对象在内存中可以被安全地共享而不必担心竞态条件。所以这篇教程不会从“tuple 是什么”开始讲起而是直接带你钻进我的日常开发现场看我如何用 tuple 避开那些坑怎么在性能敏感路径上用它提速以及当“不可变”遇上“需要修改”这种看似矛盾的需求时我到底会怎么做——不是绕开规则而是理解规则后聪明地利用它。2. tuple 的本质不是“不能改”而是“改了就不是它了”2.1 从内存 ID 看清不可变性的真相很多教程说“tuple 不可变”然后给你一个t (1, 2, 3); t[0] 99报错的例子就结束了。但这只告诉你“不能做什么”没告诉你“为什么不能”以及“它到底是什么”。真正的理解得从 Python 的对象模型说起。在 CPython 中每个对象都有一个唯一的id()它本质上是该对象在内存中的地址。我们来做一个实验# 创建一个纯不可变元素的 tuple pure_tuple (1, hello, 3.14) print(fpure_tuple id: {id(pure_tuple)}) print(fpure_tuple[0] id: {id(pure_tuple[0])}) print(fpure_tuple[1] id: {id(pure_tuple[1])}) # 创建一个含可变对象的 tuple mixed_tuple (1, [2, 3], world) print(f\nmixed_tuple id: {id(mixed_tuple)}) print(fmixed_tuple[0] id: {id(mixed_tuple[0])}) print(fmixed_tuple[1] id: {id(mixed_tuple[1])}) print(fmixed_tuple[2] id: {id(mixed_tuple[2])})输出类似pure_tuple id: 140234567890123 pure_tuple[0] id: 140234567890456 pure_tuple[1] id: 140234567890789 mixed_tuple id: 140234567891012 mixed_tuple[0] id: 140234567890456 mixed_tuple[1] id: 140234567891345 mixed_tuple[2] id: 140234567891678注意看pure_tuple和mixed_tuple自身的id是唯一的且一旦创建就永不改变。这才是“不可变”的第一层含义——tuple 对象自身的身份identity是固定的。你无法通过任何操作让pure_tuple变成另一个对象你只能创建一个新的 tuple 来替代它。但第二层更微妙mixed_tuple[1]是一个 list它的id也是固定的。当你执行mixed_tuple[1].append(4)时list 对象的id不变内容变了但mixed_tuple这个容器里存的仍然是那个 list 的原始地址。所以mixed_tuple的“结构”没变还是三个元素第二个元素还是指向那个 list但“内容”发生了变化。这正是官方文档说 tuple “immutable” 时的真实含义tuple 容器本身不可变但容器内所引用的对象其可变性由它们自己决定。提示这解释了为什么hash(tuple)是可行的而hash(list)会报错。因为 hash 值必须基于对象的 identity 和内容计算而 tuple 的 identity 和其所有元素的 identity对于不可变元素或其引用对于可变元素都是稳定的。list 则不然它的内容随时可能变hash 值就失去了意义。2.2 为什么“不能 append”反而是最大的安全红利初学者常困惑“既然 tuple 不能增删改那它和 const list 有什么区别”答案藏在 Python 的字节码和内存管理里。我们对比两段代码的执行效率import timeit # 创建 tuple vs list 的耗时100万次 tuple_time timeit.timeit(x (1,2,3,4,5), number1000000) list_time timeit.timeit(x [1,2,3,4,5], number1000000) print(fTuple creation: {tuple_time:.4f}s) print(fList creation: {list_time:.4f}s) # 典型输出Tuple creation: 0.0421s | List creation: 0.0873s # 更关键的是内存占用 import sys t (1, 2, 3, 4, 5) l [1, 2, 3, 4, 5] print(fTuple size: {sys.getsizeof(t)} bytes) print(fList size: {sys.getsizeof(l)} bytes) # 典型输出Tuple size: 80 bytes | List size: 120 bytes差距来自底层实现tuple 是紧凑的连续内存块只存储元素指针list 则需要额外的内存来维护动态数组的容量capacity、长度length和指向缓冲区的指针。这个设计差异在高频调用的场景下会被放大。比如在 Pandas 的内部大量使用 tuple 作为索引键Index keys就是因为它的哈希计算快、内存占用小、且线程安全——多个线程同时读取同一个 tuple完全不需要加锁。所以“不能 append”不是缺陷而是 CPython 为 tuple 做的激进优化的前提。它牺牲了灵活性换来了确定性你永远知道一个 tuple 创建后它的内存布局、大小、哈希值都是恒定的。这在构建缓存键、数据库主键、分布式任务 ID 时是无可替代的优势。2.3 当“不可变”遇上“需要修改”我的三步应对法现实开发中总会遇到“这个 tuple 里有个值要改”的需求。比如一个表示坐标点的 tuple(x, y, z)现在需要把z更新为新值。新手可能想“啊tuple 不能改那我只好换成 list”这是典型的思维惯性。我的做法是第一步承认需求但拒绝破坏契约不改 tuple 本身而是创建一个新 tuple。这是最符合 Python 哲学的方式point (10, 20, 30) # 想把 z 改成 40没问题创建新 tuple new_point (point[0], point[1], 40) # (10, 20, 40) # 或者用切片 解包更优雅 new_point (*point[:2], 40) # (10, 20, 40)第二步用 namedtuple 或 dataclass 封装业务语义如果这个“点”在你的系统里频繁出现那就该升级为有名字的结构from collections import namedtuple Point namedtuple(Point, [x, y, z]) p Point(10, 20, 30) # 生成新实例保持不可变性 p_updated p._replace(z40) # Point(x10, y20, z40)第三步当性能是唯一目标时才考虑“伪可变”技巧极少数场景如实时音视频帧处理创建新 tuple 的开销无法接受。这时我会用混合 tuple# 创建一个含 list 的 tuplelist 内部可变 frame_data (timestamp, [pixel_values], metadata) # 修改 pixel_values 不影响 frame_data 的 id frame_data[1].extend(new_pixels) # 安全但必须加清晰注释并确保所有协作者都理解这个约定。这属于高级技巧95% 的场景用前两步足矣。注意永远不要为了“看起来能改”而滥用混合 tuple。我见过团队用config (host, [port], db)结果不同模块往[port]里塞值最终 config 行为完全不可预测。不可变性最大的价值是让代码行为可推理、可预测。3. tuple 的实战操作从初始化到高级技巧的完整链路3.1 初始化括号不是必须的逗号才是灵魂几乎所有 Python 教程都告诉你“tuple 用()创建”这没错但不完整。真正定义 tuple 的是逗号不是括号。括号很多时候只是分组符号。# 这些全是合法的 tuple 创建方式 t1 (1, 2, 3) # 最常见 t2 1, 2, 3 # 没有括号依然是 tuple t3 (1,) # 单元素 tuple必须加逗号 t4 1, # 同样合法等价于 t3 t5 () # 空 tuple只有括号 # 验证它们的类型 print(type(t1), type(t2), type(t3), type(t4), type(t5)) # class tuple class tuple class tuple class tuple class tuple # 错误示范没有逗号的单元素 t_wrong (1) # 这是 int不是 tuple print(type(t_wrong)) # class int这个细节在函数返回值和解包时至关重要。比如一个函数想返回两个值你写return a, bPython 自动打包成 tuple调用方写x, y func()Python 自动解包。整个过程括号都隐身了但逗号是核心。实操心得在代码审查中我只要看到(value)就会标记为潜在 bug因为它很可能本意是创建单元素 tuple却意外创建了普通值。强制要求单元素 tuple 必须写成(value,)这是团队规范。3.2 索引与切片比 list 更“纯粹”的序列操作tuple 的索引和切片语法和 list 完全一致但正因为它的不可变性这些操作更值得信赖。data (a, b, c, d, e) # 正向索引 print(data[0]) # a print(data[2]) # c # 反向索引负数 print(data[-1]) # e最后一个 print(data[-3]) # c倒数第三个 # 切片start:stop:step print(data[1:4]) # (b, c, d) — stop 索引不包含 print(data[:3]) # (a, b, c) — 从开头到索引3不含 print(data[2:]) # (c, d, e) — 从索引2到结尾 print(data[::2]) # (a, c, e) — 步长为2 print(data[::-1]) # (e, d, c, b, a) — 反转关键区别在于tuple 的切片总是返回一个新的 tuple而 list 的切片返回新的 list。这听起来 trivial但在嵌套数据结构中意义重大# 一个包含 tuple 的 list matrix [(1, 2), (3, 4), (5, 6)] # 取第一行是个 tuple row matrix[0] # (1, 2)类型是 tuple # 取第一行的第一个元素 first_elem matrix[0][0] # 1 # 如果 matrix 是 list of listrow 就是 list可能被意外修改 # 但这里是 tuplerow 的内容绝对安全3.3 连接与重复*创建新 tuple 的两种基本方式tuple 的和*操作符是创建新 tuple 最常用的手法。它们不修改原 tuple而是生成全新的对象。t1 (1, 2) t2 (3, 4) # 连接生成新 tuple t3 t1 t2 print(t3) # (1, 2, 3, 4) print(id(t1), id(t2), id(t3)) # 三个不同的 id # 重复复制自身 n 次 t4 t1 * 3 print(t4) # (1, 2, 1, 2, 1, 2) # 混合使用 t5 (t1 t2) * 2 print(t5) # (1, 2, 3, 4, 1, 2, 3, 4)这里有个重要陷阱和*要求操作数类型一致。tuple list会报错这其实是好事——它强迫你显式转换避免隐式类型混淆t (1, 2) l [3, 4] # 错误类型不匹配 # t l # TypeError! # 正确显式转换意图清晰 t_extended t tuple(l) # (1, 2, 3, 4) l_extended list(t) l # [1, 2, 3, 4]注意*操作符对包含可变对象的 tuple 有特殊效果t ([1], [2]) t_doubled t * 2 # ([1], [2], [1], [2]) t_doubled[0].append(99) # 修改第一个 list print(t_doubled) # ([1, 99], [2], [1, 99], [2])因为*是浅拷贝它复制的是 list 的引用不是 list 本身。所以修改任何一个副本里的 list会影响所有引用它的位置。这是“不可变容器”和“可变内容”的经典交织案例。3.4 成员检查与遍历安全、高效的数据访问由于 tuple 不支持修改所有只读操作都天然安全且通常比 list 更快。t (apple, banana, cherry) # in 操作符O(n) 时间但非常直观 print(banana in t) # True print(date in t) # False # for 循环遍历和 list 一样简洁 for fruit in t: print(fruit.upper()) # 使用 enumerate 获取索引和值 for i, fruit in enumerate(t): print(f{i}: {fruit}) # 解包遍历最 Pythonic fruits [(red, apple), (yellow, banana), (red, cherry)] for color, name in fruits: # 自动解包每个 tuple print(f{name} is {color})in操作符在 tuple 上的性能取决于元素数量。对于小 tuple 100 个元素它和 list 差不多但对于大集合应该用set。不过tuple 的in有一个独特优势它保证了顺序。如果你的查找逻辑依赖于元素出现的先后顺序比如状态机的合法转移序列tuple 是比 set 更合适的选择。4. tuple 的内置函数与方法哪些能用哪些不能用为什么4.1 为什么 tuple 没有 append()、remove()——设计哲学的体现这是初学者最常问的问题。答案很简单因为这些方法会改变对象的状态而 tuple 的设计目标就是“状态恒定”。t (1, 2, 3) # 这些方法在 tuple 上不存在 # t.append(4) # AttributeError! # t.remove(2) # AttributeError! # t.pop() # AttributeError! # t.insert(0, 0) # AttributeError! # 但这些只读方法/函数是存在的 print(len(t)) # 3 print(t.count(2)) # 1 print(t.index(2)) # 1len(),count(),index()这些方法之所以存在是因为它们不改变 tuple 本身只读取其信息。len()返回元素个数count()统计某个值出现次数index()查找第一个匹配项的位置——所有这些都不需要修改 tuple 的内存布局。实操心得当你在 IDE 里敲t.然后按 Tab看到的可用方法列表就是 tuple 的“能力边界”。这个边界不是限制而是承诺IDE 和你都知道调用这些方法tuple 的内容绝不会变。这极大降低了代码的认知负荷。4.2 关键内置函数详解从基础到进阶len(),count(),index()这三个是最常用的 tuple 方法用法和 list 相同但语义更纯粹t (1, 2, 2, 3, 2, 4) print(len(t)) # 6 print(t.count(2)) # 3 —— 出现三次 print(t.index(2)) # 1 —— 第一次出现在索引1 print(t.index(2, 2)) # 2 —— 从索引2开始找第一次出现在索引2index()的start参数很实用比如你想跳过第一个匹配项找第二个。min(),max(),sum(),sorted()这些函数对 tuple 的支持体现了 Python 的鸭子类型哲学只要对象支持所需的操作如比较、加法函数就能工作。nums (5, 1, 9, 3) print(min(nums)) # 1 print(max(nums)) # 9 print(sum(nums)) # 18 # sorted() 返回 list不是 tuple这是重点 sorted_nums sorted(nums) # [1, 3, 5, 9] print(type(sorted_nums)) # class list # 如果你想要 tuple必须显式转换 sorted_tuple tuple(sorted(nums)) # (1, 3, 5, 9)sorted()返回 list 是有意为之的设计。因为排序后的结果通常是用来进一步处理的比如遍历、修改而 list 更适合后续操作。如果你明确需要 tupletuple(sorted(...))是标准写法。any(),all(),tuple()这三个函数展示了 tuple 在逻辑判断和类型转换中的角色# any() 和 all()对元素进行布尔判断 empty_t () single_t (0,) # 注意0 是 Falsy truthy_t (1, 2, 3) print(any(empty_t)) # False —— 空 tuple 是 False print(any(single_t)) # False —— 0 是 False print(any(truthy_t)) # True —— 所有元素都是 True print(all(truthy_t)) # True print(all((1, 2, 0))) # False —— 0 是 False # tuple()类型转换的瑞士军刀 print(tuple([1, 2, 3])) # (1, 2, 3) print(tuple(abc)) # (a, b, c) print(tuple(range(3))) # (0, 1, 2) print(tuple({1, 2, 3})) # (1, 2, 3) —— 顺序不确定tuple()转换时要注意从set或dict转换顺序是不确定的因为它们本身无序。如果顺序很重要必须先排序或用其他方式保证。4.3hash()tuple 的终极认证也是它能做字典键的原因hash()函数是理解 tuple 为何能用作字典键、集合元素的关键。t1 (1, 2, 3) t2 (1, 2, 3) t3 (1, 2, 4) print(hash(t1)) # 例如-3550055125485641917 print(hash(t2)) # 和 t1 相同 print(hash(t3)) # 不同 # 因为 hash 值相同t1 和 t2 可以互换作为 dict key d {t1: value1} print(d[t2]) # value1 # 但 list 不行 # l [1, 2, 3] # hash(l) # TypeError! list is unhashablehash()的存在意味着 tuple 的内容及其所有元素的内容在创建后是稳定不变的。这是 Python 字典和集合高效查找O(1) 平均时间复杂度的基础。当你用 tuple 作为 cache key 时hash()的稳定性保证了缓存命中率。注意只有所有元素都可哈希的 tuple 才是可哈希的。([1], 2)就不行因为 list 不可哈希。hash(([1], 2))会报错。5. 高级技巧与避坑指南十年踩过的坑都在这里了5.1 解包赋值Unpackingtuple 最惊艳的用法解包是 Python 中最优雅的语法糖之一而 tuple 是它的最佳载体。# 基础解包 coordinates (10, 20, 30) x, y, z coordinates # 自动分配 print(x, y, z) # 10 20 30 # 忽略某些值用 _ 作为占位符 _, _, z_only coordinates print(z_only) # 30 # 星号解包Python 3 first, *middle, last (1, 2, 3, 4, 5) print(first) # 1 print(middle) # [2, 3, 4] —— 注意middle 是 list print(last) # 5 # 解包函数返回值最常用场景 def get_user_info(): return (Alice, 30, Engineer) name, age, role get_user_info() # 一行解包三个值 print(f{name} is {age} years old and works as {role})星号解包 (*) 的妙处在于它能处理不定长数据。middle总是 list这很合理——因为 tuple 是不可变的而你需要一个可变的容器来存放“中间部分”。实操心得在处理 CSV 行、API 响应、数据库记录时我几乎总是用解包。比如user_id, username, email, *roles row这样即使 roles 字段数量变化代码也不用改。这是让代码适应数据变化而不是让数据适应代码。5.2 嵌套 tuple 与多维解包处理复杂数据结构现实中的数据很少是一维的。tuple 的嵌套能力让它成为结构化数据的理想载体。# 一个二维坐标列表但用 tuple 表示每个点 points ((0, 0), (1, 1), (2, 4), (3, 9)) # 逐个解包 for x, y in points: # 自动解包每个子 tuple print(f({x}, {y}) - y x²? {y x*x}) # 更复杂的嵌套(姓名, (城市, 国家), 年龄) person (Bob, (Shanghai, China), 25) name, (city, country), age person # 多层解包 print(f{name} lives in {city}, {country} and is {age}) # 带星号的嵌套解包 data (report_2023, Q1, sales, 10000, USD, details, more, info) filename, quarter, category, *values, currency, *metadata data print(fFile: {filename}, Quarter: {quarter}, Values: {values}, Currency: {currency}) # File: report_2023, Quarter: Q1, Values: [sales, 10000], Currency: USD嵌套解包让代码自文档化。变量名直接表达了数据的语义比用data[0],data[1]清晰无数倍。5.3 常见陷阱与排查技巧那些让我加班到凌晨的 Bug陷阱 1单元素 tuple 的逗号缺失# 错误以为创建了 tuple其实是 int t (5) print(type(t)) # class int # 正确必须加逗号 t (5,) print(type(t)) # class tuple # 在函数参数中尤其危险 def process_tuple(t): print(fLength: {len(t)}, Type: {type(t)}) process_tuple((1, 2, 3)) # Length: 3, Type: class tuple process_tuple((5)) # Length: 1, Type: class int —— BUG!排查技巧在函数入口加类型检查或用isinstance(t, tuple)断言。陷阱 2可变对象嵌套导致的“假不可变”# 看似安全的 tuple config (prod, [db_host], cache_enabled) # 但下游模块可能这样改 config[1].append(backup_db) # 悄悄修改了 # 结果config 现在是 (prod, [db_host, backup_db], cache_enabled) # 而所有持有 config 引用的地方都看到了这个变化解决方案用tuple()包裹不可变对象config (prod, tuple([db_host]), cache_enabled)用namedtuple或dataclass(frozenTrue)在关键函数中做深拷贝safe_config tuple(item[:] if isinstance(item, list) else item for item in config)陷阱 3sorted()返回 list 的意外scores (95, 87, 92, 88) sorted_scores sorted(scores) # 返回 list [87, 88, 92, 95] # 如果你期望它是 tuple后续 .index() 等操作会失败 # sorted_scores.index(92) # OKlist 有 index() # but if you do: sorted_scores tuple(sorted(scores)), then its safe # 更隐蔽的坑传递给期望 tuple 的函数 def analyze_data(data_tuple): return sum(data_tuple) / len(data_tuple) # analyze_data(sorted_scores) # Error! sorted_scores is list analyze_data(tuple(sorted_scores)) # Correct排查技巧在函数文档字符串中明确写出参数类型用类型提示def analyze_data(data_tuple: tuple) - float:并配合 mypy 静态检查。陷阱 4性能误区——不是所有地方 tuple 都更快# 创建小 tuple 很快但创建大 tuple 可能比 list 慢 import timeit # 小数据tuple 快 small_t timeit.timeit(tuple(range(10)), number100000) small_l timeit.timeit(list(range(10)), number100000) print(fSmall: tuple {small_t:.4f}s, list {small_l:.4f}s) # 大数据list 的预分配机制可能更优 big_t timeit.timeit(tuple(range(10000)), number10000) big_l timeit.timeit(list(range(10000)), number10000) print(fBig: tuple {big_t:.4f}s, list {big_l:.4f}s) # 在我的机器上big_t 可能略慢于 big_l真相tuple 的性能优势主要在创建后的使用阶段哈希、比较、内存占用而不是创建过程本身。对于需要大量追加的场景先用 list 构建再tuple()转换是最佳实践。6. 实战项目用 tuple 重构一个真实的配置管理模块6.1 项目背景一个混乱的旧配置系统我接手的一个老项目配置是用全局 dict 存的CONFIG { database: {host: localhost, port: 5432}, cache: {enabled: True, ttl: 300}, features: [auth, logging, metrics] }问题层出不穷不同模块随意修改CONFIG[features].append(new_feature)导致功能开关状态不一致测试时修改了CONFIG[database][host]影响了其他测试用例最糟的是有人写了CONFIG {}清空了所有配置。6.2 重构方案用 tuple namedtuple 构建不可变配置树from collections import namedtuple from typing import NamedTuple, Tuple, List, Dict, Any # 定义配置的结构化类型 class DatabaseConfig(NamedTuple): host: str port: int database: str class CacheConfig(NamedTuple): enabled: bool ttl: int class FeatureFlags(NamedTuple): features: Tuple[str, ...] # ... 表示可变长度 tuple # 主配置也是一个 namedtuple保证整体不可变 class AppConfig(NamedTuple): database: DatabaseConfig cache: CacheConfig features: FeatureFlags # 创建不可变配置实例 DEFAULT_CONFIG AppConfig( databaseDatabaseConfig(hostlocalhost, port5432, databasemyapp), cacheCacheConfig(enabledTrue, ttl300), featuresFeatureFlags(features(auth, logging, metrics)) ) # 使用示例 def connect_to_db(config: AppConfig) - str: # 安全config.database.host 永远不会被意外修改 return fpostgresql://{config.database.host}:{config.database.port}/{config.database.database} def is_feature_enabled(config: AppConfig, feature: str) - bool: # 安全features 是 tuplein 操作是 O(n)但内容不会变 return feature in config.features.features # 如果需要“更新”配置创建新实例 def enable_feature(config: AppConfig, feature: str) - AppConfig: # 创建新的 features tuple new_features config.features.features (feature,) new_features_flags FeatureFlags(featuresnew_features) return AppConfig( databaseconfig.database, cacheconfig.cache, featuresnew_features_flags ) # 测试 original DEFAULT_CONFIG updated enable_feature(original, analytics) print(original.features.features) # (auth, logging, metrics) print(updated.features.features) # (auth, logging, metrics, analytics) print(original is updated) # False —— 完全不同的对象6.3 重构后的收益与经验总结Bug 归零配置被意外修改的 bug 100% 消失。所有修改都必须显式创建新实例代码审查时一眼就能看到。性能提升配置加载后hash(AppConfig)可用于快速缓存in操作在 features 上稳定高效。可测试性增强每个测试用例可以安全地创建自己的AppConfig实例互不影响。文档即代码NamedTuple的字段名和类型提示本身就是最准确的配置文档。我个人在实际使用中发现这种模式在微服务配置、机器学习 pipeline 的超参数管理