企业官网建设流程全解析

很长时间没正儿八经聊过Python函数了。最近在整理自己代码仓库的时候，翻到早些年写的项目，发现很多当时觉得"已经很厉害"的函数写法，现在看确实绕了远路。加上社区里经常有人问"函数到底怎么学""为什么我写了几百行代码还是理不清"这类问题，我觉得是时候把Python函数这块掰开揉碎，从理论到实战，连带着这些年踩过的坑和绕过的弯，一起整理成一篇能直接落地的长文。

这篇文章不会只讲语法，也不会上来就扔几十个例子让你背。我想从一个真正的使用者的视角出发，讲清楚函数背后的设计逻辑、各种参数类型的适用场景、作用域带来的那些隐形麻烦，再用几个贴合真实项目的实战案例，把理论串起来。不管你是刚接触Python的同学，还是已经写了一阵子但总觉得函数用得不够顺手的朋友，这篇文章应该都能给你一些新的启发。

1. 函数是什么：不只是"代码复用"那么简单

1.1 函数在Python里的一等公民身份

先从一个最容易被忽略的点说起：在Python里，函数是对象，而且是"一等公民"。

很多人学函数的时候，只记得"函数是用来封装代码、避免重复的"。这个理解本身没错，但太狭隘了。如果你真正把函数当成一个对象来看待，很多高级玩法就顺理成章了——函数可以赋值给变量，可以放进列表里，可以作为参数传给另一个函数，也可以作为返回值从函数里出来。

我举个例子，你感受一下：

def square(x): return x * x def cube(x): return x * x * x # 函数作为对象，放进列表里 funcs = [square, cube] for func in funcs: print(func(3)) # 输出9和27 # 函数作为参数传递 def apply_twice(f, value): return f(f(value)) print(apply_twice(square, 2)) # 输出16 print(apply_twice(cube, 2)) # 输出512

你发现没有，有了"函数是对象"这个认知，map、filter、sorted这类函数为什么能接受一个函数作为参数，就完全说得通了。包括后面要讲到的装饰器、回调函数，本质上都是在利用"函数即对象"这个特性。

很多JavaScript开发者刚转Python的时候会问"js中函数是对象吗"，其实在JavaScript里函数也是对象。只不过Python在这方面走得更纯粹，它把函数、方法、类都统一成了可调用对象。理解了这一点，你就不会再把函数当成"一段孤立的代码"，而是当成"可以被传递、被组合的数据"。

1.2 命名空间：函数背后看不见的规则

函数执行的时候，Python会开辟一个独立的命名空间。这个命名空间决定了函数内部变量和外部变量的关系，也是新手最容易迷惑的地方。

我用一个经典问题来说明：

global_var = 10 def my_func(): local_var = 20 print(global_var) # 可以读取全局变量，输出10 print(local_var) # 输出20 my_func() print(local_var) # 报错：NameError

局部变量在函数外面是访问不到的，这一点大多数人都知道。但有个细节经常被忽略：函数内部可以读取全局变量，但如果要重新赋值，就需要用global声明，否则会创建一个新的局部变量。

counter = 0 def wrong_add(): counter = counter + 1 # 报错：UnboundLocalError def right_add(): global counter counter = counter + 1 right_add() print(counter) # 输出1

第一次写的时候我就在wrong_add这种写法上翻过车。报错信息不太直观，很多人第一反应是"我明明定义了全局变量啊"，但Python的解释是：只要函数内部有对某个变量赋值的操作，它就会默认这个变量是局部的。这个规则坑过太多人了，后面我会专门用一个章节来排查这类问题。

1.3 可调用对象的边界感

Python里除了用def关键字定义函数，还有几种"看起来像函数"的东西：lambda匿名函数、类中定义的方法、类本身（通过__call__实现）、甚至是实现了__call__方法的实例。

class Multiplier: def __init__(self, factor): self.factor = factor def __call__(self, value): return value * self.factor double = Multiplier(2) print(double(5)) # 输出10，实例像一个函数一样被调用

你不需要一上来就用__call__这种黑科技，但知道"可调用对象"这个概念是有好处的。比如你写一个策略模式的调度器，可以用字典把不同策略映射到对应的处理函数；再比如某些配置系统里，一个配置项的值既可以是一个静态值，也可以是一个函数，这种灵活性就来自"函数即对象"。

