产品：PHP 开源版 v8；核查基于 GitHub v8.0.0 提交 42b234fe45750479355b2d9e59f9d15d593e03d9。2026-11-06 对照 Gitee v8.0 当前提交 923217340792033303e079cb53338e170242044e，相关购物车页面及小程序编译产物相同。
## 现象和验证边界
使用 AI 辅助核查官方源码，并用可执行脚本在原版函数及客户端请求边界复验：前一次保存请求未结束时继续修改数量，最后的输入会更新页面数量和合计，却可能没有作为更新请求发出。未在真实微信界面、服务端或数据库进行端到端验证，未操作线上订单和支付。
## 可复核步骤
1. 测试商品单价 10 元，库存不少于 23，加入购物车并勾选，初始数量为 1。
2. 将数量改为 2，在本次 cart/num 请求尚未完成时继续输入 3，使数量成为 23，再移开焦点。
3. 本地原版函数复现中，页面数量为 23、合计 230，但截获的更新请求仅有 number=2。前一请求完成后没有自动补发 23，非空输入失焦也没有补发。
4. 对照：等待第一次请求完成后再把数量改为 23，可以依次观察到 number=2 和 number=23 两次更新。
脚本实际输出：
```json
{"scenario":"before-ack","shown":"23","total":230,"sent":[["cart/num","2"]]}
{"scenario":"after-ack","shown":"23","total":230,"sent":[["cart/num","2"],["cart/num","23"]]}
```
这里的 sent 指本地在客户端请求边界截获的参数，不代表已在真实服务器收到或写入数据库。
## 原因线索与期望
iptCartNum 更新显示并调用 setCartNum；setCartNum 在 disabledChangeNumber 为 true 时直接返回。前一请求结束只释放标志，没有提交期间积累的最新输入；blurInput 只处理空值。已编译小程序也体现先写入输入值再调用处理函数的顺序。
期望最后一次有效输入能成功保存，或明确显示保存失败/尚未保存。可考虑按购物车条目保留最新待保存数量，当前请求结束后继续提交，并处理失败及失焦情形。这里只提供修复方向，尚未修改官方代码。
固定源码：
- https://github.com/crmeb/CRMEB/blob/42b234fe45750479355b2d9e59f9d15d593e03d9/frontend/uni-app/src/pages/order_addcart/order_addcart.vue
- https://github.com/crmeb/CRMEB/blob/42b234fe45750479355b2d9e59f9d15d593e03d9/frontend/uni-app/src/api/order.js
- https://github.com/crmeb/CRMEB/blob/42b234fe45750479355b2d9e59f9d15d593e03d9/backend/public/statics/mp-weixin/pages/order_addcart/order_addcart.js
## 复现材料
已准备 reproduce-crmeb-cart.cjs。它从本地 CRMEB Git 仓库的上述固定提交读取原版函数和编译产物，以可控的模拟请求执行两组断言，不向线上服务器发送请求；需要 Node.js 和 Git，无需数据库、微信账号或个人数据。
运行方式（第二个参数替换为本地仓库路径）：
```text
node reproduce-crmeb-cart.cjs /path/to/CRMEB
```
公开检索没有找到同样步骤，但无法覆盖内部工单，不能保证首次报告。烦请协助判断是否已有记录，以及是否可按官方“找Bug、提需求拿红包”活动受理；如需要完整脚本或其他测试材料，可以继续补充。
