应将语义关联的多个参数（如x、y、width、height）封装为结构体或类，优先用const引用传参；职责不清时需拆分函数或引入Builder模式；禁用std::map/void*等弱类型“万能参数”。
用结构体或类封装相关参数
函数参数超过4个，尤其是存在语义关联的参数（比如 x、y、width、height），直接传参极易出错且难以维护。最直接有效的做法是把它们打包进一个结构体或类。
结构体比类更轻量，适合纯数据聚合；若需默认值、校验或行为，可选 class 并加构造函数。
- 避免把不相关的字段塞进同一个结构体——例如
user_id和timeout_ms不应共用一个Config - 结构体命名要体现职责，如
ImageCropParams比Params更明确 - 传参时优先用 const 引用：
void process(const ImageCropParams& p)，避免拷贝开销 - 若结构体字段较多，考虑用
= default构造函数 + 成员初始化器列表，提升可读性
按职责拆分函数，而不是堆参数
参数多往往意味着函数职责过重。与其不断加 bool enable_foo、int retry_limit、std::string log_tag，不如识别主干逻辑和变体分支，把可选行为抽成独立函数或策略对象。
例如处理网络请求的函数，原本有 7 个参数控制重试、超时、压缩、鉴权、缓存、回调、错误码映射——其实可以拆成：
立即学习“C++免费学习笔记（深入）”；
-
HttpRequestBuilder负责配置（链式调用设置各项） -
execute()只接收构建好的Request对象 - 不同场景复用 builder，不再需要每个调用都传一堆参数
这种模式在 C++17 后配合结构化绑定和 std::optional 更易控制可选参数。
警惕“万能参数”反模式：std::map 或 void*
看到参数太多就扔进 std::map<:string std::any></:string> 或裸指针 void*，短期看似灵活，实际等于放弃编译期检查和 IDE 支持。
这类方案带来的问题远多于便利：
- 调用方无法知道该传哪些 key，只能翻文档或看示例，容易拼错键名
- 类型安全丢失：
map["timeout"]可能是int、std::chrono::milliseconds或根本不存在 - 无法做参数默认值、重载或 SFINAE 分支选择
- 调试时打印
map内容远不如直接看结构体字段直观
除非是插件系统或脚本桥接等强动态场景，否则不要用。
用命名参数模拟（C++20 及以后可考虑）
C++ 还没有原生命名参数语法，但可通过函数对象 + 成员访问模拟接近效果，比如：
auto req = HttpRequest{}.url("https://api.example.com")
.timeout(5s)
.retries(3)
.compress(true);
send(req);
这种写法依赖良好的 builder 设计，关键点在于：
- 每个 setter 返回
*this（支持链式） - builder 的成员变量与最终目标结构体字段一一对应，避免中间状态不一致
- builder 构造函数设为私有，强制走链式调用，防止漏设必要字段
- 注意移动语义：builder 在
send()中应能高效转为目标对象，避免冗余拷贝
不过要注意，过度设计 builder 本身也会增加维护成本——是否值得，取决于该函数被调用的频次和配置复杂度。
真正难的不是怎么封装参数，而是判断哪些参数属于同一抽象层级、哪些其实暗示了新类型或新职责。参数膨胀往往是接口边界模糊的第一个信号。
