为什么要把函数拆分成独立模块
初学者写Python时往往习惯把所有代码都写在一个main.py里，几十行的时候问题不大，可一旦代码量超过几百行，各种功能的函数混在一起，查找和维护就会变得非常痛苦。比如一个数据处理脚本里，既有读取文件的函数，又有清洗数据的函数，还有生成报表的函数，全部堆在一个文件里，改一个功能时很容易误伤其他部分。
模块化的本质是按照职责把代码切分到不同的文件中，每个文件就是一个模块。Python中一个.py文件就是一个模块，文件名就是模块名。拆分之后，每个模块只负责一类功能，代码的阅读性、可测试性和复用性都会大幅提升。当你下次需要做类似的数据清洗时，直接导入清洗模块即可，不用再从大杂烩文件里复制粘贴。
从工程角度看，模块化还有利于多人协作。不同开发者可以各自负责不同的模块，通过明确定义的接口进行交互，避免了对同一个文件的频繁修改冲突。Git提交记录也会更清晰，每一次改动都能对应到具体的功能模块。
函数模块化的基本做法与目录结构
最简单的模块化就是把函数按功能分文件。假设你在做一个日志分析工具，可以设计这样的目录结构：
log_analyzer/ ├── main.py # 程序入口 ├── reader.py # 负责读取日志文件 ├── parser.py # 负责解析日志内容 ├── report.py # 负责生成统计报表 └── utils.py # 通用工具函数
每个文件中只写与自身职责相关的函数。比如parser.py中可以这样写：
# parser.py
import re
def parse_line(line):
"""解析单行日志，返回字典格式的时间、级别和消息"""
pattern = r'(\d{4}-\d{2}-\d{2} .*?)\s+\[(\w+)\]\s+(.*)'
match = re.match(pattern, line)
if match:
return {
'time': match.group(1),
'level': match.group(2),
'message': match.group(3)
}
return None
def parse_file(lines):
"""批量解析多行日志"""
return [r for r in (parse_line(l) for l in lines) if r]
在main.py中通过import语句导入并调用这些函数：
# main.py
from reader import read_log
from parser import parse_file
from report import build_report
def main():
lines = read_log('app.log')
records = parse_file(lines)
build_report(records)
if __name__ == '__main__':
main()
当项目继续增大时，可以进一步引入包的概念。包就是包含__init__.py文件的目录，通过多级目录把模块组织成树形结构，比如把所有与数据库相关的模块放在db包中，把接口处理逻辑放在api包中。这样即使项目有上百个文件，结构依然一目了然。
函数封装的设计原则
模块化不只是把代码搬到不同文件里，函数本身的设计同样关键。一个好的模块化函数应该遵循单一职责原则，也就是一个函数只做一件事。如果一个函数名字里带“并且”，比如read_and_parse_and_save，那几乎可以肯定它应该被拆成多个函数。
其次是参数设计。尽量避免让函数依赖全局变量，所有需要的数据都应该通过参数传入，处理结果通过返回值传出。这样的函数是纯函数式的，便于单独测试，也便于在其他项目中复用。对比下面两种写法：
# 不推荐：依赖全局变量，难以测试
data = []
def load_data():
global data
data = open('config.txt').read().splitlines()
# 推荐：参数化设计，职责明确
def load_data(filepath):
with open(filepath, encoding='utf-8') as f:
return f.read().splitlines()
命名规范也不容忽视。模块名和函数名应该使用小写字母加下划线的形式，函数名最好用动词开头，比如calculate_total、validate_input，让调用者看名字就知道函数做什么。同时为每个函数编写docstring文档字符串，说明参数含义和返回值，配合help()函数或IDE提示，使用体验会好很多。
避开模块化路上的常见坑
模块化过程中最常见的问题是循环导入。当模块A导入了模块B，而模块B又导入了模块A时，Python会报ImportError。解决思路通常是提取公共依赖，把两个模块都用到的函数或常量放到第三个模块中，让A和B都去导入它。如果暂时无法重构，也可以把import语句移到函数内部，延迟导入的时机。
# 容易触发循环导入的写法
# a.py
import b
def func_a():
b.func_b()
# b.py
import a # a已经导入了b，这里再导入a就会循环
def func_b():
a.func_a()
另一个坑是相对导入的用法。在包内部，可以用from . import utils这样的相对导入，但它只能在包内使用，直接把包里的文件当脚本运行会报错。建议统一从项目根目录开始运行，使用绝对导入，路径清晰不容易出错。
最后提醒一点，导入模块时避免使用from module import *这种写法。它会把模块里所有公开名称一股脑导入当前命名空间，极易造成命名冲突，也让代码的可读性变差。明确写出要导入的函数名，或者直接导入模块后以module.func()的方式调用，是更稳妥的习惯。掌握了这些原则和技巧，你的Python项目就能随着规模增长始终保持清晰的结构，代码复用也会变得自然而然。