2. 参数机制详解：从形参到实参的完整链路

2.1 位置参数和关键字参数的取舍

参数是函数最重要的对外接口。很多人写函数时，参数怎么定全凭感觉，结果就是函数调用起来很别扭。我个人的经验是：能表达语义的，用关键字参数；顺序至关重要且语义清晰的，用位置参数。

def create_profile(name, age, city="未知", job=None): return {"name": name, "age": age, "city": city, "job": job} # 位置参数：顺序必须正确 p1 = create_profile("张三", 28, "北京", "工程师") # 关键字参数：语义清晰，顺序无所谓 p2 = create_profile(age=25, name="李四", job="设计师")

在参数比较多的时候，关键字参数的价值会体现得很明显。比如你有一个画图函数，参数有颜色、线宽、透明度、阴影等七八个选项，如果全部用位置参数，调用的人根本记不住第5个参数代表什么。用关键字参数，阅读成本会低很多。

但这也带来一个权衡：如果所有参数都写成关键字参数，函数签名会显得冗长。Python里有一个经典做法——把必填参数放在前面用位置形式，把可选项全部放到**kwargs里，这样既保证了核心参数的直观性，又保留了扩展空间。

2.2 默认参数的致命陷阱：可变对象

这是Python函数里最著名的坑，没有之一。看下面这个函数：

def add_item(item, container=[]): container.append(item) return container print(add_item("a")) # ['a'] print(add_item("b")) # ['a', 'b']，而不是预期的 ['b']

很多人第一次撞上这个坑的时候都一脸蒙。问题出在哪里？默认参数在函数定义时只被求值一次，然后一直复用同一个列表对象。所以你在第二次调用时，container拿到的还是第一次调用时那个已经被改过的列表。

正确的做法是：默认值用None，函数内部再做初始化。

def add_item(item, container=None): if container is None: container = [] container.append(item) return container

这个坑表面上看起来很简单，但实际项目里如果大团队协作，代码审查时稍不留神就会漏掉。我见过线上服务因为一个可变默认参数导致数据越攒越多，最后报警。记住一句话：永远不要用可变对象作为默认参数值。

2.3 *args和**kwargs：到底在解决什么问题

*args和**kwargs是Python函数参数体系里最灵活的部分，但很多教程一上来就让你用，没讲清楚它解决的到底是什么问题。

其实核心就一个：当你预先不知道调用方会传多少个参数时，你需要一个能接纳任意数量参数的形式。

def log_message(level, *messages): prefix = f"[{level}]" for msg in messages: print(prefix, msg) log_message("INFO", "start", "process", "done") def render_report(**options): title = options.get("title", "未命名报告") format_type = options.get("format", "html") print(f"标题：{title}，格式：{format_type}") render_report(title="销售月报", format="pdf", author="张工")

单独看这两个例子可能觉得用处不大，但放到框架代码里，*args和**kwargs几乎是标配。比如写一个中间件或装饰器时，你不能限制被装饰函数的参数形态，用*args和**kwargs把它们统统收下再转交出去，这是最稳妥的做法。

还有一个容易被忽略的语法：解包。调用函数时，可以在可迭代对象前面加*，在字典前面加**。

points = [(1, 2), (3, 4)] for x, y in points: print(x, y) # 元组解包成两个变量 values = {"age": 30, "city": "上海"} p3 = create_profile("王五", **values) # 等价于 create_profile("王五", age=30, city="上海")

这个用法在实际开发里非常顺手，尤其是当你有一个字典，需要把它当成一组关键字参数传给某个函数的时候。

3. 作用域与闭包：那些排查到半夜的Bug源头

3.1 LEGB法则：变量查找的顺序

如果你理解了作用域，函数的一大半Bug就能提前避免。Python查找变量时遵循的是LEGB法则，依次查找：

• L（Local）：当前函数内部的局部作用域
• E（Enclosing）：外层嵌套函数的作用域（比如闭包的外层函数）
• G（Global）：模块级别的全局作用域
• B（Built-in）：Python内置作用域（如len、print）

我用一个嵌套函数的例子来演示：

x = "global" def outer(): x = "outer" def inner(): x = "inner" print(x) inner() print(x) outer() # 依次输出 inner outer

这看起来很简单，但你有没有想过，如果inner函数里没有给x赋值，它会打印什么？根据LEGB法则，它会去外层找，得到"outer"。这就是作用域链的传递性。

