nzynzynzy

另 1：我司部署的环境不支持 TS 因此用 js 写
另 2：我一些代码是 gpt 写的以节约时间，所以代码风格不一致，见谅

感谢大家回复，我把最终方案扔在 append 中了，欢迎批评

冒昧艾特一下参与讨论的朋友，也算有个交代。谢谢大家！

https://jsfiddle.net/4pyejfL8/

@xhawk #31
@ZeroAsh #30
@xuanbg #26
@catamaran #23
@changyang #22
@cybort #21
@ddzzhen #20
@Motorola3 #25
@zizon #24
@Chad0000 #15
@NoOneNoBody #13
@Sawyerhou #11
@NessajCN #12
@wingor2015 #8
@rekulas #7
@ivvei #1

如有遗漏重复请海涵。祝各位今天有个好心情。

乐高是按照欧美收入标定的价格，国内收入买起来确实吃力的。所以应该买山寨乐高，就家长和孩子两全其美了（受伤的只有乐高公司

这太简单了，只是各位老哥都是守法公民所以处处是被监控的。

如果你是法外之人，比如买卖了身份证的，那妥妥的隐身。

@zizon 对的无论 m 还是 n 都是有序的。不同冲销策略确实会导致冲销单据的范围不一定，但是余额是一定的因为余额是 transaction 的累加，和进出无关。

@Motorola3 是的。这是一个例子，实际上可能增增减减数额不会这样完全一致，可能是 100 ，-98 ，110 ，-9.98 这样。
这个情境里不仅销售会减小余额，对余额直接操作也会。而目的是寻找销售对应的余额操作（可能增加、减少），减少余额的操作不用考虑找对应。

@xuanbg 这个是关于账户的操作就比较敏感一点，用户看不见对应的、没办法核查就感到不放心。而且当时牛 p 吹出去了就做了吧虽然难度增加了。

@Chad0000 #15 而且你的例子中假设是 invoice 是可以 pending 状态先进来等待付款，和我的情况有差别，我的更像是进来时候实时判断钱够不够，不够这笔就废止了。我觉得老哥说的 cumsum 是有道理的，而且是正负都存在的 cumsum 。

这个就变成了：cumsum 的数组中找值大于 invoice 的情况，其中最靠队尾的、值大于等于 invoice 的一个或者一群值中最靠前的一个。累死我了这个描述。。。

@NessajCN #12 多谢这个还真的很类似！我感觉余额会过期是一种类似的情况，都是有序的先进先出地消耗，我继续去读一下