Foundry Forge Lint 规则实战write-after-write冗余存储写入检测与 Gas 优化指南【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry本文围绕 Foundry 项目forge lint内置的write-after-write规则展开系统讲解它如何识别写入存储后、在被读取之前就被再次覆盖的死写入模式剖析其背后的 Gas 浪费原理、规则边界与源码实现并给出可复制的触发示例、推荐写法、配置启用方式与已知局限。读完本文你将能够在自己的 Solidity 合约中准确识别并消除冗余的存储写入同时理解该检测器何时会漏报或误报。该规则以 crates/lint/docs/write-after-write.md 为权威文档本文结合其实现源码 crates/lint/src/sol/gas/write_after_write.rs 与完整测试用例 crates/lint/testdata/WriteAfterWrite.sol 进行深度扩充。规则概览Severity 与 ID属性值规则名称Write after writeSeverity严重级别GasID规则标识write-after-write诊断消息redundant storage write; value overwritten before being read在源码中该规则通过declare_forge_lint!宏注册见 crates/lint/src/sol/gas/write_after_write.rs#L18-L23declare_forge_lint!( WRITE_AFTER_WRITE, Severity::Gas, write-after-write, redundant storage write; value overwritten before being read );并在 crates/lint/src/sol/gas/mod.rs#L22 中以late阶段语义分析后执行注册进 Gas 严重级别分组write_after_write: (WriteAfterWrite, late, (WRITE_AFTER_WRITE));What it does检测什么该规则报告的是对状态变量的赋值其写入的值在真正被读取之前就被再次覆盖。具体来说它跟踪已被写入、但尚未被任何读取观察过的状态变量一旦发现对同一变量再次写入前一次写入即为冗余dead write并以前一次写入的位置为锚点发出诊断。规则文档明确列出了以下排除项复合赋值compound assignment如x 1不触发——因为复合赋值本身会先读取旧值再写入对单个 mapping 条目、数组元素或结构体字段的写入不触发——因为这类写入无法确定是否命中同一个存储槽例如balances[a]与balances[b]很可能指向不同槽位。触发示例原文档给出的经典触发示例crates/lint/docs/write-after-write.md#L19-L30contract C { uint256 public x; function bad(uint256 v) external { x 0; // write-after-write: this value is never read x v; // second write overwrites the first } }第一行x 0的值从未被任何读取消费紧接着的x v将其覆盖x 0就是典型的死写入。推荐写法contract C { uint256 public x; // Write once with the final value directly. function good(uint256 v) external { x v; } // Reading between writes is fine. function goodRead(uint256 v) external returns (uint256 prev) { x 1; prev x; // x is read here x v; } // Compound assignments read before writing, not flagged. function goodCompound() external { x 1; x 1; } }三种安全模式一目了然直接写入最终值两次写入之间插入一次读取使用复合赋值让读-改-写合并。Why is this bad为什么浪费 Gas向存储写入数据SSTORE指令是 EVM 中最昂贵的操作之一。将值写入存储后立即再次覆盖如果编译器没有消除第一次写入就会白白多付一次存储写入的 Gas。需要特别强调的是文档原文每次写入的成本并不固定它取决于槽位访问历史与所写值槽位在本次交易内从未写过cold slot写入非零值最昂贵槽位若曾在本交易内写过再次写入的成本会大幅降低warm slot写入零值、或在重置零值等场景下成本又不同。因此write-after-write带来的浪费是一个随上下文浮动的量不能一概而论地说每次冗余写入固定浪费多少 Gas。文档同时给出了一个重要的修复约束Remove the first assignment only when evaluating its right-hand side has no required side effects.即只有在前一次赋值的右值表达式没有必需的副作用时才应该删除第一次赋值。例如// 右值有副作用删除 x f() 会丢失 f() 的调用 x f(); // f() 的副作用不可丢弃 x v;这种场景下应保留第一次赋值或改写逻辑而不是机械地删除。规则边界什么算、什么不算原文档只给出了三类基本排除项而仓库中的测试文件 crates/lint/testdata/WriteAfterWrite.sol 将规则边界扩展到了数十种真实语法形态。测试通过//compile-flags: --only-lint write-after-write仅启用本规则其期望输出记录在 crates/lint/testdata/WriteAfterWrite.stderr。会被标记bad的形态形态示例说明连续两次普通赋值x 1; x 2;最基础场景赋零后覆盖x 0; x v;同上delete后覆盖delete x; x v;delete视为纯写入冗余的 delete 同样被标记括号包裹的赋值语句(x 1); x v;剥括号后仍被识别嵌套在初始化器中的赋值uint256 z (x v);左值仍是一次写入分支体内的连续写入if (flag) { x 0; x v; }分支内部独立分析自增/自减后的覆盖x; x v;x是一次读写后置自增的写入被覆盖x 1; x; x v;标记x的写入元组解构写入(x, y) (1, 2); x v;只标记死掉的组件x调用参数选项中的写入addr.call{value: (x v)}();call 选项参数同样先求值emit 不阻断检测x 1; emit MyEvent(v); x v;emit只记录日志不会读取存储调用实参中的写入被覆盖x 1; helper2(x v);实参求值即写入其中值得注意的设计emit语句只读取实参、不会观察存储内容因此两次写入之间的emit不会清除待定写入而任何函数调用都会保守地清除待定写入见下文源码分析。不会标记good的形态形态示例说明两次写入间有读取x 1; prev x; x v;第一次写入已被读取消费复合赋值x 1; x 1;先读后写写入不同变量x v; y v;互不影响mapping 不同键balances[a] v; balances[b] v;槽位可能不同保守不报分支后再写外层清除if (flag) { x 1; } x v;分支可能未执行外层待定被丢弃右值引用后覆盖x 1; y x v; x v;右值读取了x两次写入间有调用x 1; helper(); x v;任何调用都可能观察存储写入后直接 return / revertx v; return x;后面代码不可达内层块共享待定集合x 1; { y x v; } x v;内层块顺序执行读取计入三元表达式互斥分支(flag ? (x 1) : (x 2));两分支只执行其一短路(v 0) (x v) 0;右侧可能不执行不可达代码return x; x 1; x 2;返回后的写入不可达先读后增x 1; return x;/x v; x;自增先读取旧值修饰符modifier场景测试还覆盖了 modifier 的特殊行为ModifierTestmodifier 体x 1; _; x 0;中占位符_会执行被修饰函数可能观察存储因此两侧写入都视为有效不报ModifierBadmodifier 体内直接x 1; x 2;则照常报错。源码实现原理一次顺序数据流分析该规则实现于 crates/lint/src/sol/gas/write_after_write.rs核心是一个顺序数据流分析器以HashMapVariableId, Span维护待定写入集合——已写入但尚未被读取的状态变量及其写入位置。struct Analyzera, gcx { ctx: a LintContexta, a, gcx: Gcxgcx, pending: HashMapVariableId, Span, }入口与语句级遍历check_functionwrite_after_write.rs#L26-L30从函数体开始由check_block/check_stmt顺序遍历语句。每个语句的返回布尔值表示控制流是否继续Return、Revert、Break、Continue是终结语句先处理其中的表达式读取然后清空pending并返回false说明其后的代码不可达永远不会覆盖前面的待定写入If的两个分支通过isolated隔离分析——分支单独分析可捕获分支内部的写入对同时丢弃外层待定写入因为任一分支都可能读取或跳过外层写这正是测试good5与已知漏报branchMiss的分野Loop可能执行零次因此不会阻断外层控制流嵌套块Block/UncheckedBlock顺序执行与外层共享 pending 集合所以块内读取能消费外层写入占位符Placeholder、内联汇编AssemblyBlock、Switch、错误节点统一视为不透明保守地清空 pending。表达式级处理process_exprwrite_after_write.rs#L125-L157对会产生副作用的表达式分类处理普通赋值先reads(rhs)处理右值再write_lhs(lhs)记录左值写入复合赋值等右值求值后还要reads(lhs)——因为复合赋值会读取当前左值这也解释了为什么x 1不触发自增/自减/--先读后写若目标是状态变量则记录写入delete x视为纯写入任何函数调用先处理 callee、实参、call 选项参数这些都会求值、可能读写存储随后无条件清空 pending——这是对重入与 view 语义的保守假设也是测试good7、pureCallMiss行为的根源。关键函数writewrite_after_write.rs#L173-L177完成诊断发射fn write(mut self, var: VariableId, span: Span) { if let Some(prev_span) self.pending.insert(var, span) { self.ctx.emit(WRITE_AFTER_WRITE, prev_span); } }HashMap::insert在槽位已被占用时返回旧值——只要发现同一变量已有待定写入就在旧写入的位置发射write-after-write诊断。readswrite_after_write.rs#L181-L229则负责把表达式读取过的状态变量从 pending 中移除其中/||短路操作数与三元表达式因可能不执行其操作数读取被隔离处理避免条件路径上的误报。元组与索引/成员访问write_lhs对元组解构逐组件递归记录每个组件用自己的 span这正是(x, y) (1, 2); x v;中诊断只高亮x组件的原因见测试TupleSpanTest与 stderr 中━━━只框住x。而索引/成员访问mapping、数组、结构体无法静态确定唯一槽位只按读取基址处理不记录待定写入——对应文档中的排除项。已知局限漏报与误报检测器采用保守设计仓库测试文件末尾专门用KnownFalseNegatives合约记录了四类已知漏报crates/lint/testdata/WriteAfterWrite.sol#L259-L291分支清空外层待定x 1; if (c) { y 2; } x v;——If语句隔离分析会保守丢弃外层x 1即使该分支并不写x两分支都写但互不合并if (c) x 1; else x 2; x v;—— 分支各自使用全新待定集合结束后不合并两次分支内写入都漏报短路表达式清空待定bool z a b;隔离 RHS 的处理会连带丢弃外层x 1所有调用都清空待定纯函数调用如abi.encode(...)也会抑制诊断保守的重入假设代价。同时存在一处已知误报WriteAfterWrite.sol#L238-L244solar 目前尚未将内联汇编降级到 HIR因此assembly { let z : sload(0) }对分析器不可见x 1; assembly {...}; x v;中的第一次写入会被误判为死写入。修复需等待 solar 对汇编的支持源码注释标注为 TODO。理解这些边界可以帮助你在收到诊断时判断是真优化机会还是保守假设下的伪报。如何启用与配置write-after-write的 Severity 是Gas而 crates/config/src/lint.rs#L13-L43 中LinterConfig的severity字段默认只包含High、Med、Low三个级别pub struct LinterConfig { /// Specifies which lints to run based on severity. /// /// Defaults to high, medium, and low severity lints. pub severity: VecSeverity, /// Deny specific lints based on their ID (e.g. mixed-case-function). pub exclude_lints: VecString, /// Globs to ignore. pub ignore: VecString, /// Whether to run linting during forge build. /// /// Defaults to true. Set to false to disable automatic linting during builds. pub lint_on_build: bool, ... }也就是说默认配置下forge lint并不会运行 Gas 级别的规则需要显式启用。两种方式在foundry.toml中扩展 severity将gas加入运行级别[lint] severity [high, med, low, gas]命令行只运行本规则例如测试夹具使用的--only-lint编译标志见 WriteAfterWrite.sol#L1forge lint --only-lint write-after-write启用后触发规则会在对应源码位置输出如下形式的诊断完整期望输出见 crates/lint/testdata/WriteAfterWrite.stderrnote[write-after-write]: redundant storage write; value overwritten before being read ╭▸ ROOT/testdata/WriteAfterWrite.sol:LL:CC │ LL │ x 1; │ ━━━━━ │ ╰ help: https://getfoundry.sh/forge/linting/write-after-write文档与测试的强约束每个已注册的 lint 都必须在 crates/lint/docs/ 目录下有同名 Markdown 文档str_id.md。根据 crates/lint/docs/README.md#L9-L16运行cargo test -p forge-lint --lib sol::tests会校验每个已注册 lint 都有元数据匹配、结构合规、help URL 规范的文档页同时拒绝未注册规则的文档页并在 CI 中强制执行。因此 write-after-write.md 既是面向用户的权威说明也是被测试约束的契约文件。编写风格上遵循 docs/dev/lintrules.md#lint-writing-style 的规范What it does描述用户可见的触发模式而非实现细节安全、正确性、Gas 相关结论保持具体并说明局限。小结write-after-write是一条聚焦于存储写入优化的 Gas 级别规则它通过顺序数据流分析跟踪未读即被覆盖的状态变量写入精准定位冗余SSTORE同时以保守策略调用清空、分支隔离、短路与三元隔离、索引/成员排除控制误报。使用时要记住三个要点先确认被标记赋值右值无副作用再删除意识到默认 severity 不含Gas需要显式配置理解分支、调用、汇编等场景下的漏报与误报边界。结合仓库中的测试文件你可以把每个边界行为当作回归用例来加深理解在真实合约中安全地应用这一优化。【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Foundry Forge Lint 规则实战：write-after-write（冗余存储写入检测与 Gas 优化指南）
Foundry Forge Lint 规则实战write-after-write冗余存储写入检测与 Gas 优化指南【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry本文围绕 Foundry 项目forge lint内置的write-after-write规则展开系统讲解它如何识别写入存储后、在被读取之前就被再次覆盖的死写入模式剖析其背后的 Gas 浪费原理、规则边界与源码实现并给出可复制的触发示例、推荐写法、配置启用方式与已知局限。读完本文你将能够在自己的 Solidity 合约中准确识别并消除冗余的存储写入同时理解该检测器何时会漏报或误报。该规则以 crates/lint/docs/write-after-write.md 为权威文档本文结合其实现源码 crates/lint/src/sol/gas/write_after_write.rs 与完整测试用例 crates/lint/testdata/WriteAfterWrite.sol 进行深度扩充。规则概览Severity 与 ID属性值规则名称Write after writeSeverity严重级别GasID规则标识write-after-write诊断消息redundant storage write; value overwritten before being read在源码中该规则通过declare_forge_lint!宏注册见 crates/lint/src/sol/gas/write_after_write.rs#L18-L23declare_forge_lint!( WRITE_AFTER_WRITE, Severity::Gas, write-after-write, redundant storage write; value overwritten before being read );并在 crates/lint/src/sol/gas/mod.rs#L22 中以late阶段语义分析后执行注册进 Gas 严重级别分组write_after_write: (WriteAfterWrite, late, (WRITE_AFTER_WRITE));What it does检测什么该规则报告的是对状态变量的赋值其写入的值在真正被读取之前就被再次覆盖。具体来说它跟踪已被写入、但尚未被任何读取观察过的状态变量一旦发现对同一变量再次写入前一次写入即为冗余dead write并以前一次写入的位置为锚点发出诊断。规则文档明确列出了以下排除项复合赋值compound assignment如x 1不触发——因为复合赋值本身会先读取旧值再写入对单个 mapping 条目、数组元素或结构体字段的写入不触发——因为这类写入无法确定是否命中同一个存储槽例如balances[a]与balances[b]很可能指向不同槽位。触发示例原文档给出的经典触发示例crates/lint/docs/write-after-write.md#L19-L30contract C { uint256 public x; function bad(uint256 v) external { x 0; // write-after-write: this value is never read x v; // second write overwrites the first } }第一行x 0的值从未被任何读取消费紧接着的x v将其覆盖x 0就是典型的死写入。推荐写法contract C { uint256 public x; // Write once with the final value directly. function good(uint256 v) external { x v; } // Reading between writes is fine. function goodRead(uint256 v) external returns (uint256 prev) { x 1; prev x; // x is read here x v; } // Compound assignments read before writing, not flagged. function goodCompound() external { x 1; x 1; } }三种安全模式一目了然直接写入最终值两次写入之间插入一次读取使用复合赋值让读-改-写合并。Why is this bad为什么浪费 Gas向存储写入数据SSTORE指令是 EVM 中最昂贵的操作之一。将值写入存储后立即再次覆盖如果编译器没有消除第一次写入就会白白多付一次存储写入的 Gas。需要特别强调的是文档原文每次写入的成本并不固定它取决于槽位访问历史与所写值槽位在本次交易内从未写过cold slot写入非零值最昂贵槽位若曾在本交易内写过再次写入的成本会大幅降低warm slot写入零值、或在重置零值等场景下成本又不同。因此write-after-write带来的浪费是一个随上下文浮动的量不能一概而论地说每次冗余写入固定浪费多少 Gas。文档同时给出了一个重要的修复约束Remove the first assignment only when evaluating its right-hand side has no required side effects.即只有在前一次赋值的右值表达式没有必需的副作用时才应该删除第一次赋值。例如// 右值有副作用删除 x f() 会丢失 f() 的调用 x f(); // f() 的副作用不可丢弃 x v;这种场景下应保留第一次赋值或改写逻辑而不是机械地删除。规则边界什么算、什么不算原文档只给出了三类基本排除项而仓库中的测试文件 crates/lint/testdata/WriteAfterWrite.sol 将规则边界扩展到了数十种真实语法形态。测试通过//compile-flags: --only-lint write-after-write仅启用本规则其期望输出记录在 crates/lint/testdata/WriteAfterWrite.stderr。会被标记bad的形态形态示例说明连续两次普通赋值x 1; x 2;最基础场景赋零后覆盖x 0; x v;同上delete后覆盖delete x; x v;delete视为纯写入冗余的 delete 同样被标记括号包裹的赋值语句(x 1); x v;剥括号后仍被识别嵌套在初始化器中的赋值uint256 z (x v);左值仍是一次写入分支体内的连续写入if (flag) { x 0; x v; }分支内部独立分析自增/自减后的覆盖x; x v;x是一次读写后置自增的写入被覆盖x 1; x; x v;标记x的写入元组解构写入(x, y) (1, 2); x v;只标记死掉的组件x调用参数选项中的写入addr.call{value: (x v)}();call 选项参数同样先求值emit 不阻断检测x 1; emit MyEvent(v); x v;emit只记录日志不会读取存储调用实参中的写入被覆盖x 1; helper2(x v);实参求值即写入其中值得注意的设计emit语句只读取实参、不会观察存储内容因此两次写入之间的emit不会清除待定写入而任何函数调用都会保守地清除待定写入见下文源码分析。不会标记good的形态形态示例说明两次写入间有读取x 1; prev x; x v;第一次写入已被读取消费复合赋值x 1; x 1;先读后写写入不同变量x v; y v;互不影响mapping 不同键balances[a] v; balances[b] v;槽位可能不同保守不报分支后再写外层清除if (flag) { x 1; } x v;分支可能未执行外层待定被丢弃右值引用后覆盖x 1; y x v; x v;右值读取了x两次写入间有调用x 1; helper(); x v;任何调用都可能观察存储写入后直接 return / revertx v; return x;后面代码不可达内层块共享待定集合x 1; { y x v; } x v;内层块顺序执行读取计入三元表达式互斥分支(flag ? (x 1) : (x 2));两分支只执行其一短路(v 0) (x v) 0;右侧可能不执行不可达代码return x; x 1; x 2;返回后的写入不可达先读后增x 1; return x;/x v; x;自增先读取旧值修饰符modifier场景测试还覆盖了 modifier 的特殊行为ModifierTestmodifier 体x 1; _; x 0;中占位符_会执行被修饰函数可能观察存储因此两侧写入都视为有效不报ModifierBadmodifier 体内直接x 1; x 2;则照常报错。源码实现原理一次顺序数据流分析该规则实现于 crates/lint/src/sol/gas/write_after_write.rs核心是一个顺序数据流分析器以HashMapVariableId, Span维护待定写入集合——已写入但尚未被读取的状态变量及其写入位置。struct Analyzera, gcx { ctx: a LintContexta, a, gcx: Gcxgcx, pending: HashMapVariableId, Span, }入口与语句级遍历check_functionwrite_after_write.rs#L26-L30从函数体开始由check_block/check_stmt顺序遍历语句。每个语句的返回布尔值表示控制流是否继续Return、Revert、Break、Continue是终结语句先处理其中的表达式读取然后清空pending并返回false说明其后的代码不可达永远不会覆盖前面的待定写入If的两个分支通过isolated隔离分析——分支单独分析可捕获分支内部的写入对同时丢弃外层待定写入因为任一分支都可能读取或跳过外层写这正是测试good5与已知漏报branchMiss的分野Loop可能执行零次因此不会阻断外层控制流嵌套块Block/UncheckedBlock顺序执行与外层共享 pending 集合所以块内读取能消费外层写入占位符Placeholder、内联汇编AssemblyBlock、Switch、错误节点统一视为不透明保守地清空 pending。表达式级处理process_exprwrite_after_write.rs#L125-L157对会产生副作用的表达式分类处理普通赋值先reads(rhs)处理右值再write_lhs(lhs)记录左值写入复合赋值等右值求值后还要reads(lhs)——因为复合赋值会读取当前左值这也解释了为什么x 1不触发自增/自减/--先读后写若目标是状态变量则记录写入delete x视为纯写入任何函数调用先处理 callee、实参、call 选项参数这些都会求值、可能读写存储随后无条件清空 pending——这是对重入与 view 语义的保守假设也是测试good7、pureCallMiss行为的根源。关键函数writewrite_after_write.rs#L173-L177完成诊断发射fn write(mut self, var: VariableId, span: Span) { if let Some(prev_span) self.pending.insert(var, span) { self.ctx.emit(WRITE_AFTER_WRITE, prev_span); } }HashMap::insert在槽位已被占用时返回旧值——只要发现同一变量已有待定写入就在旧写入的位置发射write-after-write诊断。readswrite_after_write.rs#L181-L229则负责把表达式读取过的状态变量从 pending 中移除其中/||短路操作数与三元表达式因可能不执行其操作数读取被隔离处理避免条件路径上的误报。元组与索引/成员访问write_lhs对元组解构逐组件递归记录每个组件用自己的 span这正是(x, y) (1, 2); x v;中诊断只高亮x组件的原因见测试TupleSpanTest与 stderr 中━━━只框住x。而索引/成员访问mapping、数组、结构体无法静态确定唯一槽位只按读取基址处理不记录待定写入——对应文档中的排除项。已知局限漏报与误报检测器采用保守设计仓库测试文件末尾专门用KnownFalseNegatives合约记录了四类已知漏报crates/lint/testdata/WriteAfterWrite.sol#L259-L291分支清空外层待定x 1; if (c) { y 2; } x v;——If语句隔离分析会保守丢弃外层x 1即使该分支并不写x两分支都写但互不合并if (c) x 1; else x 2; x v;—— 分支各自使用全新待定集合结束后不合并两次分支内写入都漏报短路表达式清空待定bool z a b;隔离 RHS 的处理会连带丢弃外层x 1所有调用都清空待定纯函数调用如abi.encode(...)也会抑制诊断保守的重入假设代价。同时存在一处已知误报WriteAfterWrite.sol#L238-L244solar 目前尚未将内联汇编降级到 HIR因此assembly { let z : sload(0) }对分析器不可见x 1; assembly {...}; x v;中的第一次写入会被误判为死写入。修复需等待 solar 对汇编的支持源码注释标注为 TODO。理解这些边界可以帮助你在收到诊断时判断是真优化机会还是保守假设下的伪报。如何启用与配置write-after-write的 Severity 是Gas而 crates/config/src/lint.rs#L13-L43 中LinterConfig的severity字段默认只包含High、Med、Low三个级别pub struct LinterConfig { /// Specifies which lints to run based on severity. /// /// Defaults to high, medium, and low severity lints. pub severity: VecSeverity, /// Deny specific lints based on their ID (e.g. mixed-case-function). pub exclude_lints: VecString, /// Globs to ignore. pub ignore: VecString, /// Whether to run linting during forge build. /// /// Defaults to true. Set to false to disable automatic linting during builds. pub lint_on_build: bool, ... }也就是说默认配置下forge lint并不会运行 Gas 级别的规则需要显式启用。两种方式在foundry.toml中扩展 severity将gas加入运行级别[lint] severity [high, med, low, gas]命令行只运行本规则例如测试夹具使用的--only-lint编译标志见 WriteAfterWrite.sol#L1forge lint --only-lint write-after-write启用后触发规则会在对应源码位置输出如下形式的诊断完整期望输出见 crates/lint/testdata/WriteAfterWrite.stderrnote[write-after-write]: redundant storage write; value overwritten before being read ╭▸ ROOT/testdata/WriteAfterWrite.sol:LL:CC │ LL │ x 1; │ ━━━━━ │ ╰ help: https://getfoundry.sh/forge/linting/write-after-write文档与测试的强约束每个已注册的 lint 都必须在 crates/lint/docs/ 目录下有同名 Markdown 文档str_id.md。根据 crates/lint/docs/README.md#L9-L16运行cargo test -p forge-lint --lib sol::tests会校验每个已注册 lint 都有元数据匹配、结构合规、help URL 规范的文档页同时拒绝未注册规则的文档页并在 CI 中强制执行。因此 write-after-write.md 既是面向用户的权威说明也是被测试约束的契约文件。编写风格上遵循 docs/dev/lintrules.md#lint-writing-style 的规范What it does描述用户可见的触发模式而非实现细节安全、正确性、Gas 相关结论保持具体并说明局限。小结write-after-write是一条聚焦于存储写入优化的 Gas 级别规则它通过顺序数据流分析跟踪未读即被覆盖的状态变量写入精准定位冗余SSTORE同时以保守策略调用清空、分支隔离、短路与三元隔离、索引/成员排除控制误报。使用时要记住三个要点先确认被标记赋值右值无副作用再删除意识到默认 severity 不含Gas需要显式配置理解分支、调用、汇编等场景下的漏报与误报边界。结合仓库中的测试文件你可以把每个边界行为当作回归用例来加深理解在真实合约中安全地应用这一优化。【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
