智能合约变量定义规范有哪些要点

写智能合约和写普通程序不一样，变量定义这件事，看似基础，却直接关系到合约的安全性和Gas消耗。很多开发者在初学Solidity时，对变量定义规范不够重视，结果上线后才发现问题——不是被重入攻击钻了空子，就是部署成本高得离谱。我接触过不少合约审计的案例，变量定义不规范是导致漏洞的高频原因之一。

状态变量和局部变量怎么区分

状态变量是存储在链上的，永久保存在合约中，定义在函数体外。局部变量只在函数执行期间存在，定义在函数体内。这个区分听起来简单，但实际开发中经常有人混淆。状态变量的存储位置决定了它的访问成本和修改成本，每个SSTORE操作都要消耗大量Gas，所以能用局部变量解决的，就不要轻易动状态变量。

比如循环里反复修改某个值，如果直接操作状态变量，Gas消耗会成倍增加。正确做法是先把状态变量读入内存变量，在循环里操作内存变量，结束后再一次性写回。这种写法在DeFi合约里尤其常见，也是优化Gas的常规手段。

另外，状态变量默认是internal可见性，如果希望外部合约读取，需要显式声明为public。但要注意，public状态变量会自动生成getter函数，这也会增加合约的字节码大小。

可见性和数据位置怎么定

可见性有public、private、internal、external四种。很多人习惯把所有变量都写成public，方便调试，但这其实暴露了不必要的接口面，增加了攻击面。建议状态变量默认用private或internal，只有确实需要对外暴露的才用public。

数据位置则涉及storage、memory、calldata三个关键词。复杂类型如数组和结构体，必须显式指定数据位置。storage指向持久化存储，memory是临时内存，calldata用于外部函数参数且不可修改。新手常犯的错误是把calldata写成memory，虽然能编译通过，但会多一次不必要的拷贝，浪费Gas。

对于address类型，还要注意区分普通地址和payable地址。如果需要向某个地址转账，必须显式声明为payable，否则编译会报错。这个细节在编写支付逻辑时经常踩坑。

命名规范和常量定义

变量命名虽然没有强制规则，但社区有约定俗成的风格。状态变量用驼峰式，函数参数用下划线前缀，常量用全大写加下划线。这些约定不是为了好看，而是为了让代码审计更容易。一个命名混乱的合约，审计成本会显著上升。

对于不会改变的值，比如协议费率、最大供应量，应该用constant或immutable关键字声明。constant在编译期就确定，immutable在构造函数中赋值一次。这两种变量不占用存储槽，Gas成本远低于普通状态变量。

变量定义规范不是教条，而是从一次次漏洞和教训中总结出来的经验。遵循这些规范，不只能写出更安全的合约，也能让团队协作和代码审计更加顺畅。如果你正在开发合约，不妨回头检查一下自己的变量定义，看看有没有可以优化的地方。