佣金计算必须在独立协程中执行，避免阻塞worker事件循环；应使用go()启动并设置硬超时，path查询需改用前缀索引与范围查询替代like，事务内禁止调外部http接口，须通过消息队列异步处理。
佣金计算必须在独立协程里跑
直接在 HTTP 请求上下文中同步算多级佣金，会卡住整个 Worker 事件循环。Webman 的协程调度是协作式的，一旦某个协程执行耗时操作（比如递归查 5 层上级、多次数据库 JOIN），其他请求就只能等它让出控制权。
正确做法是把佣金逻辑封装成独立协程任务，用 go 启动，并设置硬超时：
- 用
Co::create()或go()包裹核心计算逻辑，避免阻塞主线程 - 关键路径必须加
timeout：例如Co::set(['socket_timeout' => 3])，防止上游数据库慢查询拖垮整条链路 - 不要在协程里调
sleep()或usleep()，改用Co::sleep() - 若涉及 Redis 累加或 MySQL UPDATE，确保连接已启用协程支持（如
swoole_mysql或pdo_mysql+co::mysql）
多级分销的 path 查询不能走 LIKE
常见错误是用 SELECT * FROM distribution_relation WHERE path LIKE '1/2/%' 查下级团队——这会触发全表扫描，数据量过万后响应直接上秒级。
真正高效的方式是利用 path 字段的前缀特性 + 索引覆盖：
-
path字段必须建前缀索引：KEY idx_path (path(20))（不是全文索引） - 查询语句改写为：
SELECT user_id FROM distribution_relation WHERE path >= '1/2/' AND path （注意末尾无斜杠，靠字典序截断） - 层级深度建议限制在 3–4 层，超过需拆成异步任务；无限级模式在 Webman 中极易引发栈溢出或内存泄漏
- 若需实时统计团队人数，用 Redis HyperLogLog 做去重计数，而非每次 COUNT(*)
佣金金额必须用 decimal 计算，别碰 float
PHP 的 float 在 16 位以上精度就会丢数，而分销系统常涉及 0.01 元级结算，0.1 + 0.2 == 0.30000000000000004 这类问题会导致财务对账失败。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
所有金额字段和中间计算都应强制走 decimal：
- 数据库字段类型必须是
DECIMAL(10,2)，不是FLOAT或DOUBLE - PHP 中用
bcadd()、bcmul()等 BCMath 函数做运算，例如：bcmul($order_amount, '0.15', 2) - Redis 存储佣金时，也存字符串形式的
"123.45"，而不是123.45（PHP 自动转 float） - 前端传来的金额参数，进控制器第一行就用
filter_var($amount, FILTER_VALIDATE_FLOAT)校验，再转成字符串参与 BCMath 运算
佣金落库要配事务 + 补偿队列
Webman 没有自动事务管理，一个订单触发多笔佣金写入（上级、上上级、平台分润），若中间某条 INSERT 失败，不回滚就会导致钱少发或多发。
必须显式控制事务边界，并预留补偿能力：
- MySQL 事务起始点放在
onWorkerStart初始化的 PDO 实例上，不要用框架默认连接 - 用
$pdo->beginTransaction()→ 批量 INSERT →$pdo->commit()，任一环节异常则$pdo->rollback() - 事务提交后，立刻投递一条消息到 RabbitMQ（用
workbunny/webman-rabbitmq），内容含order_id和commission_ids，用于后续对账或补发 - 禁止在事务内调外部 HTTP 接口（如通知财务系统），这类动作必须放到消息队列消费者里异步执行
最易被忽略的是事务隔离级别：Webman 默认是 REPEATABLE READ，但佣金计算常需读已提交数据，建议在事务开始时执行 $pdo->exec('SET TRANSACTION ISOLATION LEVEL READ COMMITTED')。
