Python中argparse解析的args传入函数与类的合理方式

别教条套风格指南的示例，那个反模式示例针对的是无理由用*args拆包、靠locals()透传参数的烂写法，不是要求所有场景都必须把参数拆成单个值逐层传。针对你这种生物信息学CLI工具、固定main入口解析参数、主函数调度多进程任务的场景，按三层边界划分传参逻辑就行，不用改现有架构，还能兼顾可维护性和代码规范：

核心原则先讲透 #

「显式优于隐式」从来不是要求函数形参越多越好，核心要求是代码的依赖可观测、可追溯、不会藏意料之外的逻辑。10-20个CLI参数本身就是一组强关联的全局运行配置，属于同一个逻辑实体，硬拆成一长串形参逐层传递，除了制造冗余代码、加新参数时要改N个函数签名之外，不会带来任何「显式」的好处——毕竟没人能记住20个位置参数的顺序，传参时数错位置出的bug反而更隐蔽。

具体落地的三层传参边界 #

1. 最外层：解析完参数立刻做薄封装，不要裸传argparse原生Namespace #

argparse返回的Namespace本质是个黑盒字典包装，你从函数签名根本看不出它有哪些属性，IDE没法自动补全，写单测的时候构造起来也麻烦。解析完args只需要加几行代码，把它转成显式定义的不可变配置类就行，比如用Python自带的dataclass：

from dataclasses import dataclass
from pathlib import Path
from typing import Callable, List

@dataclass(frozen=True)  # frozen设为True，对象不可变，多进程传递时不怕意外篡改
class PipelineConfig:
    input_paths: List[Path]
    output_dir: Path
    thread_count: int
    min_quality_score: float
    accumulate_func: Callable
    # 所有CLI参数对应字段都在这里明确定义，和argparse的dest一一对应

参数解析完只需要一行就能完成转换：

args = parser.parse_args()
config = PipelineConfig(**vars(args))

这一步直接解决了「传对象不透明」的问题：所有配置项都明明白白写在类定义里，点一下就能跳转到定义看所有字段，静态检查、IDE补全全能正常工作，比裸传Namespace透明得多。

2. 中间调度层：主运行函数直接传整个config对象，不用拆分 #

就是你那个接收参数、初始化进程池、拆分任务的主函数，它的核心职责就是承接全局配置、调度整个流程，依赖绝大多数CLI参数是完全合理的。这时候硬把20个参数全列在形参里才是反模式：调用时要把20个参数挨个写一遍，后续加新参数还要改这个函数的签名，纯纯冗余代码。

边界判断标准：如果一组参数总是成组传递、共同属于同一个逻辑实体（这里就是整个pipeline的运行配置）、被函数的核心逻辑依赖，就应该封装成单个对象传递，这是符合高内聚设计的，完全不违反显式原则。

3. 多进程子任务层：只传子任务实际需要的参数，不要透传整个config #

分发到进程池的最小执行单元，就按风格指南的要求显式传单个参数。比如你某个子函数是做测序序列质量过滤，只需要单条序列和质量阈值两个参数，那就只传这两个，不要把整个config扔进去：

def filter_sequence(seq: str, min_quality: float) -> bool:
    # 子任务逻辑，不感知全局配置
    return seq.quality >= min_quality

def run_pipeline(config: PipelineConfig):
    seqs = load_sequences(config.input_paths)
    with Pool(config.thread_count) as pool:
        # 提交任务时只从config里取子任务需要的字段传
        tasks = [(seq, config.min_quality_score) for seq in seqs]
        filter_results = pool.starmap(filter_sequence, tasks)
        # 其他子任务同理，用到啥取啥传啥

这层拆参数的成本极低，因为子任务通常只依赖1-3个配置项，不会出现长参数列表的问题。同时子任务和全局配置完全解耦，后续要复用这个函数到其他流程、或者写单元测试的时候，不需要依赖整个PipelineConfig类，耦合度非常低。

额外的场景收益 #

这套方案完全适配你现在的项目架构，改动量极小，还额外解决了生信工具开发的几个常见痛点：

• 加新参数只需要在argparse加定义、在PipelineConfig加对应字段，哪个子任务要用就直接从config取，不用改中间所有调度层的函数签名，迭代效率高很多
• 不可变的config对象在多进程场景下不会被子进程意外修改，排查配置类bug的时候省很多事
• 写单元测试的时候，测主流程就构造一个PipelineConfig实例传入，测子函数就传简单的单个参数，不用每次mock argparse的解析逻辑

什么时候必须拆成单个参数 #

如果一个函数是脱离当前CLI工具也能独立使用的通用工具函数，且只用到配置里的1-3个参数，那就直接传它需要的单个值，不要传整个配置对象，避免通用函数和特定项目的配置类耦合。

内容的提问来源于stack exchange，提问作者Liam McIntyre