这个法则真正麻烦的地方在于：它只读，不写。如果你在inner里写x = "inner"，你只是创建了一个新的局部变量，并不会修改外层那个。要做到修改外层变量，必须用nonlocal关键字。

3.2 closures：闭包在实际项目中怎么用

闭包这个概念听起来高深，实际上就是"函数 + 捕获的外部变量"。Python里最常见的闭包场景是计时器、计数器、配置生成器。

def make_counter(): count = 0 def counter(): nonlocal count count += 1 return count return counter c1 = make_counter() print(c1()) # 1 print(c1()) # 2 c2 = make_counter() print(c2()) # 1，c1和c2的计数器是独立的

这里的关键是nonlocal。因为count不是counter函数的局部变量，也不是全局变量，而是位于嵌套作用域（Enclosing）中，所以需要用nonlocal声明，才能实现"修改外层变量"的操作。

闭包在项目中的实际用途比我以前想象的多得多。比如做Web请求时，你可能要为每个用户创建一个带特定请求头或认证信息的请求函数，闭包可以帮你把上下文信息"绑定"到函数上，不用每次调用都传一遍。

3.3 作用域Bug排查实录：一个真实案例

有一回我维护一个数据处理脚本，发现结果总是不对。调试了很久，最后把问题定位到一段让人抓狂的代码上：

results = [] def process_row(row): multiplier = 2 transformed = row * multiplier # 业务逻辑省略... results.append(transformed) # 其他逻辑省略... for item in [1, 2, 3]: process_row(item)

这个代码看起来没什么问题，但其实有个隐患：results是全局变量，process_row依赖全局作用域，还把数据塞进了全局列表。如果这个函数被多个线程同时调用，results的append操作就会面临并发问题。

更隐蔽的坑是下面这种写法：

def check_and_update(value): if value > 0: flag = True else: flag = False # 后续逻辑如果用到flag... return flag

flag虽然在函数内部赋值了，但如果你在前面早期分支里忘记赋值，运行到后面就会UnboundLocalError。这类错误在逻辑复杂的长函数里非常难排查，因为你盯着逻辑看半天，可能都想不到是某个分支漏了赋值。

我的建议是：函数内部用到的变量，要么全部局部化，要么明确声明global或nonlocal，绝不能含糊。尤其是项目规模上来之后，"隐式依赖外部状态"的危害是呈指数级上升的。我在自己的代码规范里有一条铁律：函数对外界的依赖必须显式写在参数里，函数对外界的影响必须显式体现在返回值里。

4. 函数的进阶玩法：装饰器、lambda与回调函数

4.1 装饰器：在不改源码的情况下增强函数

装饰器是Python函数体系里最有特色的机制之一。它的本质是：接收一个函数作为参数，返回一个新函数。装饰器语法糖@decorator只是让这个操作看起来更简洁。

import time def timer(func): def wrapper(*args, **kwargs): start = time.perf_counter() result = func(*args, **kwargs) cost = time.perf_counter() - start print(f"{func.__name__} 耗时 {cost:.4f} 秒") return result return wrapper @timer def compute_sum(n): return sum(range(n)) compute_sum(1000000)

这个例子里你真正需要关注的是wrapper函数：它接收任意参数，原样转发给原函数，然后把返回值原样传出去。这样不管原函数签名长什么样，装饰器都能适配。

装饰器在实际项目里的用途非常广泛：日志记录、性能监控、权限校验、重试机制、缓存。我印象最深的是给某个接口写重试装饰器的场景，接口偶尔会超时，用装饰器统一加了三遍重试，每遍间隔递增，改动成本几乎为零。

不过装饰器也有个需要注意的坑：用functools.wraps保留原函数的元信息。如果你不用它，被装饰函数的__name__和__doc__都会变成wrapper的，这在调试和文档生成时会造成困扰。

import functools def timer(func): @functools.wraps(func) def wrapper(*args, **kwargs): # ... pass return wrapper

4.2 lambda：什么时候该用，什么时候不该用

lambda表达式在Python里是一个被大量误用的东西。很多人觉得"lambda很高级"，结果写出了一堆难以阅读的代码。我的判断标准很简单：如果这个逻辑超过一行表达式，就不适合用lambda。

