Solidity中assert耗尽全部Gas的设计目的是什么？

为什么assert会耗尽剩余Gas？ #

核心原因在于EVM底层的 opcode 设计：assert触发时调用的是INVALID（0xfe）操作码，这个操作码的特性就是消耗所有剩余Gas；而require用的是REVERT（0xfd）操作码，会自动返还未使用的Gas。

这种设计的本质是为了区分两类完全不同的错误：

• require针对的是可预期的、合法的失败场景（比如用户输入非法、转账余额不足），这类错误是业务逻辑中允许出现的，返还Gas是为了避免用户为合法失败付出不必要的成本。
• assert则是用来检测绝对不应该发生的逻辑漏洞（比如旧版Solidity的整数溢出、内部状态变量不一致、代码分支逻辑矛盾）——这类错误属于合约开发的bug，不是业务逻辑的一部分。耗尽剩余Gas的设计，一方面是强制开发者重视这类严重问题（必须修复，而不是忽略），另一方面是防止攻击者利用这类异常状态进行低成本探测或恶意操作（毕竟耗尽Gas会让攻击成本大幅提升）。

能否新增类似require但不耗尽Gas的关键字？ #

从功能需求来看，其实现有语法已经能实现类似效果——比如用自定义错误配合revert，既能标记逻辑错误，又能返还剩余Gas。但如果专门新增关键字，从Solidity的设计原则来说并不必要：
Solidity的关键字设计一直追求简洁，且核心是明确区分错误类型。如果新增一个“不耗Gas的assert”，会模糊“可恢复业务错误”和“不可恢复逻辑bug”的边界，导致开发者滥用，把本应是必须修复的bug当成普通业务错误处理，埋下合约隐患。目前Solidity团队也没有相关的新增计划，因为现有机制已经能覆盖所有合理的错误处理场景。

尽可能少耗Gas难道不是更优选择？ #

这要分错误类型来看：

• 对于合法的业务失败场景，少耗Gas确实更优，这也是require返还Gas的原因。
• 但对于逻辑bug类的错误，此时合约的内部状态可能已经异常，继续执行或返还Gas反而会带来风险：攻击者可以反复触发这类错误，用极低的Gas成本探测合约漏洞；或者利用异常状态执行未预期的逻辑。耗尽剩余Gas的设计，既能大幅提升攻击成本，也能强制开发者必须修复bug，而不是让合约带着隐患运行。所以并非所有场景都要追求少耗Gas，错误的性质决定了最优的处理方式。

Solidity是否应对相关功能做出调整？ #

目前来看，现有设计是合理且成熟的：
assert和require的区分已经成为Solidity开发的通用规范，也被各种静态分析工具、审计流程所依赖——工具可以通过识别assert来定位潜在的逻辑漏洞，通过require识别业务校验点。如果调整assert的Gas行为，会打破这套成熟的生态，增加开发者和工具的适配成本。

另外，Solidity已经引入了自定义错误，允许开发者用更灵活、低Gas的方式处理各种错误场景，包括标记逻辑错误。对于需要在运行时返回错误提示且不耗Gas的场景，自定义错误+revert已经是更优的解决方案，不需要修改assert的原有设计。

内容的提问来源于stack exchange，提问作者Behnia FB