Cadence智能合约：前置/后置条件与assert语句的区别及选型考量

先明确共同点 #

不管是前置/后置条件，还是assert语句，都绝对不能包含任何状态变更操作——比如修改合约存储变量、调用外部写函数这类行为，一旦出现直接违反校验逻辑的设计原则。

核心语义区别 #

二者的本质差异体现在「校验目的」上：

• 前置/后置条件：用来校验业务逻辑层面的预期规则——比如用户输入是否合法、函数调用的前提是否满足、执行后的结果是否符合预期。说白了，这是给「用户操作」或「外部交互」做的校验，失败往往是因为使用者没按规则来。
• assert语句：用来校验合约内部的「不变量」——也就是那些理论上绝对不能被打破的逻辑，比如数学运算的正确性、内部状态的一致性。一旦assert触发，说明合约本身存在bug，属于开发者的逻辑失误。

适用场景分清楚 #

优先用前置/后置条件的情况

• 校验函数调用者的权限（比如onlyOwner逻辑）
• 校验输入参数的合法性（比如转账金额不能为0、不能超过用户余额）
• 校验外部调用的返回结果（比如ERC20转账是否成功）
• 校验函数执行后的预期状态（比如转账后用户余额是否正确更新）

优先用assert的情况

• 校验内部状态的一致性（比如总供应量等于所有用户余额的总和）
• 校验数学运算的正确性（比如除法操作后余数为0、避免溢出/下溢）
• 确保不会到达的代码分支（比如理论上永远不会触发的else分支）

Gas消耗差异 #

• 前置/后置条件（通常用require实现）：校验失败时会退还剩余未使用的Gas，只消耗校验过程的Gas成本。这很合理——毕竟错误是用户操作导致的，没必要让用户承担全部Gas损失。
• assert语句：校验失败时会消耗掉所有剩余Gas。因为assert是用来检测合约bug的，一旦触发说明合约逻辑有严重问题，没必要保留Gas给后续操作。

错误可读性差异 #

• 前置/后置条件：可以通过require(condition, "明确的错误提示")自定义错误信息，用户和开发者能快速定位问题原因，比如「余额不足」「无调用权限」。
• assert语句：虽然Solidity 0.8+支持添加错误信息，但语义上不推荐这么做。默认触发时只会抛出Panic错误，开发者需要通过调试工具才能定位具体的bug位置。

内容的提问来源于stack exchange，提问作者Satyam Agrawal