为什么用云商城

每一笔交易：全有或全无

一次购买依序经过下面几步，任何一步不成立，整笔交易就停在那里，不会只扣一半：

1. 检查：商店与商品的权限、购买条件、是不是在轮换中。
2. 限购 / 库存（只有设定了的商品才有这一步）：在数据库里先「预留」名额，再回到玩家身上继续。
3. 能不能完成：货币插件是否可用、物品是否存在；在背包的副本上模拟放入，放不下就直接拒绝（「背包空间不足，请检查背包」）；每一种货币的余额都够。不会把物品丢在地上，也不会先扣钱。
4. 收钱：组合价格的每一种货币依序扣除；其中一种扣不到，已经扣掉的全部退回。
5. 给东西：给物品、执行指令、写交易记录。

第 3、4 步任何一处失败，第 2 步预留的限购与库存名额都会还回去。出售时顺序相反：先确认背包里有足够的物品，拿走物品后付款；付款失败就把背包还原成交易前的样子。

限购与库存跨子服也精准

限购与库存的数字存在数据库，不是存在内存里：

• 预留名额用的是条件更新（「目前已用 + 这次数量 ≤ 上限」才写入），在同一个交易里完成。两个子服同时抢最后一件库存，只有一边会成功。
• 每个重置周期是一行新的记录，到时间不需要任何定时器去清零；所有子服在同一时刻算出同一个周期，所以一起重置。
• 每人限购、全服共用限购、限售、库存都用同一套机制，见 限购与库存。

用 ID 认物品，不是比对整个物品

回收时云商城先问物品插件「这是哪一个物品」：

物品	怎么辨认
云物品 CloudItems、MMOItems、CraftEngine、ItemsAdder、Nexo、MythicMobs	用各插件的物品 ID。随机属性、强化等级、镶嵌的宝石不同，仍然算同一种物品，照样可以卖
没有任何自订资料的原版物品	只看材质。改过名、附过魔的同材质物品不算，不会被当成普通物品误卖
自订的原版物品（改名、附魔、自订组件）	整个物品原样保存（item: {data: …}），回收时必须完全一样

买入不能堆叠的插件装备（CloudItems / MMOItems 武器、防具）时，每一件都单独产生，属性各自随机，不会复制同一件。

不拖慢服务器

• 没人用商店时，服务器线程上没有任何循环任务。 倒数、轮换、限购重置都在打开菜单时才计算；动态价格与交易记录在第一笔交易后几秒内批次写入。
• 所有数据库读写都在插件自己的 1 – 2 条背景线程，服务器线程从不等待数据库。
• 交易后只重画被买卖的那一格商品；有倒数的菜单按距离远近每 1 秒 / 30 秒 / 60 秒刷新一次。
• 实测 50 个机器人每秒 194 笔交易时，整个服务器每 tick 7.8 ms（20 TPS 的预算是 50 ms），见 效能与测试。

三种编辑方式，改哪个都行

方式	适合
游戏内管理介面 /cs admin	拿着物品点空格子上架，最适合一边玩一边加商品、上架插件物品
网页编辑器 /cs editor	大量排版、批量改价、设定限购与周期；改完回到游戏点 [套用] 才写入
直接改文件 + /cs reload	熟悉 YAML 的服主；所有设定都在 商店文件

三种方式改的都是同一份 shops/*.yml。共用 MySQL 时，在任何一个子服改，其他子服几秒内跟着更新，见 MySQL 多服同步。

测过才上线

每个版本上线前都在实机服务器上用机器人客户端跑完整测试（买卖、背包满、余额不足、限购、库存、动态价格、出售箱、指令商品、轮换、特卖、游戏内编辑、变量、云界面、导入、网页编辑器往返、两台子服共用 MySQL），发布用的混淆版本也重跑一次，见 效能与测试。