重复参数检查应集中于public接口层，即数据进入封装边界的第一时间；私有函数只处理已知合法数据，不承担校验责任，否则破坏封装契约、引发安全与维护风险。
重复的参数检查应该放在封装后的公共接口层
参数校验不是越早越好，而是要落在调用方能直接控制、且逻辑语义明确的位置。C++封装后，public成员函数是外部唯一合法入口，所有校验必须集中在这里——而不是塞进私有辅助函数、委托构造函数或底层工具函数里。
常见错误现象：isValidString被当成万能校验器到处调用，结果在某个私有方法里漏了空指针检查；或者把校验逻辑全扔进init()，但构造函数本身没做输入合法性判断，导致对象构造出非法状态。
- 校验必须发生在“数据进入封装边界”的第一刻，也就是
public函数接收参数时 - 私有函数（如
buildSearchPaths、init）只处理已知合法的数据，不承担防御责任 - 委托构造函数不能替代校验：它只负责初始化流程收敛，不负责拦截非法实参
- 若校验逻辑复杂（如解析字符串再校验范围），应封装为独立
static辅助函数，但调用点仍在public接口内
为什么不能下放到私有函数或工具层
下放校验会破坏封装契约。用户调用setAge(int age)时，默认预期这个调用本身就会拒绝负数；如果实际把校验丢给内部validateAge()，而validateAge()又被其他路径绕过，就等于暴露了不安全的内部通道。
性能与兼容性影响：校验下放会导致同一份逻辑在多个私有路径中重复触发，或因调用链变长增加分支预测失败概率；更关键的是，一旦未来重构私有实现（比如合并两个私有函数），校验可能被意外删掉或跳过。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 工具函数（如
strtol封装）只负责“转换+报告错误”，不代替业务层做语义校验（例如“年龄不能超过150”） - 类内私有方法假设输入来自本类
public接口，因此不检查前提条件 - 跨类调用时，校验责任仍归属被调用方的
public入口，而非调用方自行预检
构造函数里的参数检查最容易被忽略
构造函数看似天然该做校验，但很多人依赖委托构造函数“统一初始化”，误以为只要一个构造函数检查了，其他被委托的就安全了——错。每个public构造函数都必须独立完成自己的参数检查，哪怕只是转发给另一个构造函数。
典型翻车场景：AppConfig(std::string env, std::string path)做了非空检查，但AppConfig(std::string env)直接委托过去却没校验env是否为空，导致构造出env_为空串的对象。
- 委托构造函数语法（
: AppConfig(env, "./")）不自动继承校验逻辑 - 每个
public构造函数体的第一行可以是if检查，第二行才是委托调用 - 若校验逻辑完全一致，可提取为
static成员函数，但调用动作不能省
getter/setter里的校验边界要清晰
setXXX必须校验，getXXX一般不校验——除非它触发了延迟加载或远程获取（参考fetch_humidity()反例）。很多开发者给getTemperature()加空指针检查，其实是在掩盖对象未正确初始化的问题。
容易踩的坑：把校验写成if (!data_) throw std::logic_error("not initialized");，这属于暴露内部状态，正确做法是确保构造函数和所有public修改接口都能让对象始终处于有效状态。
-
setter校验后，应保证成员变量始终满足业务约束（如age_ >= 0 && age_ ） -
getter只返回当前值，不验证“值是否还有效”；有效性由修改入口统一保障 - 若存在“惰性计算”字段，校验应放在触发计算的
public方法里，而非getter中
真正难的不是写校验代码，而是判断“谁该为这段数据的合法性负责”。封装之后，责任必须收束到public接口这一层，多一分则冗余，少一分则破防。
