1. 为什么我会在PHP里琢磨用位运算替代算术先交代一下背景我有相当长一段时间在维护一个高并发的PHP接口服务业务逻辑不复杂但单机QPS压力一直很大。压测的时候profiler一开发现CPU时间大头不在数据库查询不在网络IO而在一堆看起来人畜无害的整数运算上——各种floor($x / 2)、$n % 2、状态码累加、$num * 1024。每次请求都要反复执行几千次积少成多CPU火焰图上那几条线非常扎眼。那时候我就在想一件事PHP作为一门动态弱类型语言底层每一步整数运算都要经过zend引擎的调度、类型检查、转换本来就不如C/C那么直接。如果能在不改变可读性的前提下把一些高频算术操作换成位运算是不是能拼出几个百分点的CPU开销后来我查了不少资料也做了实测结论是位运算替代算术这条路在PHP里确实走得通但远没有很多人想的那么“无脑换就行”。它适用的场景、边界条件和踩坑点非常多而且位运算替代算术这件事真正的价值不在于替代普通的加减乘除而在于替代那些“算起来繁琐、位运算天生擅长”的操作。这篇文章我不会写一堆教科书定义而是把我实测过的场景、测试数据、以及真实项目中踩过的坑一条一条摆出来。如果你是PHP开发者在做接口优化、算法题、或者维护一个要求极致性能的老项目这篇文章应该能帮你在安全的范围内把位运算用起来。想上手的读者哪怕之前完全没接触过位运算看完也能照着写。先说一个反直觉的地方PHP里的位运算其实比加减乘除在数值处理上更“专一”。普通加减乘除要处理整数溢出逻辑、浮点转换、类型自动转换而位运算在PHP内部强制把操作数当作整数来处理跳过了大量类型判断。这就意味着在某些特定场景下位运算不仅能帮你写出更底层的逻辑速度上也有实在优势。下面我从PHP的位运算符本身开始拆。2. PHP的位运算符到底有哪些先厘清家底很多教程讲位运算喜欢直接把C语言的用法套到PHP身上其实PHP的位运算在语义上有自己的脾气。我们先把它家的运算符列个清单再逐个说清楚在PHP里的行为。2.1 PHP位运算符全家桶PHP里一共有6个位运算符外加3个用组合的赋值形式运算符名称例子运算规则按位与$a $b两个位都为1时结果为1|按位或$a | $b至少一个位为1时结果为1^按位异或$a ^ $b两个位不同时结果为1~按位取反~$a0变11变0左移$a $n全部位左移n位右侧补0相当于乘以2的n次方右移$a $n全部位右移n位左侧补符号位或0见下文赋值形式就是,|,^,,不用单独介绍就是先运算再赋值。这里有一个每个初学者都会搞混的点PHP的右移不是无脑补0对于负数它按算术右移处理即左侧补上符号位。比如-8 1的结果是-4而不是2147483644如果你在C语言里对无符号整数这么搞的话。PHP官方手册明确说“右移时PHP将自动填充符号位”这一点一定要记得后面讲负数场景会专门说坑。2.2 PHP位运算的一个隐性前提操作数会被转成整数在PHP里位运算的操作数会被隐式转换为int转换规则和intval()差不多。这意味着?php var_dump(5.9 1); // int(1)浮点数直接截断成整数再参与位运算 var_dump(7 | 2); // int(7)数字字符串转成整数 var_dump(true 2); // int(4)true转成1我见过不少人在实际代码里把0.5拿来参与位运算结果发现跟预期完全不符。所以我的建议是不要用位运算去处理可能包含小数或非法字符串的数据除非你100%清楚PHP的int转换规则。位运算最适合的是“本来就是整数”的场景。PHP整数的内部表示在不同平台上有差异64位平台上PHP的int从-9223372036854775808到9223372036854775807即64位有符号整数32位平台则只到正负21亿。做位运算时溢出的高位会被截断。也就是说如果你做1 40在64位下正常但在32位下会得到一个匪夷所思的值。写跨平台代码的同学要额外小心这一点。2.3 位运算的性能直觉为什么它可能更快PHP的zend引擎在执行 - * /这些算术操作时要走完整个操作数处理流程判断类型、如果类型不合再转换、执行运算、检查结果是否需要转换或抛异常、内存管理。而位运算内部直接取操作数的整数值然后交给CPU的一条位运算指令完成省略了大量分支判断。我用一个生活中的例子来类比算术运算就像你去商场买东西收银员要问你是现金、刷卡还是扫码然后还要算一遍找零位运算就像自动售货机投币口你塞的硬币它直接根据重量和尺寸判断面额整个过程干脆利落不需要那么多协商流程。这个差异放在单次操作上微乎其微但如果一段代码在一个热循环里被调用了十万次差距就会从误差变成可观测的耗时差。有了这个底子下面进入正题具体的替换场景。3. 哪些算术场景可以换成位运算替换对照表我不太建议“凡算术皆可位运算”这种疯狂做法但下面这些高频场景位运算确实是用起来很顺手、替换起来没什么副作用的。我按照业务实战中遇到的频率来排每个都给出“算术写法”和“位运算写法”的对照以及适合替换的理由。3.1 乘以或除以2的整数次幂这个是最经典、替换成本最低的场景?php // 算术写法 $x $num * 8; $y $num / 4; $z floor($num / 16); // 位运算写法 $x $num 3; // 乘以2的3次方即*8 $y $num 2; // 除以2的2次方即/4 $z $num 4; // 除以2的4次方相当于floor($num / 16)有两点必须讲清楚第一左移做乘法很好理解不丢失精度只要不移到溢出都没问题。右移做除法时它实际上做的是对正数的向下取整而不是四舍五入。7 1结果是3而不是3.5这跟intdiv(7, 2)的行为一致跟7 / 2得到3.5完全不同。所以如果你的业务要求“除以2后保留浮点”那你不能无脑换。但在分页、数组索引、缓存分桶这类“除以2后必须取整”的场景右移天然就帮你做了取整反而省了一步floor。第二右移对于正数来说等价于floor($num / 2的n次方)但它的速度更快因为它直接丢弃低位的二进制比特连取整操作本身都省了。我在一个分页场景里就做过替换原来每查一次数据库都要floor($page * $pageSize / something)算偏移量换成右移之后代码精简了火焰图上的占比也降了。3.2 判断奇偶性判断一个整数是奇数还是偶数最常见的写法是$num % 2 0。改成位运算?php // 算术写法 if ($num % 2 0) { /* 偶数 */ } // 位运算写法 if (($num 1) 0) { /* 偶数 */ }原理超级简单一个整数的二进制最低位如果是1那它肯定是奇数是0就是偶数。 1就是把除了最低位以外的所有位都清零只留下最后一位。这条规则对正数负数都成立而且对负数比% 2更直观——-3 % 2在PHP里结果是-1虽然判断也不复杂但-3 1直接等于1一眼就知道是奇数。实际项目里最典型的用法写在这里?php foreach ($items as $i $item) { if ($i 1) { // 奇数行的样式处理 } else { // 偶数行的样式处理 } }在循环渲染双向列表、交替背景色、切分奇偶数据时这个写法既快又清爽。我实测过PHP在循环里跑$i 1比$i % 2要稳定快大约15%到20%量级虽然不大但日请求量上亿的项目里这就是实打实的CPU时间。3.3 对2的整数次幂取模这个场景很多人不知道但特别实用当除数是2的n次方时$num % (2的n次方)可以等价替换成$num (2的n次方 - 1)。举个例子?php // 算术写法 $bucket $id % 8; $index $hash % 64; // 位运算写法 $bucket $id 7; // 等价于 $id % 8 $index $hash 63; // 等价于 $hash % 64背后的道理不复杂二进制下对2的n次方取模结果就是该数的低n位而高位部分都是商。 (2的n次方 - 1)正好就是“只保留低n位”。比如100 % 8100的二进制是1100100低3位是100即4所以100 7等于4跟100 % 8一模一样。这个场景在什么业务里会用到哈希分桶、负载均衡里的取模路由、环形缓冲区的索引计算、分布式一致性哈希的槽位计算。我实际处理过一个订单号生成服务原本用$orderId % 64来分库分表每次要算一次取模改成$orderId 63后这部分耗时直接砍掉一半以上。但是这里有个大坑我必须说清楚这个替换只对“除数为2的整数次幂”成立除数换成6、10、100位运算就不灵了。$id 9绝对不是$id % 10因为9的二进制是1001它保留了低4位而% 10的结果依赖整个数的所有位两者天差地别。替换前一定先确认模数是不是2的幂1、2、4、8、16、32、64、128、256这类。3.4 快速设置、清除和判断“状态位”说白了就是用一个整数的不同二进制位来存储多个开关状态这是位运算在业务代码里最能发挥价值的地方。一个典型的场景是订单的“状态集合”是否已支付、是否已发货、是否已退款、是否已评价。传统写法是定义四个布尔变量或四个数据库字段而位运算允许你用一个int字段搞定。?php // 定义状态位常量注意必须是2的幂 define(STATUS_PAID, 1); // 二进制 0001 define(STATUS_SHIPPED, 2); // 二进制 0010 define(STATUS_REFUNDED, 4);// 二进制 0100 define(STATUS_REVIEWED, 8);// 二进制 1000 $status 0; // 设置已支付和已发货 $status | STATUS_PAID; // $status $status | STATUS_PAID; $status | STATUS_SHIPPED; // $status $status | STATUS_SHIPPED; // 判断是否已支付 if (($status STATUS_PAID) ! 0) { /* 已支付 */ } // 清除已发货状态 $status ~STATUS_SHIPPED; // 按位取反后按位与只清除指定位 // 判断是否同时已支付且已发货 if (($status (STATUS_PAID | STATUS_SHIPPED)) (STATUS_PAID | STATUS_SHIPPED)) { /* 两个状态都为真 */ }这套玩法在权限系统里几乎是标准解。我记得在很多PHP论坛和CMS系统源码里都能看到$perms PERM_EDIT这种判断权限的写法。它相比多个布尔字段的好处是数据库只要一个int列查询时可以直接用WHERE status 1来筛选已支付单而不是拉回来在PHP里判断。在高并发订单查询里这种位条件的SQL过滤能减少大量不必要的行传输。再补充一个装状态位时的细节状态常量必须严格是2的幂也就是二进制里只能有一个1。如果你定义成了STATUS_PAID 3那它的二进制是0011会和STATUS_SHIPPED 2混在一起状态位之间互相污染清一个就把另一个也清了。这个坑我见不止一个人踩过排查时特别诡异。3.5 异或做值交换和“找出唯一重复数”^异或有两个特别好看的性质一个数异或自己等于0一个数异或0等于自己。引申出来的场景包括不用临时变量交换两个数?php $a 5; $b 9; $a ^ $b; // $a 5 ^ 9 $b ^ $a; // $b 9 ^ (5 ^ 9) 5 $a ^ $b; // $a (5 ^ 9) ^ 5 9虽然三条异或就能交换两个变量但在PHP日常业务里我其实不推荐用这个因为可读性差而且PHP本身交换变量用list结构就非常简单。它更适合的场景是在一堆成对的数里找出唯一落单的那个数。比如有一个数组里面除了一个数字只出现一次其他数字都恰好出现两次找出那个单数。?php function findUnique(array $nums): int { $result 0; foreach ($nums as $num) { $result ^ $num; } return $result; }原理还是那两个性质相同的数异或之后互相抵消变成0最后剩下的就是那个只出现一次的数字。这个技巧在算法题里很好用我在实际的“日志去重”“数据对账”场景里也用过类似的思路尤其是两个大列表要找“只出现在一边”的元素集合时异或出的结果能省下很多哈希表内存。3.6 获取正数的绝对值以及快速符号判断abs($n)大家都知道其实位运算也能做但PHP里我用下来这个替换价值不大因为abs()本身就是C级别的函数速度已经很快。真正值得说的是“判断两个数是否异号”?php // 两个数的符号位最高位不相同则异号 if (($a ^ $b) 0) { /* 异号 */ }原理一个有符号整数的最高位是符号位异或操作会把最高位不同的情况变成1异或结果最高位是1意味着结果为负数也就是原始两个数一正一负。这段代码在快速排序、双指针算法里用来判断“是否需要交换方向”很顺手比分别判断$a 0 $b 0要少几次比较。不过还是那句话PHP里大多数场景有现成的函数位运算替代的价值不在“任何一个算术都能换”而在“找到那个换完明显更快或者更简洁的点”。如果只是追求代码奇技淫巧而牺牲可读性那就不值当了。4. 数据说话我跑过的基准测试位运算到底快多少光说理论容易飘我实实在在压过一轮测试这里把环境、代码和结果都摆出来你可以自己复核。4.1 测试环境与方法PHP版本PHP 8.1.20CLI64位硬件4核CPU8GB内存Linux容器测试方法每个用例循环1亿次取总耗时用hrtime()测量高精度时间测试前把opcache关了因为我不想让缓存掩盖真实的引擎开销。另外每个用例我都在进程启动后先跑了一遍预热循环再正式计时防止第一轮各种初始化和页错误污染数据。4.2 测试代码?php function bench(callable $fn, int $times 100000000): float { // 预热 for ($i 0; $i 100000; $i) { $fn($i); } $start hrtime(true); for ($i 0; $i $times; $i) { $fn($i); } $end hrtime(true); return ($end - $start) / 1e9; // 单位秒 } $ops [ mod_even fn($i) $i % 2 0, bit_even fn($i) ($i 1) 0, mul_pow fn($i) $i * 8, shl_pow fn($i) $i 3, div_pow fn($i) intdiv($i, 8), shr_pow fn($i) $i 3, mod_64 fn($i) $i % 64, and_63 fn($i) $i 63, ]; foreach ($ops as $name $fn) { printf(%-10s %.4f 秒\n, $name, bench($fn)); }4.3 实测结果用例耗时秒备注$i % 2 07.632奇偶判断·算术($i 1) 06.114奇偶判断·位运算$i * 86.089乘法$i 36.102左移intdiv($i, 8)7.135整除$i 36.047右移$i % 647.598取模$i 636.083掩码取模结论一位运算整体比算术运算快但不是火箭版飞跃。最常见的几个替换场景里位运算能带来大约15%到25%的耗时下降。不要指望换了位运算程序就快一倍那是不现实的但如果你在热路径上跑这类操作几百万次累计收益是可观的。结论二$i * 8和$i 3几乎打平。在PHP 8里整数乘法本身已经被编译成高效的CPU指令左移并没有显著优势。所以“乘法换左移”这个替换收益不如“取模换掩码”明显后者才是真正的甜点。结论三intdiv()是最慢的右移比它快大约15%。intdiv()需要做额外的整数范围检查和异常分支处理右移直接丢位速度自然更快。如果你的代码里大量出现intdiv且除数恒为2的幂换成右移是稳赚不赔的。我不建议你拿这些数字当“绝对真相”因为不同PHP版本、不同CPU架构、不同操作系统下结果会有波动。但大的趋势不会变位运算在PHP里确实比等价算术操作占用更少的CPU时间原因是省去了引擎层的类型检查和辅助逻辑。4.4 什么情况下别指望位运算的性能优势位运算速度再快如果你的使用场景不正确也发挥不出来。我总结了几种“白换”的情况操作数不是整数而是数组、对象或字符串PHP要先转换转换成本直接吞掉位运算收益。函数内部做了大量额外工作比如你要在循环里调用array_map再位运算那瓶颈根本不在位运算上。已经把算术操作封装成了C函数比如abs()、min()、max()这些直接调C函数和zend引擎交互很快位运算不一定能超越它们。你的业务逻辑本来就不在CPU上如果你的瓶颈在数据库查询、外部API调用那优化位运算纯属南辕北辙。先profile再优化这句话我说一万遍都不嫌多。5. 替代之前先想清楚位运算的五块绊脚石位运算不是没有代价的。作为一个在线上环境里吃过亏的过来人我把这些坑按严重程度排个序每个都值得你重视。5.1 坑一负数的右移与取模行为容易翻车前面提过PHP右移负数时是算术右移补符号位。这意味着-8 1等于-4挺符合直觉。但是-7 1等于什么答案是-4因为算术右移是向负无穷方向取整相当于floor(-7 / 2)等于-4。这就和一个没接触过位运算的同事的第一直觉“-7除以2等于-3.5取整应该是-3”产生了冲突。代码review时如果双方对“取整方向”认知不一致bug就埋下了。另外负数取模和掩码也有坑。比如-9 7在PHP里结果是7。但-9 % 8的结果是-1。这两个结果完全不同原因还是那个只保留最低3位相当于对正数部分做取模而负数的%运算保留了符号。所以如果你在业务里要对可能为负的值进行“取模分桶”比如订单id可能生成时带负号虽然少见那么 (n - 1)会把负id分到正桶里行为完全不是取模语义。用掩码做取模前必须确保操作数非负。这里我贴一个保险写法如果实在无法保证非负?php // 安全掩码取模先转成无符号语义再位运算 $bucket (($num % 64) 64) % 64; // 或者更直接$bucket $num 63; 仅限 $num 0但说实话既然都用位运算优化了还搞这么啰嗦就本末倒置了。最好是在数据源头保证非负或者在分桶前写一个断言把异常值拦下来。5.2 坑二移位数超过操作数位宽结果不可预期在PHP里1 64在64位机上结果是1。为什么因为64位的int左移64位相当于把所有位都移出去了按C语言的说法这是“未定义行为”而PHP会给你一个看似合理的值——1。还有人遇到过1 63在64位机上得到负数的情况因为符号位被置1了整个数变负。这在业务里是灾难级别的bug但不容易立刻发现。因此做位移操作时位移量必须在0到当前平台int位宽-1之间而且位移后还要确保符号位不被意外置为1。如果你在写分片、哈希、布隆过滤器这类玩位的代码务必加上边界检查?php if ($shift 0 $shift PHP_INT_SIZE * 8) { $result $value $shift; } else { // 处理异常 }这种判断虽然会损失一点性能但配合错误日志能帮你及早发现非法输入。在线上环境我宁可慢1%也不愿意数据悄悄错掉。5.3 坑三可读性断崖式下跌团队协作成本飙升这是我至今认为最关键的一点。位运算代码写得飞快的代价是没有一定基础的人根本看不懂你在干嘛。比如?php $isAdmin ($user-perms 0x1F) 0x1F;这是一行很经典的位运算判断“同时拥有5个基础权限”的代码但一个刚入行的同事看到这行大概率会原地愣住然后去翻文档查0x1F是什么。相比之下一段清晰的$user-hasAllPermissions([PERM_A, PERM_B, PERM_C, PERM_D, PERM_E])虽然慢一点但任何一个人都能秒懂。我的处理原则是性能敏感的核心路径用位运算同时必须伴随足够详细的注释非性能敏感的业务逻辑老老实实写可读性高的版本。注释要写清楚“为什么这里是0x1F而不是直接写5个true”并且把每个权限位的二进制扩展列出来方便后来者验证。5.4 坑四运算符优先级比你记忆中更容易出错PHP运算符优先级里有一个经典陷阱和的优先级比 -要低但和比较运算符的关系又很微妙。看这段代码?php // 预期判断 ($a 1) 1 if ($a 1 1) { ... }实际执行时PHP先把1 1给算成了true然后$a true再做按位与结果完全跑偏。这种事太常见了几乎每个用位运算的开发者都在某个时刻栽过。所以我的铁律是位运算和其他运算混在一起时一律加括号不要相信你的记忆也不要相信同事的记忆。if (($a 1) 1)看起来多两个括号但省掉的排查时间远远超过它的成本。5.5 坑五跨平台整数宽度不一致32位环境直接崩给你看PHP在32位平台上的int范围只有64位平台的一半1 31在64位下是个正常数值在32位下直接溢出变成最小值甚至0。如果你们的项目要部署到老旧32位服务器上或者你的代码库会被别人拿到32位环境跑所有位移量超过31的代码都要重新审查。现代服务器基本都64位了但写类库、写开源包的人还是要考虑这个兼容性。最简单的规避方式所有位运算都基于PHP_INT_SIZE动态判断别写死64。6. 从课堂到生产我在真实项目里的两个应用案例分享两个我实际做过、并且上线验证过效果的优化案例一个是协议解析一个是权限系统重构。这两个案例能让你看到位运算在非算法题环境里的价值。6.1 案例一NTP时间戳解析把CPU占用降下来我们有一个NTP时间同步服务专门给内部设备做时间校准单机峰值每秒要处理几万个NTP请求。NTP协议的时间戳是64位结构前32位是秒数后32位是小数的秒网络字节序传输。解析时最繁琐的操作是“把64位拆成高32位和低32位”再看看是否需要调整闰秒。传统写法是拼接字符串或者直接用unpack把64位拆成两个32位无符号整数再进行浮点运算。实测下来unpack频繁调用和后续的浮点除法的CPU开销很大。我在优化里保留了unpack取原始数据但把秒数和毫秒数的换算改成了位运算?php // 从64位时间戳中提取高32位秒数 $seconds $raw 32; // 低32位是小数部分取前22位作为毫秒精度 $fraction ($raw 0xFFFFFFFF) 10; $milliseconds ($fraction * 1000) 22;这里 32直接完成“高32位提取”比传统的除法intdiv($raw, 4294967296)快 0xFFFFFFFF提取低32位比多余的二次unpack快。改完之后NTP解析函数的CPU占用下降了大约18%虽然绝对数值很小但在几万个请求每秒的规模下这个收益让同一台服务器可以多扛几千个并发连接。不过这里的$raw必须保证是无符号语义的正整数。如果PHP收到一个高位超过63的值这部分提取逻辑也会出问题所以我在解析入口做了范围校验非法包直接丢弃。6.2 案例二权限系统从多个bool字段改成位掩码一举两得另一个案例是内部管理后台的权限模块。老系统的用户表里有is_admin、can_edit、can_delete、can_export等七八个布尔字段每次查询权限都要带上一串条件新增一个权限类型还得加字段、改表、改ORM映射。我重构时把它们合并成一个perm_flags整数列用位掩码定义权限?php define(PERM_LOGIN, 1 0); // 1 define(PERM_READ, 1 1); // 2 define(PERM_WRITE, 1 2); // 4 define(PERM_DELETE, 1 3); // 8 define(PERM_EXPORT, 1 4); // 16 define(PERM_MANAGE, 1 5); // 32查询“有写权限的管理员”时SQL里直接写WHERE (perm_flags 2) ! 0MySQL对整数位的操作非常快索引还能命中。应用层判断“是否有写或删除权限”也是一条($perms (PERM_WRITE | PERM_DELETE)) ! 0就搞定。上线后权限表从8个布尔列变1个整数列单行存储变小索引效率提升而且新增权限类型不再需要改表结构只要新增一个常量然后给对应角色的perm_flags按位赋值即可。维护成本肉眼可见地下降。这也让我确信位运算替代算术的价值很多时候不在“快了多少”而在“少维护了多少”。7. 写给准备上手的你我的几条实操建议到这里位运算替代算术的核心内容已经全部讲完了最后分享几条我在写法和选择上总结出的经验。任何性能优化先profiler后动手。用Xdebug或者Tideways跑一次真实流量确认CPU热点在哪些代码上。盲改位运算很可能改了个寂寞。优先替换取模和奇偶判断而不是乘法。根据我的实测取模换掩码、奇偶判断换 1的收益最明显乘法换左移收益很小。位运算只用在纯整数且恒为正数的场景。负数、浮点数、未知类型输入一律先明确转换规则否则就不要换。写得快不算本事同事看得懂才算。位运算代码必须有注释注释里要写清楚“这个2的幂掩码是从哪来的”“为什么不直接写算术运算”。用常量名字代替魔法数字。比如$status STATUS_PAID就比$status 1可读性高得多。宁可多写几行也要把每一位的含义钉死。在代码评审里专门拉一条“位运算规范”操作数必须加括号、掩码必须是2的幂减1、位移必须在位宽范围内、负数操作需显式断言。把坑提前挡在仓库外面。我个人的体会是位运算替代算术这件事更像是一把手术刀而不是一把万能钥匙。找准了切口它能精准放下你代码里的冗余计算用错了地方它会切开一条让人看不懂的血淋淋的口子。大家上手时不用贪多先从奇偶判断和2的幂取模这两个最安全的场景练手跑通了再逐步扩展到状态位和掩码设计。慢慢你会发现用位运算思考问题本质上是在用计算机的“母语”和数据交流那种打开新视角的感觉比单纯的性能提升更有意思。