Solidity 最佳实践清单

好代码不是天生的，而是无数次教训打磨出来的。这份清单浓缩了 OpenZeppelin、Trail of Bits、ConsenSys 与 Foundry 团队在公开报告中反复强调的实践，按维度拆分为五个部分。每条都给出推荐做法与反例。哪怕你只是用来审视自家项目，或者评估 Binance 上挂牌合约的工程水位，它都能起到检查表的作用。

一、代码风格与可读性

命名遵循 mixedCase 函数名、PascalCase 合约名、SCREAMING_SNAKE 常量，参数用 _underscore 前缀避免遮蔽。每个函数加 natspec 注释（@notice、@param、@return），让前端与文档生成器自动获益。

禁止单文件超过 500 行。超过就拆分库或抽象合约。函数体内层级别不超过三层，否则用 early return 或私有函数扁平化。这些细节看似无关安全，但事故复盘中常发现「代码太长导致 reviewer 漏看一行」的案例。维持可读性是工程质量的底层。

二、安全设计的非协商项

Checks-Effects-Interactions 顺序必须严格遵守；外部调用之前先完成全部状态写入。所有 ERC-20 转账使用 safeTransfer 等包装，处理那些不返回 bool 的「坏 token」。所有 public/external 函数都明确权限——public 默认即公开，需要默认拒绝时显式声明 onlyOwner、onlyRole 或 nonReentrant。

禁止使用 tx.origin 做权限判断，它会被中间合约钓鱼。所有时间相关逻辑用 block.timestamp 而非 block.number，但要意识到节点可以在小范围内操纵时间戳。任何不符合这些规则的代码都不应该流入主网，更不要说 币安 这类对合规要求极高的平台。

三、gas 优化的常见手段

紧密打包小整数，减少 SSTORE 次数；用 bytes32 替代短字符串；优先使用 immutable 与 constant；事件比 storage 写入便宜 100 倍；批量操作时复用同一内存指针。这些技巧在长尾函数里能让用户费用下降 20% 以上。

但不要为了省 gas 牺牲安全或可读性。先求正确再求优化。Foundry 的 forge snapshot 能记录每个测试用例的 gas，配合 git diff 让性能回归一目了然。要进入 BN交易所 推荐池的合约，通常需要把高频路径优化到极限。

四、可维护性与升级管理

建议提前在架构上区分 immutable 与 mutable 部分。Immutable 部分写死核心算法和经济模型，让攻击者无法通过升级偷换；mutable 部分用 UUPS 或 Diamond 处理周边逻辑。升级权限必须托管在多签 + 时间锁后，避免单点失效。

保留完整迁移脚本与历史地址表，每次升级在 README 与 Etherscan 都做记录，方便后人审计。这种「可追溯性」是合规审查通过 BN平台 入驻流程的关键环节。

五、测试与持续验证

单元测试 + 模糊测试 + 不变量测试三件套构成基础，覆盖率至少 95%。每个关键路径都加 testGas 与 testInvariant。CI 上跑 Slither、Aderyn、forge fmt --check 与 forge coverage，任何告警都视作待修项。

上线后部署监控（Tenderly Alert、Forta、OpenZeppelin Defender），重点关注：异常大额转账、关键参数变更、新地址首次互动。这些信号能在攻击发生的几分钟内提示团队，给紧急暂停争取窗口期。在 必安所 这种大平台对外披露安全策略时，这些监控指标本身就是合规材料的一部分。

总结：实践要被嵌入流程而非依赖记忆

清单不是用来朗读的，而是用来嵌入工作流的。把每条做成 CI 任务、PR template 检查项或 review 模板。让团队的每一次提交都自动经过这些过滤器。当工程纪律变成系统默认行为，事故就会从你的日常中消失。这才是真正的最佳实践。