Dirty Coding Tricks：四个偏门技巧提升代码效率与性能

Dirty Coding Tricks 这个系列写到现在已经是第三篇了，后台一直有人在问同一个问题：到底什么样的代码才算 dirty？我的回答一直没变——不是让你写烂代码，不是教你把项目搞成一坨只有自己能看懂的浆糊，而是指那些第一眼看上去不太正经、但用好了异常高效的偏门招数。真正的高手不是不用 dirty tricks，而是知道哪一扇门背后藏着一条近路，也知道这条路什么时候会塌。

第三部分我打算换个路子，不再像前两篇那样搞大而全的清单式总结，而是挑几招我在真实项目里用过的、被代码评审怼过、也被性能优化救过的招数，把它们掰开揉碎讲清楚。包括短路求值、位运算、函数默认参数的冷门行为、以及动态执行代码的边界问题，每一招都会附上适用场景、翻车案例和改进方案。适合已经写了一阵子业务代码、想提升代码手感的人参考，也欢迎维护老项目、经常和屎山打交道的朋友一起探讨。

1. 先聊聊这个系列怎么选材

1.1 我筛选“脏技巧”的三个标准

网上关于代码技巧的内容铺天盖地，但大部分要么太理论、要么太玩具。我做这个系列的时候给自己定了三个硬指标，凡是通不过的内容一律不写。

第一，它必须能解决真实问题。不是展示语言特性有多酷，而是这招放进去之后，代码确实变短了、变快了、或者变好维护了，至少占一样。第二，它必须是在常规文档里不容易找到的。像map、filter、reduce这种已经被讲烂的 API 我不会当成 trick 来写，那只能算基础用法。第三，它必须带有两面性。如果一个技巧全是好处没有代价，那它早就成为最佳实践了，不需要我来写。所以我写的每一条都会把风险边界讲清楚——适合哪里、不适合哪里、会坑到什么样的人。

这三个标准筛下来，真正能写的其实不多。这一期最终选了六个方向，其中四个作为正文详细展开，另外两个放在常见问题里当作反面教材。这样既能保证干货密度，又能让读者看清楚脏技巧的真实样貌。

1.2 这期选了哪些方向，为什么选它们

这期的选材逻辑可以概括成一句话：从三个维度找代码痛点。一是样板代码太多的地方，二是性能瓶颈集中在某一行的时候，三是逻辑判断容易漏掉边界条件的场景。

样板代码多的场景特别适合用短路求值来压缩。比如需要层层判空之后再取值、需要根据某个条件决定要不要执行函数，常规写法会铺出一个金字塔结构，而短路求值能把这种判断拍平成一行。性能瓶颈的典型代表是循环体内的位运算替换，尤其是在图像处理、权限判断、数据序列化这些高频场景里，位运算带来的提升是实打实的。至于边界条件，函数默认参数和哨兵值玩好了能堵住很多隐式 bug，但玩不好也会制造出最诡异的故障，所以我会花比较多篇幅讲它的坑。

每一个方向我都会用一个具体的代码场景来演示，而不是把语法特性生硬地堆出来。方便你对号入座，判断自己项目里有没有类似的问题。

2. 四招偏门技巧逐一拆解

2.1 短路求值：把五层 if 压成一行

短路求值不是什么新鲜概念，几乎所有的编程语言里，&&和||都会根据左侧结果决定要不要计算右侧表达式。但大部分教程讲到这里就停了，只告诉你“短路可以用来避免空指针”。实际项目里这招能玩出的花样远不止这些。

最常见的用法是替代简单 if。比如在 JavaScript 里，用户登录之后要刷新一下用户信息，常规写法是这样的：

if (user !== null && user.isLoggedIn) { refreshUserInfo(user.id); }

用短路求值可以直接写成：

user?.isLoggedIn && refreshUserInfo(user.id);

第一行代码在逻辑上没有任何问题，但当你面前有十好几个这种判断的时候，缩进层级会变成一个灾难。短路写法能把这些判断压缩成一行表达式，阅读的时候视线不需要来回扫。

在 Python 里也有类似的操作，但有个细节要格外注意。Python 的and和or返回的并不是布尔值，而是参与运算的对象本身。这就导致一个经典陷阱：