# 适合lambda的场景：简单、一次性的逻辑 points = [(1, 3), (2, 1), (4, 2)] points_sorted = sorted(points, key=lambda p: p[1]) print(points_sorted) # [(2, 1), (4, 2), (1, 3)] # 不适合lambda的场景：复杂逻辑应该用def # 下面这种写法人人都喊痛 process = lambda x: x * 2 if x > 10 else (x + 1 if x > 5 else x - 1)

lambda真正方便的地方是与map、filter、sorted这类内置函数配合。但你要注意，当逻辑复杂度上升时，用常规def函数反而更清晰。Python社区有一个共识：lambda适合简单的表达式，一旦涉及语句、复杂分支，就应该用def。

4.3 回调函数和函数组合

回调函数在GUI编程、事件驱动、异步编程里随处可见。Python里实现回调非常简单，因为函数本身可以被传递。

def on_success(data): print(f"处理成功：{data}") def on_failure(error): print(f"处理失败：{error}") def process_request(request, success_cb, failure_cb): try: result = request["value"] * 2 success_cb(result) except Exception as e: failure_cb(str(e)) process_request({"value": 21}, on_success, on_failure) process_request({}, on_success, on_failure)

这种回调模式在UI框架中极其常见。比如你用Python写一个简单的窗口程序，点击按钮时需要执行某个动作，你就可以把那个动作函数作为回调传给按钮。

更进一步，函数组合可以让代码更模块化。比如你要处理一组数据，依次执行清洗、转换、聚合三个步骤，可以用一个链式容器把它们管起来。

4.4 内置函数里值得深挖的几个

Python内置函数中与函数式编程相关的几个，map和filter经常被提到，但我更想说的是functools.partial和functools.reduce。

partial可以固定某个函数的某些参数，生成一个新函数，这在配置化编程中特别有用：

from functools import partial def power(base, exponent): return base ** exponent square = partial(power, exponent=2) cube = partial(power, exponent=3) print(square(5)) # 25 print(cube(5)) # 125

你可以把partial理解为"提前设置默认参数"。如果一个项目里要反复调用同一个函数，但每次都要传几个相同的参数，用partial包装一下，调用代码会清爽很多。

5. 实战案例拆解：从算法题到业务场景

5.1 案例一：李白打酒问题中的函数设计

"李白打酒"是一道经典算法题：李白提着酒壶，遇店加一倍，遇花喝一斗。经过若干次店和花之后，酒刚好喝完，问有多少种排列顺序。这类递归枚举问题特别适合用函数来拆解。

我们先明确状态：当前遇到店和花的顺序是一个"策略序列"，每一步要么选"店"要么选"花"。酒量的变化规则是：遇店翻倍，遇花减一，最后必须归零，且过程中酒量不能为负。

def count_ways(stores, flowers, wine): if stores == 0 and flowers == 0: # 店和花都用完了，最后一口酒正好喝完 return 1 if wine == 0 else 0 ways = 0 # 走"遇店"的分支 if stores > 0 and wine > 0: ways += count_ways(stores - 1, flowers, wine * 2) # 走"遇花"的分支 if flowers > 0 and wine > 0: ways += count_ways(stores, flowers - 1, wine - 1) return ways print(count_ways(5, 10, 2))

这个解法里，函数count_ways的输入是"当前剩余店数、剩余花数、当前酒量"，输出是"从这个状态出发的合法排列数"。

这背后是递归函数的本质：将一个大问题拆成两个子问题，每个子问题的状态空间比父问题更小，直到达到基准情形。

我把这个函数的参数设计逻辑拆给你看：店数、花数、酒量三个状态变量缺一不可，因为不同的排列顺序会导向不同的中间状态。用函数来建模时，最关键的技巧是让函数签名精确表达"当前状态"，而不是把一堆全局变量传来传去。

这道题如果不用函数，用全局变量硬枚举，代码会迅速膨胀到没法看。函数化之后，每一个递归分支都是独立的状态演变，逻辑非常清晰。

5.2 案例二：邻接矩阵构建与图遍历中的函数抽象

图相关的算法题经常涉及邻接矩阵。热搜词里有"python构建邻接矩阵"，我猜很多人是卡在数据结构上了。邻接矩阵本质上就是一个二维列表，但怎么用函数把这个结构组织好，是有讲究的。

