如果我想配置某个产品库存为无限的话，值设置为 -1 好吗？
我看我们生产环境这样做的，但是我觉得有问题。

这得看具体逻辑吧。

如果超发了，库存变为-1 ，这不得出大问题

2^64 -1

有点作死的感觉

0 超卖就爽翻天了。

普通商品 65535 就够。

分库存类型：有限库存、无限库存，无限库存不做扣减退还操作

只能说设置一个大一点的库存比较好. 具体逻辑也不用改..

whmcs 里面负数就是没货了，可以参考淘宝的商家，设一个很大的数就行了。

没事的，记得退货的时候不要加回去就行了，不然就没得卖了。

确定你不会超卖，就可以

最大的风险可能会是那些正常库存的商品，在某个 bug 触发的情况下被扣成了-1 ，这个时候就爽歪歪了😂

最好是新增一个字段。因为一个字段代表什么含义就应该一直做一样的用处。库存就是个数字。是否无限就是一个 bool 。字段巧用，当时是省事了，以后迭代，交接的维护成本极高。

给个超级大数字会怀孕？

这写-1 的人代码抽象能力估计要告别编码了

实际生活中不可能出现无限库存，所以不需要这个选项

手机充值表示，还是有可能的

给个 1 亿以上的数字不就行了。就和加油站的员工卡一样。起步都是几千万的金额在上面。

null

首先你不应该用 signed 的数值来存储，然后无限的话选择 UINT32_MAX-1 其实就足够了。

不能这么说，楼主应该是有见过例子的。其实 Linux kernel 里很多函数发生错误的时候返回值都是-1 。

加个字段区分标记无限库存不行吗。

用 unsigned int 然后 underflow 了那不就成了 uinx max 了吗。这和楼主说的-1 有什么区别

给 2 亿不行吗？

设置 99999999 最高库存比较好，现实场景中无限库存应该不存在的，一般建议补库存。

应该横向派生不同的类，而不是加重内部逻辑

你这不是抽象而是篡改业务逻辑。
库存实际上就不可能无限，如果是实体货物，有进货才有库存，成本和仓储空间决定了库存上限；如果是虚拟物品，也有版权费用、人工成本等也会限制库存上限。

你根据实际情况定一个合理的库存，就不会留下奇奇怪怪的逻辑漏洞。

我之前也试过，后来马上改了；
1 、部分产品允许超售，此时就会出现-1 的情况，无法分辨是超售了还是无限；
2 、设置为 NULL ，业务代码判断的时候需要单独区分判断，可以这样做，但对后续业务代码不友善；
3 、增加栏位，设定为是否不限库存；

最终我们选择的是第三点；
因为产品允许 超售|库存|不限；
包括后来增加的功能，部分产品需要二次询价，比方 A 给我们一个基本价，库存 10 ，超出库存的要二次确认，我们有单就飞过去，超出库存部分是否能做由他们决定，这种的话业务上会设置为库存产品|允许超售；
1 、因为业务需要统计还剩多少没卖，所以不能设定为不限库存产品；
2 、由于超出时候不是不能卖，只是流程上需要供应二次确认，所以只能设定为 可超售。

所以建议你还是加多个栏位进行判断。
BTW：
我们有些直连对接的分销，业务关系，我们不会反回这种产品究竟是 可超 /不可超 /库存数量这些的，一般情况下可超或库存大于 999 的直接返回 999 ；

几个月前,百度 app 里面的手机充值,不知什么原因的 bug,冲多少,就送多少话费,一群羊毛党蜂拥而至,不知道被薅了多少羊毛.我还特意冲了 100 去试了一下.

咋滴 一个无符号 int 43 亿不够你库存了？

最好设置一个产品认为用户不会超过的上限，这样能兜底。

shopify
缺货后继续销售

math.MaxUint64 这个数够用 N 年了

参考下业界成熟经验吧，你看王者荣耀 30 级的时候，经验上限是 99999999 （几个 9 忘了……

加个类型吧，一个字段显然不够，不够优雅

代码最好完全按照业务逻辑来写，希望合并代码逻辑的话也最好看看是不是业务逻辑上可以合并，有时候不合并比合并的开发、维护、测试成本更低，同时风险也低，还可以不同模块单独分配计算资源，以及单独上线下线。

比如业务上有有限库存和无限库存两种概念，你就写两套，这样故障互相隔离，一部分出 Bug 不会影响另一部分。

等业务和代码比较成熟了，再考虑是否程序规模是否是主要矛盾，是否可以合并一部分来减小规模。

数据库里统计库存的时候，一般都是直接 sum 一下。想想结果。
生产环境最好不要有负数存在，冷不丁什么时候会拿来运算一下。

看大家都是从代码的角度分析，我想从业务本身来说：库存顾名思义就是存放在仓库货物的数量，既然是货物的数量就不应该是负数，货物不应该出现凭空消失的状态。

不能这么绝对，实际业务会有先卖出，后补货的情况。也就是卖多少，补多少。

我们的业务兜底逻辑是非正数库存，都视作无库存；

一般是 N 个 9 作为无限库存，或者字段控制（管理库存 /不管理库存，不管理库存=无限库存），我个人觉得字段控制是否管理库存是最合适的，不管理库存的货，代码就可以每天给逻辑库存加一个极大值。

销售不看仓库的实物，代码里都是虚拟（销售）库存逻辑，你说的 wms 的实物库存逻辑，两边业务不一样，思路不一样。
就算是 WMS 的实物库存，因为人为操作不规范、繁琐的现象，业务上也存在出现-1 可能性。如果严控的话，可能会影响操作效率。尺度如何控制，要看业务经验了。WMS 毕竟是同时和人和货打交道，人不会完全按照设计操作。

我只是单纯从数据设计角度来理解，使用 signed 来存储“数量”这个属性不太合理。如何不 underflow 就是另一个问题了，要考虑如何支持并发，该加锁的地方加锁。

不能存储库存的字段设定特定值。这样会出现很奇怪的业务数据异常问题。

我的做法是：1.加字段标记特殊产品。2. 反正都无限了，库存标记比较大的数值

两种方式都会影响财务模块。所以还需要代码上标记筛选。

不合适，有些时候业务会允许负库存的

不合适,
0.容易触发 bug,
1.不好计数,虽然说是无限量,但是数量还得心里有数

假如接手的不知道-1 表示无限库存，那就完了。可以设置成很大的数，不够再加嘛。

建议设置成数字类型变量的最大值这种

加个标识吧 你没法控制并发下 库存会不会变为-1 如果变了-1 那就是无限了

手机话费就是无限库存的