学 Python最绕不开的一个坎就是函数。很多新手对def这个词一开始是发怵的总觉得函数就是把代码“包起来”而已但真到自己写的时候又不知道从哪里下手。函数是整个编程思维从“按顺序写代码”升级到“设计代码结构”的关键转折点能不能跨过这个坎基本决定了你后面写出来的代码是能维护的作品还是一堆只能跑一次的草稿。这篇博文我会把 Python 函数从定义、参数、返回值到作用域一层层拆开讲每一部分都会解释“为什么这门语言要这样设计”同时把我这些年实际写代码踩过的坑、带新人时反复强调的点都放进去。整篇内容适合两类人看一类是完全零基础、刚学会if和for的初学者另一类是懂点语法但总感觉代码写不“干净”的自学者。看完你至少能明白函数不是语法负担而是你写出可复用代码的第一把钥匙。1. 函数到底是什么先解决“为什么要写函数”1.1 函数本质上是把一段逻辑打包成“可命名的动作”我们可以把函数想象成一台小型机器。这台机器有输入口和输出口你往里面扔原材料它按照内部流程加工然后把成品吐出来。比如你要算 30 个长方形的面积总不能把宽 * 高这种算式手写 30 遍而是应该把“计算面积”这个动作打包成一个函数每次只需要告诉它“宽是多少高是多少”它就把面积返回给你。更直白一点函数就是“给一段逻辑起个名字”。这个名字代表了一整套操作步骤以后每当你想执行这套步骤只需要喊名字即可。这跟做菜完全一样菜谱上写“红烧肉”三个字背后是一整套加料、炖煮的流程你不需要每次做菜都把流程重新背一遍只需要确定今天要不要做红烧肉。从语言设计的角度看函数是“过程抽象”的体现。你可以隐藏底层的实现细节只保留一个干净的接口。这样带来的第一个好处就是复用同样的逻辑写一次用很多次。第二个好处是隔离每一段逻辑被单独包裹互相不干扰调试的时候能精准定位问题。第三个好处是可读性代码从“一堆散装计算步骤”变成“先准备食材再烹饪最后装盘”这种清晰的动作序列。1.2 新手学函数最容易卡住的点不是语法是封装思维我带过不少刚入门的朋友发现他们学函数时最典型的问题是听课时觉得很简单def加缩进加return就完事但真到了需要自己设计函数时脑子一片空白。原因不是语法没记住而是他们还没建立“封装思维”。我给你讲一个真实场景。有位同学发来的练习是一段画五角星的代码画了三个不同位置、不同大小的五角星。他的做法是把 turtle 那一套画五角星的指令复制粘贴了三遍只是改了坐标和边长。我说“你用函数试试”他愣住了因为他发现自己不知道“哪些代码应该放进函数哪些应该留在外面”。这个问题的本质是他还不习惯把代码按“动作”切块。画五角星的“动作”包含抬笔、移动到指定位置、落笔、循环五次画边、旋转。如果要把这三个尺寸的五角星都画出来最自然的函数设计就是draw_star(x, y, size)把坐标和大小当作参数传进去。这样画三个五角星的核心代码就只剩下三行调用。当你能从“我需要画星星”而不是“我需要一行行写海龟指令”的角度思考时函数思维就算初步建立了。这也是为什么我经常和初学者说学函数先别急着背def的各种写法先练习“把一段重复动作提取成一个动作名”这个动作名就是未来的函数名。1.3 调用函数时Python 到底做了什么理解函数运行机制能有效减少很多玄学困惑。当你调用一个函数Python 会做这样几件事先根据函数名去当前命名空间查找这个函数对象找到之后暂停当前代码的执行流带着传入的参数进入到函数体内部进入函数后Python 会为这次调用创建一个全新的、独立的局部命名空间所有在函数内部赋值的变量都存在这个空间里接着按顺序执行函数体里的代码直到遇到return或者函数体结束最后把返回值交还给调用方同时销毁这个局部命名空间。这个“创建独立空间、用完就销毁”的设计就是后面作用域概念的源头。你可以把函数调用理解成去一家餐厅点餐你坐下暂停当前执行服务员把菜单给你传入参数后厨在自己的厨房里忙活函数体内独立的局部变量最后把菜端到你桌上返回结果然后厨房进行收拾局部空间销毁。很多初学者会有“函数和外部变量是不是共享的”这种困惑。实际上默认情况下函数内部的变量和函数外部的变量是两个世界除了你显式传入的参数和拿到的返回值它们之间不会乱串。搞清楚这一点后面作用域那一章会轻松很多。2. 函数定义def 背后的一套完整规则2.1 最简定义与调用的完整流程Python 定义一个函数语法非常简洁def greet(name): 向指定的名字问好 message f你好{name} return message result greet(小明) print(result) # 输出你好小明def是关键字告诉 Python“我要开始定义函数了”greet是函数名后面跟一对圆括号括号里写参数列表行尾的冒号表示函数体的开始。比这更关键的是下一行的缩进Python 用缩进来表达代码块的归属函数体所有代码必须保持同样的缩进级别通常约定是 4 个空格。这个设计和其他语言用花括号{}包裹代码块的做法很不一样。很多人刚接触时觉得缩进很“烦”但用久了会发现它其实强制你把代码写整齐。C 或 Java 里可以写出花括号错乱、缩进混乱的代码但在 Python 里缩进错了程序直接报错根本跑不起来。函数定义完成后函数体并不会立刻执行。只有当你写出greet(小明)这种调用语句时函数才会真正运行。这就像菜谱摆在那里你不打开灶台菜谱里的步骤永远只是文字一旦你决定“按这个菜谱做菜”那些步骤才开始变成现实。2.2 函数命名与文档字符串容易被忽视的“接口设计”函数名是给调用者看的相当于接口的门面。Python 社区对函数命名有约定全小写多个单词用下划线分隔比如calculate_average、send_email。函数名最好是动词或动词短语因为函数是一个动作叫get_user_name就比name清晰得多。我见过不少代码里出现def a()、def fun1()这种命名这类名字放到项目里就是给自己埋雷三个月后回来看代码根本想不起来a()是干什么的。除了名字还有一个容易忽略但极其重要的部分文档字符串也就是函数体第一行的三引号字符串。文档字符串是给函数写“说明书”说明这个函数是干什么的、参数是什么、返回值是什么。它会被 Python 自动存储在函数的__doc__属性里很多现代编辑器也能直接读取并在鼠标悬停时展示。def calc_price(unit_price, count): 计算商品总价。 参数: unit_price: 商品单价 count: 商品数量 返回: 总价单价乘以数量 return unit_price * count很多初学者觉得写文档字符串是在浪费时间反正代码自己能看懂。但你试试半年后再打开自己写过的脚本或者把代码交给别人维护就会明白“一句好的注释胜过十行代码”的道理。写不写文档字符串是“能跑”和“可用”之间的分水岭。2.3 缩进与代码块Python 的“强制整洁”Python 对缩进的要求非常严格同一个代码块里的缩进必须一致。最常见的坑是 Tab 和空格混用。看起来没问题但解释器会在运行时报IndentationError而且报错位置往往让人摸不着头脑。我自己的经验是所有代码编辑器都改成“按 Tab 键时插入 4 个空格”然后用“显示空白字符”功能辅助检查。VSCode 里可以在设置里搜insertSpaces开启或者直接点击右下角的Tab 大小进行配置。哪怕你用的是记事本也要养成只用空格、不用真实 Tab 字符的习惯。缩进也承担了“界定范围”的作用。同样是写在一个def下面的代码缩进级别相同的就是函数体的同层语句嵌套一个if内部的代码要再缩进一级。这种“缩进即层级”的规则让 Python 代码的视觉结构和逻辑结构高度一致读起来就像在看文章的章节层级非常直观。3. 参数详解四种传参方式背后的设计哲学3.1 位置参数顺序就是调用契约位置参数是最基础的传参方式调用时传入的值按顺序一一对应到函数定义里的参数名。def make_rectangle(width, height): return width * height area make_rectangle(5, 3) print(area) # 输出155传给width3传给height。这种传参方式简单直接但它的代价是调用方必须记住参数的顺序。一旦调用方写成了make_rectangle(3, 5)如果恰好函数对宽度和高度有不同语义结果就错了。所以设计函数时位置参数的顺序一定要符合直觉把重要、常用的参数往前放。我在代码评审时看过有人写出def division(divisor, dividend)这种定义就是先写除数再写被除数和平时说的“被除数除以除数”顺序相反结果调用的人经常传反。这就是位置顺序设计不合理导致的真实事故。位置参数适合参数少、顺序自然、语义清晰的场景参数一多就该考虑用下面说到的关键字参数。3.2 关键字参数让代码自己解释自己关键字参数在调用时用参数名值的形式传参不再依赖位置。def book_ticket(city, date, seat_type): print(f已预订{city}的{date} {seat_type}座票) book_ticket(city上海, date2025-12-01, seat_type靠窗)这样写出来的调用代码几乎不需要额外注释一眼就能看出“这是给上海、某日期、靠窗座位的票”。关键字参数的另一个好处是你不需要记住参数的顺序只要参数名写对就行。这在函数参数非常多四五个以上的时候尤其好用比如 Python 的matplotlib.pyplot.plot()里面几十个参数没人会全按位置传。关键字参数和位置参数可以混用但有个铁律位置参数必须在关键字参数之前出现。book_ticket(上海, date2025-12-01, seat_type靠窗) # 正确 book_ticket(city上海, 2025-12-01, seat_type靠窗) # 报错第二条会报SyntaxError因为一旦开始用关键字传参位置就必须从前面全部按位置传完不能中间混着来。这个规则背后的原因很简单Python 需要从逻辑上避免歧义。如果允许“前面关键字、后面位置”解释器就没法判断后面的位置参数到底对应哪个参数了。3.3 默认参数灵活性与安全性的平衡默认参数是在函数定义时就给参数指定一个默认值调用时如果没传这个参数就使用默认值。def send_email(to, subject无主题, ccNone): print(f收件人{to}主题{subject}抄送{cc})这样既保证了函数的灵活性也保证了调用方的最低输入成本。默认参数在通讯类、配置类的接口设计中非常常见。但这里面藏着一个 Python 新手最容易踩的大坑默认参数在函数定义时只会被计算一次而不是每次调用都被重新计算。def add_item(item, container[]): container.append(item) return container cart1 add_item(苹果) cart2 add_item(香蕉) print(cart1) # [苹果, 香蕉]而不是 [苹果]问题出在container[]这个空列表在函数定义那一刻就被创建了之后每次调用如果不传container用的都是同一个列表对象。cart2调用时共享了cart1已经追加过元素的列表结果两个购物车串在一起了。这是 Python 官方文档里明确警告过的陷阱。正确的做法是默认值用不可变类型或者以None作为哨兵值函数内部再创建新对象def add_item(item, containerNone): if container is None: container [] container.append(item) return container这样每次调用如果没有传入列表就会创建全新的列表互不干扰。总结成一句话默认参数只适合字符串、数字、元组这些不可变对象千万不要用列表、字典这类可变对象。3.4 可变参数*args和**kwargs的取舍有时函数的参数数量不固定比如写一个求总价的函数希望传入任意数量的价格这时候就需要可变参数。*args会接收任意多个位置参数并把它们打包成一个元组**kwargs会接收任意多个关键字参数并把它们打包成一个字典。def calc_total(*prices): return sum(prices) print(calc_total(10, 20, 30)) # 60 print(calc_total(5, 7)) # 12 def show_info(**info): for key, value in info.items(): print(f{key}: {value}) show_info(name张三, age18, city北京) # 输出 # name: 张三 # age: 18 # city: 北京注意args和kwargs这两个名字只是约定俗成你可以换成任何名字比如*numbers它的含义是把多个位置参数收集成一个元组。真正起作用的是那个星号*和双星号**。这里我给一个实用建议可变参数不是万金油不要因为“看起来高级”而滥用。接受任意参数意味着你的函数接口失去了约束调用传错参数时不会及时报错排查问题会更难。合适的场景是装饰器、日志封装、事件回调等确实需要透传任意参数的地方。在普通业务代码里我还是推荐把参数写明确哪怕多写几个默认参数也比**kwargs把一切吞掉好。顺便说一句如果你学过 JavaScript会发现...rest剩余参数和 Python 的*args思路很像它们都解决了“不定数量参数”这个问题也都是收集成一整个序列。理念相通只是语法不同。4. 返回值return 的细节与常见误解4.1 return 的三种主要作用return是函数体内最关键的语句之一它有三个作用返回计算结果、提前结束函数、在没有返回值时返回None。写一个检查数字的示例def check_number(n): if n 0: return 负数 if n 0: return 零 return 正数这里函数执行到第一个满足条件的return时会立刻把字符串返回给调用方后面的代码不再执行。这种“早返回”风格写出来的代码比用一堆if-else嵌套要清晰得多也容易减少缩进层级。我平时写代码时很推荐“卫语句”风格在函数开头依次检查各种边界条件一旦条件不满足就用return退出主流程留到后面干干净净地写。这样代码读起来像在安检一道关不过直接回头过了就一路畅行。4.2 返回多个值其实是“元组打包”和解包很多其他语言要返回多个结果需要定义结构体或类。Python 中可以直接在一个return语句里用逗号分隔多个值def get_user_info(): name 张三 age 25 city 北京 return name, age, city # 实际上返回了一个元组 (name, age, city) info get_user_info() print(info) # (张三, 25, 北京) print(type(info)) # class tuple调用方可以用等号一次性解包name, age, city get_user_info()这就是 Python 的元组解包魔法。你不需要去构造一个复杂的类函数自然就返回了“一包结果”。如果某个返回的字段你不想用可以用下划线_来占位name, _, city get_user_info()这种做法在遍历字典或返回较多字段时非常常见。不过我也要提醒一句返回太多字段时调用方容易搞混顺序所以一般建议返回值不要超过三个。如果确实需要返回五六项数据定义一个NamedTuple或数据类会比散装元组好维护得多。4.3 没有 return 的函数返回的其实是 NonePython 中每个函数都默认返回None即使你没写return函数跑到末尾也会自动“返回 None”。这是新手最容易被坑的地方之一你打印一个没有return的函数会看到输出None。def say_hello(name): print(f你好{name}) result say_hello(张三) print(result) # 你好张三\n None这里要注意的是say_hello把问候语打印到屏幕上了但没有给调用方任何返回值。如果你打算写“会返回消息”的函数就必须显式写return并且在函数体内避免额外打印。这也是函数设计上最经典的分工问题有的函数负责“干活并返回结果”有的函数负责“干活并输出展示”尽量不要让一个函数同时承担两件事否则测试和复用都会很别扭。另外特别注意None的布尔值。在条件判断中None被视为假值所以如果你写了下面这种代码result get_data() if result: print(有数据) else: print(没有数据)当函数没有返回值时result是None判断结果会走else分支可能掩盖真正的错误原因。排查时建议显式判断is None而不是依赖真假值。4.4 布尔返回值的正确设计bool 类型函数的细节在开发中经常要写返回布尔值的函数比如判断一个数是否为偶数、一个用户是否有权限。这类函数的命名通常以is_、has_、can_开头返回值是True或False。def is_even(n): return n % 2 0 print(is_even(4)) # True print(is_even(7)) # False这个例子也顺便说明 Python 里bool是int的子类True等价于1False等价于0。你可以直接把布尔值当作数字运算比如sum(True, False, True)结果是2但这种写法可读性极差正常情况下不建议用。写布尔返回值函数时一个常见错误是写了多余的ifdef is_even(n): if n % 2 0: return True else: return False看起来没问题但完全没必要。n % 2 0本身就是一个布尔表达式直接return n % 2 0就够了。写多了会发现很多分支判断在布尔函数里都是多余的这也是代码简洁性训练的一个好切入。4.5 返回值的几条设计建议我自己在写函数时会遵循几条朴素但有效的原则。第一函数最好只做一件事返回的结果要有清晰语义。如果一个函数既查数据库、又算价格、还发通知那它返回什么都会让人困惑。第二遇到错误时不要用return -1或return None这类魔法值来表示失败更好的做法是抛出异常让调用方明确感知到错误第三设计返回值时想清楚调用方要怎么用而不是“能返回什么就返回什么”。比如你要设计一个搜索函数如果没搜到结果返回空列表[]通常比返回None好用因为调用方可以直接遍历空列表而不用先判断None。这些细节看似微小但决定了代码在别人手里的体验。5. 作用域变量从哪里来、到哪里去5.1 LEGB 规则一次搞懂变量查找顺序作用域决定了一个变量在代码的哪些区域可以被访问。Python 查找变量时遵循一个称为 LEGB 的顺序先找 Local局部作用域再找 Enclosing外层嵌套函数的局部作用域再找 Global全局作用域最后找 Built-in内建作用域。x 全局变量 def outer(): x 外层变量 def inner(): x 内层变量 print(x) # 内层变量 inner() outer()当inner内部访问x时Python 会先从inner自己的局部空间找找到了直接用不再往上找。如果inner里没有x它就会去outer的空间找再没有就去全局找到最后才去 Python 内建作用域找比如len、print这些内建函数。理解这个顺序对于排查询变量 “为什么不是我期望的值” 的 bug 很有用。现实里很多诡异的错误都是因为函数内部或外部有同名变量导致 Python 找错了“那个 x”。避免的方法是函数内部和外部尽量避免同名全局变量也尽量少用。5.2 global 与 nonlocal什么时候才需要它们默认情况下在函数内部给一个变量赋值这个变量会成为局部变量函数执行完就销毁不会影响外部同名变量。但如果你在函数内部拿到的值总是和预期不符甚至报错往往就涉及global和nonlocal。只需要在函数内部以赋值方式修改全局变量时用global声明count 0 def increment(): global count count 1 increment() print(count) # 1如果不写global countPython 会把count当作新的局部变量还会因为count 1在赋值前就读取count而直接报UnboundLocalError。这个报错让很多人一头雾水其实它的逻辑是函数内部只要出现了对某个名字的赋值Python 就默认它是局部变量哪怕前面只是读了一下它也按局部来处理。nonlocal则用于嵌套函数中修改外层函数的局部变量def outer(): num 10 def inner(): nonlocal num num 20 inner() print(num) # 20 outer()这里如果不写nonlocal num内层函数num 20只会创建自己的局部变量外层num不会被改变。说实话我在业务代码里很少主动用globalnonlocal也只在闭包相关的场景出现。全局状态会让函数失去独立性测试和并发都比较麻烦。能用参数传递和返回值解决的问题就不要用全局变量去“开外挂”。5.3 闭包作用域带来的经典机制闭包是“函数 它定义时所在作用域的环境”的组合。当外层函数返回一个内层函数而这个内层函数引用了外层函数的变量时就形成了一个闭包。def make_counter(): count 0 def counter(): nonlocal count count 1 return count return counter c1 make_counter() c2 make_counter() print(c1()) # 1 print(c1()) # 2 print(c2()) # 1这里c1和c2各自持有自己的count互不影响。闭包非常适合做计数器、事件处理这类需要“记忆状态”的场景而且不需要为此创建一个类。但闭包有一个经典陷阱特别是配合lambda时funcs [] for i in range(3): funcs.append(lambda: i) for f in funcs: print(f()) # 输出 2 2 2原因是lambda: i中的i是在循环结束后才被真正读取的此时i已经变成2所以所有函数输出的都是 2。修复方法是用默认参数把当前值绑定进去funcs.append(lambda ii: i)这样每次循环就把当时的i值固定成了默认参数。养成“闭包里如果依赖循环变量记得用默认参数绑定”的习惯后面学装饰器和回调函数都会少踩很多坑。5.4 作用域相关的三个实操建议一个建议是函数内部不要随意修改外部状态。把功能做得越“纯”也就是同样的输入永远得到同样的输出代码就越容易测试和维护。第二个建议是全局变量命名尽量带上特殊前缀或全大写比如MAX_RETRY 3这种常量没问题但可变的全局变量越少越好。第三个建议是善用 IDE 或编辑器的颜色提示。VSCode 和 PyCharm 通常会以不同颜色标出局部变量和全局变量看到不正常的颜色往往就是作用域问题的信号。另外写函数时先思考“这个函数需要用到哪些变量哪些应该作为参数传入哪些应该作为返回值带出”。把数据流理清楚作用域问题自然会少很多。6. 函数实操从报错到重构的完整攻略6.1 新手最常见的函数报错对照表我把这几年遇到的新手高频报错整理成了一个表格碰到对应报错可以直接对照排查。报错信息原因解决方案NameError: name xxx is not defined函数外或函数内访问了不存在的变量检查变量名是否拼写错误检查变量是否在作用域内定义UnboundLocalError: local variable xxx referenced before assignment函数内有xxx的赋值但在赋值前读取了它如果确实要修改外部变量加上global否则换个变量名TypeError: xxx() missing 1 required positional argument: b调用时少传了必传参数检查函数定义和调用时参数数量是否一致TypeError: xxx() takes 2 positional arguments but 3 were given调用时多传了位置参数检查函数定义和调用时参数数量是否一致IndentationError: unexpected indent缩进不一致或混用了 Tab 和空格统一用 4 个空格缩进开启编辑器“显示空白字符”TypeError: unsupported operand type(s) for : int and str函数内部运算时参数类型不匹配用type()或isinstance()检查参数类型后转换这里的重点是TypeError那一行后面的描述其实已经提示了是“缺参数”还是“多参数”。很多初学者一看到TypeError就慌其实只要认真读报错信息八成问题都能定位。我经常和带的朋友说报错信息不是红色敌人而是最好的老师。6.2 实战用函数重构一段重复代码我们来看一段没有函数的“原生代码”# 三个学生的成绩等级判断 score1 88 if score1 90: grade1 A elif score1 80: grade1 B else: grade1 C score2 56 if score2 90: grade2 A elif score2 80: grade2 B else: grade2 C score3 95 if score3 90: grade3 A elif score3 80: grade3 B else: grade3 C代码重复了三遍改判定规则时得改三处稍有不慎还会漏改。用函数重构后def get_grade(score): 根据分数返回等级。 if score 90: return A if score 80: return B return C grades [] for score in [88, 56, 95]: grades.append(get_grade(score)) print(grades) # [B, C, A]重构的收益是肉眼可见的逻辑只写一遍以后修改等级规则只需改get_grade一个地方for循环让三个分数统一处理代码量减少了一半可读性反而更强。这也回答了 1.2 里那位同学的问题画五角星、算成绩、发邮件凡是重复出现的“动作块”都可以单元化为函数。我特别建议初学者做一个练习把自己电脑里以前写过的一段重复代码找出来试着用函数重写一遍然后对比“改一个需求时哪个版本改起来更轻松”。亲身体会一次比听十遍理论都管用。6.3 调试函数的三个小技巧第一个技巧是“打印大法”在函数入口打印参数在出口打印返回值基本能确定问题在函数内部还是调用方。def calc_price(unit, count): print(f[DEBUG] unit{unit}, count{count}) total unit * count print(f[DEBUG] total{total}) return total调试完记得删掉这些print或者用logging模块控制日志级别。第二个技巧是检查默认参数是否被意外共享可以用func.__defaults__函数查看函数默认参数的实际值如果发现是同一个可变对象多半是默认参数陷阱。第三个技巧是用type()或isinstance()排查参数类型问题特别是在写通用函数时外部传入的数据很可能和预想的不一样。def process(data): if not isinstance(data, list): data list(data) # 继续处理...这种防御式写法在写库或接口时很常见但业务代码里也不建议处处判断否则函数会变得很啰嗦。更推荐的是在入口做一次统一的类型校验内部默认数据是干净的。6.4 函数设计的“一句话检查清单”经过多年写代码和看代码我自己总结出一个检查函数质量的口诀分享出来供你参考。第一这个函数名能否准确表达它的动作如果不能就改名字。第二这个函数是否只做一件事情如果有“顺便”的逻辑就拆出去。第三参数是否能让调用方一目了然如果调用方要翻文档才懂传参顺序就考虑关键字参数或默认参数。第四返回值是否稳定清晰比如正常返回列表异常就抛异常不要一会儿返回None一会儿返回False。第五有没有共享可变状态有没有用可变对象做默认参数每次写完函数用这五条过一遍代码质量会明显提升一个档次。这也是我在教内部培训时让学员最受用的一组检查项。7. 最后再分享一点我的个人体会函数这个东西学的时候觉得知识点不算难真正难的是把它变成“习惯”。我当年第一次写函数就是被重复代码折磨到不行才老老实实把逻辑抽出来。后来带别人学我也发现能真正理解“复用”这两个字的人后面学装饰器、生成器、面向对象都会顺畅很多因为这些高级特性本质上都是在函数思想上再加一层包装。如果你现在刚开始学我的建议是先不追求一次写对。把重复代码大胆拆成函数哪怕最开始拆得很粗糙跑通之后再按照前面那份检查清单慢慢优化。函数设计是一种手艺靠的是反复练习和大量阅读别人代码没有捷径。而且这个过程也是好事——当你开始觉得“这段代码该抽成一个函数”的时候你实际上已经是一个有设计感的人了。
