库存扣减必须原子化，推荐用std::atomic配合compare_exchange_weak循环实现try_decrease接口并返回bool；构造时须校验capacity≥0且initial∈[0,capacity]。
库存对象必须带原子性校验的扣减操作
直接用 int 或 std::atomic<int></int> 存数量不够——扣减时得同时检查是否足够、更新值、返回成功与否，这三步不能拆开。否则并发扣减可能超卖。推荐封装成一个类，把「判断+修改」锁在单个成员函数里。
常见错误是写成两步：if (stock > 0) stock--;，这在多线程下必然出错；或者只用 std::atomic<int>::fetch_sub()</int> 但不检查返回值是否为负，导致库存变负数还继续发货。
- 用
std::atomic<int></int>存当前余量，初始化为非负整数 - 扣减接口（如
try_decrease(int n)）应返回bool：成功扣减才返回true - 内部用
compare_exchange_weak()循环重试，确保「读-判-改」原子完成 - 避免用互斥锁（
std::mutex），除非需要额外状态（比如记录谁扣的、何时扣的）
构造时必须校验初始上限并禁止负值
库存上限不是运行时可变参数，而是对象生命周期内的硬约束。如果允许构造时传入负数或零，后续所有扣减逻辑都会失去意义。必须在构造函数里做断言或抛异常。
容易被忽略的是：上限值和初始值要分别校验。比如上限是 100，但你传了 150 当初始值，那等于默认允许“超限入库”，业务上通常不允许。
- 构造函数签名建议为
Stock(int capacity, int initial = 0) - 强制要求
0 ，否则 <code>throw std::invalid_argument - 不要提供无参构造函数，避免误用默认值
- 上限值存为
const int成员，不可修改
需要支持「预占+确认/回滚」时别硬塞进同一个类
纯扣减（decrease）适合秒杀、抢购等「一锤子买卖」场景；但订单系统常需「先预占、再支付确认、失败则释放」，这时库存对象本身不该承担事务协调职责。
强行在一个 Stock 类里加 reserve()、confirm()、rollback() 方法，会导致职责混乱、难以测试、且无法与外部事务（如数据库事务）对齐。
- 保持
Stock类只管「当前可用量」和「原子扣减」 - 预占逻辑应由上层服务管理：用独立的预留表 / Redis Hash 记录 user_id → reserved_amount
-
Stock::try_decrease()只用于最终扣减，不参与中间态 - 如果真要内聚，至少把预留能力抽成另一个类（如
ReservedStock），和Stock平级而非继承
注意 std::atomic 在不同平台的内存序影响
默认的 std::memory_order_seq_cst 安全但稍慢；在高频库存场景（比如每秒万级扣减），可以考虑放宽。但绝不能直接换成 relaxed——它不保证操作顺序，可能导致「扣减成功但其他线程看不到最新值」。
典型错误是以为「只要用了 atomic 就安全」，结果在 ARM 或 RISC-V 上出现偶发超卖。x86 默认强序掩盖了问题，换平台就暴露。
- 读余量（
get_available()）用memory_order_acquire - 扣减内部的
compare_exchange_weak()用memory_order_acq_rel - 完全没必要碰
memory_order_relaxed，省下的那点性能远不如一次超卖带来的损失 - 如果用 C++20，可考虑
std::atomic_ref避免拷贝，但仅当库存值本身已存在且生命周期可控时才适用
Stock 类该管的事，但没想清楚这点，封装再漂亮也没法上线。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
