取余运算结果取决于数据类型而非机器位宽；int、long等类型在不同平台宽度不同导致结果差异，隐式转换和平台相关类型（如size_t、off_t）易引发问题，负数取余符号规则跨平台一致。
取余运算本身在32位和64位机器上**不会产生逻辑差异**，只要操作数类型、值范围和编译环境一致，结果完全相同。真正影响结果的，不是“机器位宽”，而是参与运算的数据类型宽度、符号性、以及底层整数表示方式。
关键看数据类型，不是看系统位数
比如 C/C++ 中：
-
a % b的结果取决于a和b是int、long还是long long，而不是你装的是 Win10 32 位还是 64 位系统； - 在 Windows 上，
int和long都是 32 位（LLP64 模型），哪怕跑在 64 位系统里，int a = -5; a % 3仍是-2； - 但若写成
long long a = -10000000000LL; a % 7，这个计算就必然动用 64 位寄存器——不是因为系统是 64 位，而是因为类型要求它必须用 64 位算术。
容易出问题的其实是隐式类型转换
当代码混用不同宽度类型时，32 位和 64 位环境下的截断或提升行为可能不一致：
- 把一个 64 位指针地址转成
int再取余（如(int)ptr % 100）：在 32 位系统可能侥幸不丢数据，在 64 位系统大概率高位被截断，结果错乱； - 用
size_t（32 位下是 4 字节，64 位下是 8 字节）参与取余，又拿int接收结果，可能溢出或符号异常； - 负数取余的符号规则由语言标准规定（C99 起要求
(a/b)*b + a%b == a，且a%b与a同号），这点在两类平台完全一致，无需担心差异。
编译器和 ABI 才是实际执行者
CPU 指令层面，x86-32 有 idiv/div 指令处理 32 位除余，x86-64 则扩展支持 64 位操作数。但这些细节由编译器根据变量类型自动选择——你写的 uint64_t x % 100，GCC/Clang 在 64 位目标下会生成 div rax 类指令；若目标设为 -m32，它就会先做运行时拆分或调用库函数，确保结果正确，只是性能更低。
移植时真正要检查的点
如果你在把代码从 32 位环境迁到 64 位环境后发现取余结果变了，大概率不是“机器不同”，而是以下原因：
- 源码中用了
long，而它在 Linux（LP64）下是 64 位，在 Windows（LLP64）下仍是 32 位； - 读取了文件偏移（
off_t）、内存大小（size_t）等随平台变宽的类型，再直接参与取余； - 使用了未加
ULL后缀的字面量（如1 ），在 32 位编译下溢出，64 位下正常，导致被除数不同； - 依赖未定义行为，比如对
INT_MIN % -1求值（C 标准规定这是未定义行为，各平台可任意处理）。