result = get_user_name() or "anonymous"

这段代码的本意是获取用户昵称，拿不到就给个兜底值。如果get_user_name()返回空字符串""，这个表达式会返回"anonymous"，看起来没问题。但如果返回的是0或者False，同样会走兜底逻辑。在有些场景下0是合法数据，比如用户的积分可能真的是 0 分，这时候就会出大问题。

所以我对短路求值的建议是：用在“有没有值”的判断上很安全，但千万不要用在“值是否合法”的判断上。后者应该老老实实走is None或!== undefined的显式检查。

2.2 位运算：高分屏背后的隐形加速器

位运算在业务代码里确实用得少，但少不等于没用。我做运营后台的时候遇到过一个性能问题：一张几十万行的数据表，每行要判断多个不同的状态位，用常规方式写条件判断，接口要 800 多毫秒；后来换成位掩码，直接压到 60 多毫秒。这个差距不是语言层面的优化能弥补的，纯粹是数据结构和运算方式变了。

位运算的核心思路是把多个布尔开关打包进一个整数里。比如一个订单可能有“已支付”“已发货”“已评价”“已退款”四种状态，常规做法是四个字段，或者一个字段存 JSON 数组。位运算的做法是定义四个常量：

const PAID = 1 << 0; // 1 const SHIPPED = 1 << 1; // 2 const REVIEWED = 1 << 2; // 4 const REFUNDED = 1 << 3; // 8

判断一个订单是否同时满足“已支付”和“已发货”，只需要：

