函数有副作用的本质是修改外部可见状态，如改全局变量、写文件或原地修改可变参数；识别关键是检查函数体内是否有+=、.append()、open(…,’w’)等操作，尤其对list/dict等可变对象的原地修改。
怎么一眼看出函数有副作用
副作用的本质是函数执行时修改了“外部可见状态”，比如改全局变量、写文件、改传入的可变对象。最直接的识别方式是看函数体里有没有 +=、.append()、open(..., 'w')、print() 这类操作，尤其注意对参数本身做原地修改。
常见错误现象：传一个 list 进去，调用完发现原列表变了，但函数没返回新列表——大概率是用了 .sort() 而不是 sorted()，或者用了 .extend() 而不是 + []。
- 检查所有对参数的赋值或方法调用：如果参数是
list、dict、set或自定义可变对象，且调用了.clear()、.update()、.pop()等，基本就是副作用 - 留意隐式副作用：
Logging.info()、requests.post()、time.sleep()都算，哪怕没改变量 - 静态分析工具如
pylint的W0622（重定义内置名）或R1710（不一致返回）不能直接抓副作用，得靠人工盯住可变对象操作
如何让函数没有副作用（纯函数化改造）
核心就一条：不修改任何外部状态，只靠 return 输出结果。对可变参数，要主动复制；对外部依赖，要抽成参数传入。
使用场景：单元测试要稳定、函数要可缓存（@functools.lru_cache）、多人协作时避免“这个函数悄悄改了我的数据”。
立即学习“Python免费学习笔记（深入）”；
- 对
list参数，用items.copy()或items[:]开头；别用items = items.copy()后再改——这只能遮盖问题，调用方仍能看到原列表被改 - 对
dict，用{**d}或d.copy()，但注意.copy()是浅拷贝，嵌套字典还得用copy.deepcopy() - 把 I/O 操作抽出来：不要在函数里写
json.dump(data, open('out.json', 'w'))，改成def process(data): return transformed_data，写文件交给调用方
示例：
def add_item(items, new_item): # 有副作用<br> items.append(new_item) # ← 改了外面的 list<br> return items<br><br>def add_item(items, new_item): # 无副作用<br> return items + [new_item] # ← 返回新 list，原 items 不动为什么有时候必须保留副作用
不是所有副作用都该消灭。性能敏感路径（如大数据处理）、资源管理（如数据库连接池）、或明确设计为“动作型”函数（如 queue.put()）时，副作用是合理甚至必要的。
关键判断点：这个函数的职责是不是“做一件事”，而不是“算一个值”？比如 shutil.move() 的目的就是移动文件，它要是返回新路径却不真移，反而错了。
- 性能影响：深拷贝大对象（如百万级
dict）可能慢 10 倍以上，这时宁可文档写清“会修改输入”，也不盲目纯函数化 - 兼容性风险：python 标准库很多函数就是带副作用的（
list.sort()、random.shuffle()），强行封装一层无副作用版本反而增加理解成本 - 类型提示难覆盖：mypy 默认不校验副作用，
def f(x: list) -> list完全不体现是否修改x，得靠命名或文档约定
调试时快速定位副作用源头
当发现数据莫名被改，别一上来就翻整个调用栈。先锁死可疑变量，用 id() 和 is 判断是否同一对象，比打印内容更准。
常见错误现象：两个地方打印同一个 list，内容不同，但你以为是逻辑错——其实是中间某个函数把它 .reverse() 了。
- 在关键节点加断点，运行时检查
id(my_list)是否变化；如果没变但内容变了，说明是原地修改 - 用
sys.settrace()或breakpoint()配合条件：比如if 'my_list' in frame.f_locals and id(frame.f_locals['my_list']) == target_id: - 临时加防护：在函数开头写
assert not isinstance(items, (list, dict, set)), "mutable input detected"，快速暴露问题调用点
容易被忽略的是：自定义类如果实现了 __iadd__ 或 __setitem__，也会产生副作用，但不像内置类型那么显眼。