% 本质是整数取模映射，不直接生成概率，但可将连续整数映射到固定范围实现确定性分桶；关键在模数与分支逻辑设计，如30%中奖需结合请求序号而非随机数。
用 % 做概率分桶，本质是整数映射
取模运算本身不直接生成概率，但它能把连续递增的整数（比如请求序号、时间戳、自增ID）映射到固定范围，从而实现「确定性轮询」或「离散化概率分桶」。关键不是 % 多神奇，而是你怎么设计模数和条件分支。
比如你有 100 次请求，想让其中 30% 中奖：别指望 Math.random() % 100 —— 那根本不是取模的用法，而且 <code>Math.random() 返回的是浮点数，对浮点数取模在 JS 里行为不可靠。
- 正确做法是先生成一个整型序列号（如
reqId），再用reqId % 100得到0–99的均匀分布整数 - 然后判断：
if (reqId % 100 - 这样只要
reqId是递增且无跳空的，中奖率就严格等于 30%
% 在轮询分配中如何避免状态依赖
服务端做灰度流量分发时，如果用随机数，每次请求都得查状态或维护 session；而用 userId % N 就完全无状态：同一用户永远落在同一组，适合一致性哈希的简化版。
- 假设你有 4 台机器，希望流量均分：
serverIndex = userId % 4→ 直接路由到第serverIndex台 - 但注意：
userId必须是整型；如果是字符串 ID，先用简单哈希（如str.charCodeAt(0) % 256）转成整数，再取模 - 扩容风险：从 4 台扩到 5 台，
% 4→% 5会导致 80% 流量重分布；如需平滑迁移，得换一致性哈希或加映射表
为什么 timestamp % 60 不适合做分钟级定时任务
表面上看，Date.now() % 60000 === 0 能捕获整分钟时刻，但实际几乎不可能触发——因为 JS 定时器精度低、事件循环延迟、以及 Date.now() 返回毫秒值，% 60000 等于 0 的瞬间极短，单次检查大概率错过。
- 真正可行的是：记录上一次执行时间
lastRun，每次检查Math.floor(Date.now() / 60000) !== Math.floor(lastRun / 60000) -
%更适合周期对齐的离散场景，比如“每 7 条日志打一个标记”：if ((logCount + 1) % 7 === 0) { /* 打标 */ } - 别用
%替代setInterval或节流逻辑，它不解决时机控制问题
负数取模的坑：不同语言结果不一致
Python 中 -1 % 5 是 4，JavaScript 中是 -1。如果你用请求序号做取模，而序号可能为负（比如某些数据库 ID 从负数开始），结果会出乎意料。
- JS 安全写法：
((n % m) + m) % m强制转为正余数 - Go/Java/C++ 默认向零取整，
-7 % 3 == -1；Rust 和 Python 向下取整，-7 % 3 == 2 - 只要输入可控（如自增 ID 从 0 开始），就别碰负数；否则统一预处理，别依赖语言默认行为
真正难的不是写出 a % b，而是确认 a 的取值范围、分布特征，以及 b 是否随业务变化——这些决定了你的“概率”到底是伪随机、强一致性，还是埋了扩容雷。