def build_adjacency_matrix(edges, n): matrix = [[0] * n for _ in range(n)] for u, v in edges: matrix[u][v] = 1 # 如果是无向图，加上下面这行 matrix[v][u] = 1 return matrix def dfs(matrix, start, visited=None): if visited is None: visited = [False] * len(matrix) visited[start] = True order = [start] for neighbor in range(len(matrix)): if matrix[start][neighbor] == 1 and not visited[neighbor]: order.extend(dfs(matrix, neighbor, visited)) return order edges = [(0, 1), (1, 2), (2, 3), (0, 3)] adj_matrix = build_adjacency_matrix(edges, 4) print(adj_matrix) print(dfs(adj_matrix, 0))

这里有三个值得注意的函数设计细节：

第一，build_adjacency_matrix把"边的列表"转换成"邻接矩阵"，这个转换逻辑是被很多算法复用的，单独抽成函数很有必要。你可以在不同算法里直接调用，不用每次手写双重循环。

第二，dfs函数把visited列表作为参数传递，并且在函数内部修改它。这里有个容易踩坑的地方：不要把可变对象作为默认参数。如果你写成def dfs(matrix, start, visited=[])，第二次调用时visited会保留上次的数据，结果就错了。我在这里用None作为默认值，函数内再做初始化，这是我在第2章强调过的处理方式。

第三，深度优先遍历实际上也用到了隐式"状态传递"——通过visited列表在不同递归层之间共享访问状态。

5.3 案例三：softmax函数与数值稳定性

再往科学计算方向走一步。热搜词里有"softmax函数"和"python矩阵0"，我把它们一起讲。

softmax是把一组数值转换成概率分布的函数，它在多分类问题的输出层、注意力机制里都极其常见。公式很简单：对每个元素取指数，再除以所有元素指数之和。

import math def softmax(logits): max_val = max(logits) exp_values = [math.exp(x - max_val) for x in logits] total = sum(exp_values) return [e / total for e in exp_values] print(softmax([1.0, 2.0, 3.0])) # 输出接近 [0.0900, 0.2447, 0.6652]

这里最关键的一行是max_val = max(logits)。很多人第一次写softmax是直接math.exp(x)，如果x比较大（比如1000），math.exp(1000)会直接溢出。把每个元素减去最大值之后，最大指数变成math.exp(0) = 1，分母至少为1，彻底规避了溢出风险。

这就是数值稳定性的经典案例。如果你在深度学习的框架里写自定义层，这种细节决定你的模型训练会不会突然冒出NaN。

从函数设计的角度看，softmax这个函数只做一件事：把任意一组实数映射到和为1的概率分布。它的输入输出都非常明确，不依赖任何外部状态，是最理想的纯函数形式。这种函数最容易测试、最容易复用。

5.4 案例四：简单碰撞检测函数

再看一个偏游戏开发和仿真方向的例子，热搜词里有"碰撞检测函数"。碰撞检测听起来高大上，其实最简单的一类就是"判断两个轴对齐矩形是否相交"——这在2D游戏里最常用，做一个精灵与障碍物是否碰撞的判断。

def rects_collide(rect1, rect2): # 矩形格式：(x, y, width, height)，x和y是左上角坐标 x1, y1, w1, h1 = rect1 x2, y2, w2, h2 = rect2 return not ( x1 + w1 < x2 or x2 + w2 < x1 or y1 + h1 < y2 or y2 + h2 < y1 ) player = (10, 10, 50, 50) obstacle = (60, 20, 30, 30) print(rects_collide(player, obstacle)) # False，正好错过 obstacle2 = (50, 10, 30, 30) print(rects_collide(player, obstacle2)) # True，边缘重叠也算碰撞

这个函数的逻辑其实很简单：两个矩形不相交，当且仅当一个在另一个的左边、右边、上边或下边。把"不相交"的四类情况都排除掉，剩下的就是相交。

从抽象的角度看，这个函数之所以是好函数，是因为它没有副作用、不修改入参、输入输出明确。你可以在游戏主循环里反复调用它，也可以在单元测试里验证它。如果哪天需要判断圆形碰撞或者更复杂的多边形碰撞，你只需要再写一个函数，保持同样的输入输出约定，上层逻辑根本不用改。

6. 函数设计的工程实践：从能用到好用

6.1 纯函数与副作用管理

在工程实践中，判断一个函数写得好不好，我第一眼看的是：它是不是一个纯函数。

