降低高阶函数耦合度的核心是解耦实现细节：用函数类型替代硬编码行为、封装关联参数为结构化输入、避免参数传递状态或副作用、限制数据结构深度与可变性。
降低高阶函数的耦合度，核心是让函数不绑定具体实现，只关心“做什么”，而不是“怎么做”。关键不在参数多或少，而在参数代表什么、是否可替换、是否暴露内部细节。
用函数类型替代硬编码行为
当高阶函数内部直接调用 print、requests.get 或写死 == 判断时，它就和 I/O、网络、比较逻辑强耦合了。应把这类行为抽成参数：
- 传入一个 logger 函数，而非直接调用 logging.info
- 传入一个 fetcher 函数，而非在函数体内写 requests.get(url)
- 传入一个 comparator（如 lambda a, b: a['score'] > b['score']），而非固定按某个字段排序
这样主流程完全不感知底层变化，测试时只需传入哑函数或打桩函数即可。
封装关联参数为结构化输入
若高阶函数接收 4 个以上参数，且它们语义相关（比如 host、port、timeout、retries），说明这些本该属于一个配置单元：
- 定义 ClientConfig 类或 NamedTuple，把这组参数打包传入
- 避免调用方记不清顺序，也防止后续新增字段导致所有调用点改签名
- 结构体本身可复用、可默认初始化、可带验证逻辑（如 timeout > 0）
避免通过参数传递状态或副作用控制
高阶函数不应靠参数开关来决定“是否缓存”“是否记录日志”“是否重试”——这属于控制耦合，会让函数职责模糊：
- 不要设计 cache=True 这类布尔参数，而应让缓存作为独立装饰器或中间层
- 不要用 debug_mode=True 来开启打印，而应统一通过 logger 级别或 handler 控制
- 真正需要分支逻辑时，优先用不同函数组合（如 with_retry(f) 包装原函数），而非在函数内写 if-else
限制参数中数据结构的深度与可变性
高阶函数接收 dict 或嵌套 list 时，容易形成标记耦合：一旦结构微调，所有使用方都要改：
- 约定清晰的输入契约，例如只接受 data: Sequence[User]，而非 raw_response: dict
- 对复杂输入做一次预处理（如 parse_user_list(raw)），让高阶函数只操作稳定的数据形态
- 避免参数是可变对象（如 list/dict）并被函数内部修改——这会引发隐蔽的副作用和并发问题
