c++接口中不能用同一函数既查又改，因语义冲突、调用方无法预期副作用、破坏const契约与abi稳定性，且混淆读写导致缓存、日志、并发、监控等系统失效。
为什么 C++ 接口里不能用同一个函数既查又改
因为语义冲突、调用方无法预期行为、破坏无状态契约。C++ 中的接口函数一旦签名相同（比如 get_or_update()），调用者就无法从函数名或参数判断它是否会产生副作用，这直接违背了“接口即契约”的设计前提。
常见错误现象包括：
- 客户端缓存了返回值，结果下一次调用时发现数据被悄悄更新了
- 日志系统只记录“读操作”，但实际执行了写逻辑，审计链路断裂
- 多线程环境下，
fetch()被当成纯读函数加了 const 限定，结果内部偷偷调用了update_cache()，编译器报错或静默 UB
const 成员函数与可变语义的硬性约束
C++ 编译器靠 const 修饰符来区分查询和修改意图。一个声明为 const 的成员函数，按语言规则不得修改对象的逻辑状态（除非用 mutable 显式豁免）。如果硬把查+改塞进一个函数，你就得在 const 函数里做非 const 操作——要么删掉 const（失去编译期保护），要么滥用 mutable（掩盖真实副作用）。
实操建议：
- 查询接口一律用
const成员函数，返回值类型明确不含副作用（如std::optional<data></data>、const Data&） - 修改接口必须是非
const，且函数名带动词前缀（update_config()、set_timeout()），禁止用assign()、put()这类模糊词 - 若真需要“查后自动修正”逻辑（如缓存未命中时加载并存入），应拆成两个显式步骤：
try_get()+insert_if_missing()，由调用方组合
ABI 兼容性和二进制演化陷阱
一旦发布动态库，接口函数的签名就锁死了。如果初期定义了 value() const 查询函数，后期想让它“顺带刷新状态”，就必须改签名（比如加个 refresh: bool = false 默认参数）——但这会改变 vtable 布局，导致旧客户端崩溃。
更隐蔽的问题是：某些场景下你其实并不需要“分开”，但误以为可以合并。例如：
-
size()看似是查询，但如果内部要遍历容器算长度，它就不是 O(1)，也不该被当成廉价调用；这时应提供empty()和length_hint()等更轻量的替代 - Redis 客户端封装中，
get(key)必须是纯查询；而get_with_ttl(key)返回值含过期时间，这仍是查询——只要不修改服务端状态，多个返回值不构成“修改”
客户端视角：调用成本与错误恢复完全不同
查询操作天然可重试、可缓存、可并行；修改操作必须考虑幂等性、事务边界、失败回滚。把两者混在一个接口里，等于强迫所有调用方为最坏情况做准备——哪怕 99% 的调用只是读。
容易被忽略的一点是：日志、监控、熔断这些基础设施，都是按“读/写”分类打标和限流的。如果你的 fetch_user() 有时写 DB、有时不写，指标就完全失真，告警阈值也失去意义。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