纯函数的意思是：相同的输入永远产生相同的输出，且不会修改任何外部状态。这个概念来自函数式编程，但它的价值是放之四海皆准的。

纯函数的好处在哪里？第一，它可测试——你不用费劲去构造一堆前置状态，直接喂输入、验输出就行。第二，它可推理——你不需要担心"这个函数改了一个全局变量，会不会影响后面"这种问题。第三，它天然支持并发——多个线程同时调用同一个纯函数，不会互相踩踏。

前面几个实战案例里，softmax和rects_collide都是纯函数，count_ways和dfs则是"带递归状态传播的函数"，它们虽然能工作，但如果你追求更严格的工程约束，可以把状态全部封装到内部。

我并不是说所有函数都必须写成纯函数。做日志、写文件、更新数据库的I/O操作天然就是有副作用的，你不能为了纯而纯。但正确的姿态应该是：尽量把"计算逻辑"和"副作用操作"分开。比如，先算完结果，再打印日志；先收集完数据，再一次性写入数据库。这种分层让代码的意外耦合大幅减少。

6.2 参数数量控制：函数接口设计

我见过让人崩溃的函数签名，十几个参数排成一排，调用的时候全靠位置硬记。这种代码别说是别人，过三个月你自己都看不懂。

控制参数数量有几个实用手段：

第一，把相关的参数聚合成对象。如果三个参数永远是一起出现的，比如坐标(x, y, z)，你可以把它们聚成一个元组或者一个小的数据类。

from dataclasses import dataclass @dataclass class Point: x: float y: float z: float def distance(p1: Point, p2: Point) -> float: return ((p1.x - p2.x) ** 2 + (p1.y - p2.y) ** 2 + (p1.z - p2.z) ** 2) ** 0.5

第二，用**kwargs吸收配置项，但要在函数内部做校验和默认值管理。这个方法我在第2章已经演示过。

第三，拆函数。如果一个函数需要超过五个参数，往往意味着它承担了太多职责。比如一个函数既要做数据过滤又要做格式转换还要做结果汇总，你应该把它拆成三个小函数，然后用一个调度函数把它们串起来。

6.3 类型注解与文档字符串：让函数自解释

Python 3.5之后引入了类型注解语法，我强烈建议你在关键函数上使用。它不只是一个书写习惯，更是给IDE和代码检查工具提供了线索，能在写代码阶段就帮你揪出不少类型错误。

def parse_price(price_str: str) -> float: """将价格字符串解析成浮点数。 Args: price_str: 形如 "1,299.00" 的字符串 Returns: 解析后的浮点数值 Raises: ValueError: 当字符串无法解析时 """ cleaned = price_str.replace(",", "") return float(cleaned) print(parse_price("1,299.00")) # 1299.0

类型注解加文档字符串，让函数本身就变成了可读的规范文档。尤其是团队协作时，别人调用你的函数，不需要翻源码就能知道该传什么类型、可能抛出什么异常。

6.4 生成器函数：处理海量数据的钥匙

最后必须要讲的是生成器函数。它在处理大数据或流式数据时，能显著降低内存占用，是一个被低估的高级特性。

def read_chunks(file_path, chunk_size=1024): with open(file_path, "r", encoding="utf-8") as f: while True: chunk = f.read(chunk_size) if not chunk: break yield chunk for chunk in read_chunks("big_log.txt"): process_chunk(chunk)

你注意，这里用的是yield而不是return。函数执行到yield时会暂停，把值交给调用方，下次再调用时从暂停的位置继续执行。这就像一个"按需生产的流水线"。

如果不用生成器，一次性读取一个大文件的所有内容，内存直接被打满。用生成器，每次只处理一个chunk，内存占用基本恒定。

生成器函数也可以用来实现无限序列，比如斐波那契数列、计数器、数据流过滤器。它和普通函数的区别在于：普通函数是一次性计算的"结果提供者"，生成器是按需计算的"序列提供者"。理解这层差异后，我对Python函数体系的理解才算完整。

写完这些，我最大的体会是，Python函数学到最后，拼的不是语法记忆，而是"设计感"——知道什么时候该抽象出一个函数、参数怎么摆、副作用怎么管理、状态怎么传递。这些能力不是靠刷几道题就能练出来的，是在一个个项目里被坑出来的。上面这些案例和实战，都是我一步步走过的路，希望能帮你少踩几个坑。