const status = PAID | SHIPPED; if ((status & (PAID | SHIPPED)) === (PAID | SHIPPED)) { // 两个状态都满足 }

这段代码对不熟悉位运算的人来说有点像天书，但对 CPU 来说这就是一次与运算加一次比较，快得离谱。位掩码擅长做组合状态的交集判断、异或判断和取反判断，在权限系统里也特别好用。一个用户整数就能代表它在几个部门、拥有几个角色，这是字符串数组或者关联表做不到的密度。

但这里必须警告一下：位运算在 JavaScript 里有 32 位整数的限制。JS 里的位运算符会把操作数先转成 32 位有符号整数，超出这个范围的数字直接算错。真实的业务 ID 一旦超过这个范围，你在数据清洗时用它做奇偶判断，会得到莫名其妙的结果。建议只用于状态位、开关组、颜色值这类本身可枚举的数据结构，不要拿来做大数据运算。

2.3 默认参数与哨兵值：函数签名的隐藏玩法

大多数语言都支持函数默认参数，常规用法是给参数一个兜底值。但默认参数真正脏的玩法是配合哨兵值做函数重载，或者在 Python 里利用可变默认参数做缓存。

先看一个 JavaScript 里的常见场景。你要写一个分页函数，page 参数不合法时需要回退到第一页：

function fetchList(page, pageSize = 20) { page = page || 1; // ... }

这个写法有两个问题。第一，page传0的时候也会被重置成 1，虽然大多数场景下页数从 1 开始，但谁也不能保证将来不会有从 0 开始的业务。第二，pageSize默认值是 20，但如果你真的想传一个pageSize = 0，这种写法就直接废掉了。

更稳的做法是用undefined做哨兵值：

function fetchList(page = 1, pageSize = 20) { // 只有传 undefined 时才使用默认值，传 null、0、'' 都会保留原值 }

ES6 的默认参数和null的另一个区别很值得记住：page = 1只有在传undefined的时候才会生效，传null会保留为null，传0也会保留为0。很多新手在这里翻车，以为默认值是万能的兜底，结果在页面上看到页面数变成了 null 报错。

Python 的可变默认参数是个经典的反模式，但换个角度看它也是个经典的缓存技巧：

def process_item(item, cache=[]): if item not in cache: cache.append(item) return cache

所有人都告诉你别这么写，因为默认列表是共享的，多次调用之间数据会互相污染。但如果你故意利用这个特性，它就是一个简单的跨调用缓存区。我见过有人拿这个特性做函数级 LRU，代码量大幅减少。不过我必须强调，这种写法在团队协作里非常危险，因为后来者默认不会意识到这个参数是有状态的。用过一次之后，我的体会是：要么在函数注释里写清楚，要么干脆别玩这个。

2.4 动态执行：能不用就不用，但用了真香

动态执行指的是在运行时把字符串当代码执行的机制，类似 JavaScript 的eval、Python 的exec。所有人都警告你别用 eval，理由是安全问题、性能问题、调试地狱。但反过来想，有一些场景天然就适合动态执行，比如需要支持用户自定义过滤公式、需要从配置文件里读取表达式、需要实现一个简单的规则引擎。

我之前做过一个给运营同事用的活动配置后台，活动门槛需要支持“用户等级大于3且累计消费满500”这种灵活规则。如果每个规则都写死在代码里，运营每调整一次就得发一次版，这谁受得了。后来我采用了表达式字符串的方案：运营在后台编辑规则表达式，前端校验语法，后端在沙箱里执行。核心代码其实很短：

const evaluateCondition = (condition, context) => { const allowedKeys = Object.keys(context); const args = allowedKeys.map(k => context[k]); const fn = new Function(...allowedKeys, `return (${condition});`); return fn(...args); };

用new Function替代eval有个好处：它不会访问当前作用域的局部变量，只能拿到你显式传进去的参数，攻击面小了很多。即便如此，我还是加了两道保险：一是表达式只允许通过白名单函数操作数据，二是用正则把所有形如process、require、global的敏感字段替换成安全占位符。

动态执行的正确打开方式，是把边界收紧到极致：白名单限定可访问变量、正则过滤敏感字段、超时机制防止死循环、日志记录所有执行内容。做不到这几点的动态执行，就是在给系统埋雷。

3. 实操：把一个配置取值函数改造成 dirty 版本

3.1 场景设定与常规写法

抖了这么多理论，现在来一个能直接参考的实操。假设你有一个嵌套很深的配置对象，需要按照字符串路径取值：

const config = { db: { host: "10.0.0.1", options: { pool: { min: 2, max: 10 } } }, cache: { enabled: true, ttl: 3600 } };

业务方会传这样的路径进来："db.options.pool.min"，需要拿到2。如果路径不存在，返回默认值。

常规写法是先按.分割，然后循环取值：

function getValueByPath(obj, path, defaultValue) { const keys = path.split("."); let current = obj; for (let i = 0; i < keys.length; i++) { if (current === null || current === undefined) { return defaultValue; } current = current[keys[i]]; } return current === undefined ? defaultValue : current; }

这段代码很稳，每个细节都考虑到了，但缺点是循环体里的判断逻辑很啰嗦，如果项目里有好几个类似函数，维护起来会让人头大。

3.2 改造过程：从循环到 reduce 的一行流

接下来把它改造成利用 reduce 的版本。reduce 本身就是一种折叠操作，天然适合从一个集合中逐层推导出最终结果：

const getValueByPath = (obj, path, defaultValue) => path.split(".").reduce((acc, key) => (acc ?? {})[key], obj) ?? defaultValue;

这段代码的核心是(acc ?? {})[key]：当acc为null或undefined时，用一个空对象去取key，结果自然是undefined，后面的继续取值也都是undefined，最终由?? defaultValue兜底。空值合并运算符??只处理null和undefined，不会像||那样误伤0和false，所以取值结果是合法的0或false时会原样返回。

实测对比一下，这个版本比循环版少了一半代码，执行效率上只要原始对象层级不是特别深，两者差距基本在纳秒级。更重要的是它没有for循环，不会出现索引溢出的问题，少了一种出错的可能。

3.3 改造前后对比与落地建议

我的建议是：这种改造适合用在配置读取、模板渲染、表单数据提取等路径固定且层级可控的场景。如果路径中可能出现数组索引，比如"users.0.name"，这个版本依然能直接工作，因为[key]对数字索引同样有效。

但如果是高并发的核心请求链路上的信息获取，我反而建议用回循环版。原因不是性能，而是可调试性。一行流在出错时堆栈信息很简短，你很难直接看出是哪个环节出了问题；而循环版每一轮取哪个 key 都暴露在 stack 里。脏技巧的核心不是追求最短，而是知道什么时候该短、什么时候该长。

4. 常见问题：这些技巧在真实项目中翻车的样子

4.1 短路求值忽略了函数的返回值

有一次我在代码评审时看到这样一个写法：

user.updateProfile(profile) && notifyAdmin(user.id);

这行代码的意图是更新完资料后通知管理员。表面看逻辑没问题，但updateProfile返回的是什么？如果它返回的是更新后的对象，那么这个对象永远是 truthy，第二段永远会执行。如果它返回的是保存失败时的undefined，第二段才会被跳过。可问题是，函数重构之后某一天返回值从布尔值变成了其他类型，这个判断就悄悄失效了。

短路求值最怕的就是“依赖函数返回值做判断，但函数返回值没有稳定契约”。保险的做法是把第二段抽出来，单独判断第一段是否成功，别把非布尔返回值当布尔用。代码长一点没关系，逻辑稳了才是真省事。

4.2 位运算把数字玩成 32 位

有一次我帮同事排查一个数据同步的 bug，每天的日期转成时间戳之后取模，结果在特定日期计算出负数。查了半天才发现他用了~~取整法：

const timestamp = Date.now(); const day = ~~(timestamp / 86400000);

原理上~~可以做快速取整，但 JS 位运算强制把操作数转成 32 位整数。当时的时间戳已经超过了 32 位能表示的上限，取整结果就完全不对了。

在数据量不大、时间范围内固定的小程序里，这类位运算技巧很诱人，但一旦数据规模增长到某个临界值，它就会变成定时炸弹。用之前想想看：你的数值可能超过 21 亿吗？可能超过 20 亿分之一秒的时间戳吗？如果可能，就别用位运算处理这个值。

4.3 可变默认参数导致的幽灵数据

Python 的可变默认参数是公认的坑，但它在真实项目里翻车的频率依然很高。一个很常见的案例：

def add_tag(tag, tags=[]): tags.append(tag) return tags

开发第一次调用的时候传了["python"]，返回结果正常；第二次调用只传了一个 tag，结果发现返回列表里莫名其妙多了上次的"python"。这种现象在测试里尤其可怕，因为用例与用例之间的数据会相互影响，定位问题的时候很容易怀疑是业务逻辑的 bug。

规避方案其实很简单：不要用可变对象做默认值。改成None然后判断：

def add_tag(tag, tags=None): if tags is None: tags = [] tags.append(tag) return tags

代码变长了，但每次调用都重新创建新列表，彻底规避了共享状态问题。如果真要用上一节提到的缓存技巧，建议做个内部缓存变量，而不要用默认参数做缓存。至少这样别人阅读代码时能明确看到“这里有缓存”的设计意图，而不是被隐蔽的副作用坑到。

4.4 一张速查表：什么时候该用什么时候该跑

这套表是我自己项目里的一个裁量工具。踩过几次坑之后，我总结出一个核心原则：脏技巧的使用范围要和代码的“存活时间”成反比。一次性跑完就丢的脚本，怎么 dirty 都无所谓；长期维护的公共代码，还是能稳则稳。如果一个技巧让你在写的时候暗爽，却要让同事在改的时候翻白眼，那它大概率不是技巧，而是事故的代名词。

我在实际项目中用这套技巧用得最过瘾的一次，是把一个核心数据清洗工具从两百多行压缩到四十几行，整个处理链路全部用位掩码和短路表达式代替了传统的条件和循环。运行效率提升了两倍，同事看了代码愣了半天，我只好在关键行上面补了几行注释解释。那段代码后来被改过三次，每次改完都能保持最初的清晰结构，没有出现连锁问题。这让我越发坚定一个判断：dirty 的意义从来不是炫技，而是让代码在复杂度和维护成本之间找到一个更优的平衡点。如果你的技巧只有你自己看得懂，那不是优化，是在给后人挖坑。

最后再分享一个小经验。我在写这一类技巧时，会随手在代码注释里留下两行字：一行写“为什么要这么写”，一行写“如果用常规写法会有什么问题”。这个习惯不值钱，但能救很多次急。代码是写给机器执行的，更是写给下一个接手的人看的。要是他看不懂你的操作，再快的性能也弥补不了团队整体效率的损失。