智能合约条件语句怎么写才能不出漏洞

智能合约跑在区块链上，代码一旦部署就不可更改，条件语句写错一个符号，轻则功能失灵，重则资金被锁死甚至被黑客掏空。我见过太多项目方在if-else上栽跟头，所以这篇内容不聊虚的，直接讲条件语句开发里最要命的几个点，帮你避开那些坑。

条件判断里最容易忽略的边界值

写智能合约条件语句，第一反应是判断“大于”或“小于”，但很多人忘了处理等于的情况。比如一个空投合约，要求用户余额大于0才能领取，你写if(balance > 0)，那余额正好等于0的用户就被排除在外，这没问题。但如果是分红合约，要求余额大于等于某个阈值，你写成if(balance > threshold)，那刚好达到阈值的用户就领不到钱，用户会骂娘，合约逻辑也不符合预期。

另一个高频坑是整数溢出的边界。Solidity 0.8版本之前，整数溢出不会报错，而是自动回绕。比如uint8最大值是255，你加1变成0，条件判断if(count + 1 > 5)在count等于255时反而成立，逻辑直接崩了。0.8之后默认带溢出检查，但如果你用unchecked块包裹，溢出检查就被跳过了，这时候条件语句里的算术表达式必须自己保证安全。

还有时间戳的边界。很多合约用block.timestamp做截止时间判断，比如拍卖截止到某个时间点。你写if(block.timestamp >= deadline)，那在deadline那一秒出价，会被拒绝还是接受，取决于你用的是>=还是>。这里没有绝对对错，但必须跟产品需求对齐，否则用户卡着点操作，结果跟预期不符，纠纷就来了。

多重条件嵌套如何避免逻辑混乱

条件语句嵌套太深，代码读起来像迷宫，审计人员看了头疼，你自己过两个月回来看也懵。一个常见场景是白名单加限购加时间窗口，三个条件叠在一起，有人会写成三层if套娃。这种写法不是不行，但一旦某个分支漏了else，或者某个条件取反写错，排查起来非常痛苦。

更好的做法是把每个独立条件拆成修饰器或者单独的函数。比如判断用户是否在白名单，单独写一个modifier onlyWhitelist()，判断是否在限购数量内，单独写一个modifier withinLimit()，然后在函数上叠加使用。这样每个条件逻辑单点维护，出错概率大幅降低，代码可读性也高很多。

另外要注意条件语句里的状态变量更新顺序。比如你先判断余额是否足够，再扣款，再更新状态，这个顺序是对的。但如果你先更新状态再判断，一旦判断失败回滚，状态还能恢复吗？Solidity里revert会回滚整个交易的状态变化，所以顺序问题在单次交易里影响不大，但在跨合约调用或者回调函数里，顺序错了可能导致重入攻击。条件判断里涉及外部调用的，务必先改状态再调外部合约，这是防重入的铁律。

条件语句开发的核心就一句话：把边界想清楚，把嵌套拆干净，把状态变更顺序锁死。别嫌麻烦，合约部署上去改不了，多花十分钟检查条件逻辑，能省下后面几万U的审计费。你写条件语句的时候，多问自己一句：如果这个条件刚好卡在临界值，会发生什么？想明白这个，你的合约就稳了一大半。