JavaScript中%是取余还是取模？与Math.floor实现的区别

一、核心定性：% 运算符的本质行为

很多开发者在初学 JavaScript 时，习惯将 % 顺口称为“取模运算符”。当我们在做一些常规算术或正整数循环时，例如：

console.log(7 % 3);   // 1
console.log(10 % 4);  // 2

这种日常直觉让我们很难察觉到它与数学“取模”的区别。然而 ECMAScript 官方规范（ECMA-262）中明确将其定义为 Multiplicative Operators -> Remainder Operator (%)，即余数运算符。

它的运算逻辑是基于向零截断除法（Truncated Division）：即商直接丢弃小数部分向 0 取整。这带来了一个至关重要的性质：余数的符号完全由被除数（左边的数）决定，与除数（右边的数）的符号无关。

console.log( 7 %  3);  //  1  (被除数为正，结果为正)
console.log(-7 %  3);  // -1  (被除数为负，结果为负！)
console.log( 7 % -3);  //  1  (被除数为正，结果为正)
console.log(-7 % -3);  // -1  (被除数为负，结果为负)

请特别注意第 2 行的 -7 % 3 === -1。在初等数论和离散数学中，模 3 的同余类通常被严格限定在非负区间 {0, 1, 2} 之内。数学上的 -7 mod 3 应当是 2，因为 -7 = 3 × (-3) + 2。JavaScript 的 % 返回 -1，直接证明了它执行的是“取余”而非数学“取模”。

二、底层数学推导：商的取整方式如何决定符号

任何整除或模除体系都遵循基本的欧几里得除法恒等式：

a = b × q + r   ➔   r = a - (b × q)

其中 a 是被除数，b 是除数，q 是商（Quotient），r 是残差（Remainder 或 Modulo）。从公式可以看出，被除数 a 和除数 b 是固定的，余数 r 的大小和符号完全由商 q 如何从浮点数舍入成整数决定。

• 向零截断（Truncation）：q = Math.trunc(a / b)。朝 0 的方向舍入。无论正负，直接抹掉小数位。计算机硬件底层（如 x86 汇编中的 IDIV 指令、C/C++、Java、JavaScript）通常默认采用这种方式，其优势是硬件实现简单快速。
• 向下取整（Flooring）：q = Math.floor(a / b)。朝负无穷大（-∞）方向舍入。高德纳（Donald Knuth）在数论和计算机程序设计艺术中倡导这种定义，Python 和 Ruby 的 % 原生就是这种模式。

从图 1 的数轴可以非常清晰地看出：当计算 -7 ÷ 3 = -2.333... 时：

1. 向零截断：向 0 靠拢得到整数商 -2。基准积为 3 × (-2) = -6。此时 -7 在 -6 的左侧，需要再减去 1，故余数 r = -1。
2. 向下取整：向 -∞ 靠拢得到整数商 -3。基准积为 3 × (-3) = -9。此时 -7 在 -9 的右侧，需要加上 2，故模数 r = +2。

三、算法推演：四种符号组合的完整对照

为了全面掌握两者的差异，我们列出 a = ±7 和 b = ±3 的全部 4 种组合，对比其计算过程：

四、如何使用 Math.floor 正确实现数学取模

在了解了数学机制后，我们就可以编写出符合数论标准的数学取模函数。根据欧几里得除法公式，只需将商的获取方式改为 Math.floor：

/**
 * 标准数学取模函数（兼容任意正负数）
 * @param {number} n 被除数 (Dividend)
 * @param {number} d 除数 (Divisor)
 * @returns {number} 结果符号与除数 d 保持一致
 */
function modulo(n, d) {
  return n - d * Math.floor(n / d);
}

// 验证结果：
console.log(modulo( 7,  3)); //  1
console.log(modulo(-7,  3)); //  2 （完美解决了负数问题！）
console.log(modulo( 7, -3)); // -2 （除数为负，符号随除数）
console.log(modulo(-7, -3)); // -1

const cycleMod = (n, m) => ((n % m) + m) % m;

五、典型业务踩坑：轮播翻页与环形缓冲区的“负索引”事故

很多开发者在编写轮播图、无限滚动跑马灯、Tab 标签切换逻辑时，经常会写出如下代码：

// 错误示范：
function getNextIndex(currentIndex, totalCount) {
  return (currentIndex + 1) % totalCount; // 向右切换：正常
}

function getPrevIndex(currentIndex, totalCount) {
  return (currentIndex - 1) % totalCount; // 向左切换：埋下隐患！
}

当用户在第 0 张幻灯片点击“上一页”时，currentIndex - 1 为 -1。按照开发者预期，轮播应该循环无缝跳到最后一张（索引 totalCount - 1）。

但由于 JavaScript 的 % 执行的是向零截断取余，(0 - 1) % 5 的计算结果不是 4，而是 -1！在 JavaScript 数组中访问 slides[-1] 将直接返回 undefined，导致后续视图渲染崩溃、图片加载断流甚至页面报错卡死。

安全健壮的业务实现

// 正确实现方案：
class CircularCarousel {
  constructor(slides) {
    this.slides = slides;
    this.length = slides.length;
    this.currentIndex = 0;
  }

  // 安全切换索引（支持任意正负偏移量）
  navigate(step) {
    // 无论是 +1、-1 还是跨步跳转，均通过取模完美闭环
    this.currentIndex = ((this.currentIndex + step) % this.length + this.length) % this.length;
    return this.slides[this.currentIndex];
  }
}

const carousel = new CircularCarousel(['Slide-A', 'Slide-B', 'Slide-C']);
console.log(carousel.navigate(-1)); // 'Slide-C'（从第0项成功循环至末尾项）
console.log(carousel.navigate(-1)); // 'Slide-B'
console.log(carousel.navigate(1));  // 'Slide-C'

场景扩展：角度规范化

在 Canvas 绘图、游戏开发或 CSS 旋转动画中，经常会遇到连续旋转后的角度计算。例如将用户输入的任意角度规范化到 [0°, 360°) 之间：

// 如果直接使用 -45 % 360 得到 -45，无法用于直观弧度映射
const normalizeAngle = (deg) => ((deg % 360) + 360) % 360;

console.log(normalizeAngle(-45));  // 315°
console.log(normalizeAngle(750));  // 30°

六、总结与工程选型指南

最后，我们在面对实际开发场景时，该如何快速、科学地在原生 % 与 Math.floor 之间进行选择？请参考下方决策指南：

核心技术要点备忘：

1. 概念界定：JavaScript 的 % 严格叫取余（Remainder），不是取模（Modulo）。
2. 符号特征：% 的符号与被除数（左数）一致；真正的取模符号与除数（右数）一致。
3. 奇偶判断警惕：判断变量 n 是否为奇数时，切勿写 n % 2 === 1（负奇数如 -3 % 2 === -1 会判断失败）。正确写法是 n % 2 !== 0 或 Math.abs(n % 2) === 1。
4. 循环索引首选：环形队列、轮播左右切换时，首选 ((n % m) + m) % m，既拥有极佳的运行速度，又能彻底规避 undefined 负索引陷阱。