智能合约变量定义规范 写代码别踩坑

智能合约开发中，变量定义看似基础，却是决定合约安全性和可维护性的关键环节。很多新手甚至老手，因为变量定义不规范，导致gas费飙升、逻辑漏洞甚至资产被盗。本文从实际开发经验出发，梳理最核心的变量定义规范，帮你在编码时避开常见陷阱。

变量作用域怎么选才安全

在Solidity中，状态变量、局部变量和全局变量各有用途，但用错作用域会直接引发安全问题。状态变量存储在链上，每次修改都要消耗gas，所以能不用状态变量就别用。比如临时计算的中间值，用局部变量存内存里就行，别一股脑塞进storage。

状态变量的可见性也要严格把控。public变量会自动生成getter函数，意味着所有人都能读，敏感数据千万别设成public。internal和private虽然不能直接外部读取，但链上数据其实是公开的，所以密码或私钥这类信息永远不能存到合约里，不管用什么可见性修饰。

还有一个常见坑：在循环里反复读写状态变量。每次操作都触发SLOAD或SSTORE，gas消耗巨大。正确的做法是把状态变量先读到内存变量里，循环操作内存变量，最后再写回状态变量。比如批量转账时，先把余额映射读到内存数组，算完再批量更新。

数据类型用不对会有什么后果

整数类型的选择直接影响合约的安全和效率。uint256能存的范围很大，但如果你明确知道数值不会超过255，用uint8就够了，能省gas。不过要注意，不同精度的整数做运算时，Solidity会自动做类型转换，稍不注意就会溢出。

地址类型address和address payable要分清。后者才有transfer和send方法，如果你需要用合约接收以太币，地址必须声明为payable。另外，地址变量赋值前一定要检查零地址，否则可能把资产转到黑洞。

映射mapping和数组array的取舍也常让人头疼。mapping适合键值对存储，不能遍历；array可以遍历但gas高。如果你需要遍历所有元素，考虑用数组加映射的组合方案，比如用一个数组存所有用户地址，再用映射存每个用户的数据，这样既方便查找又能遍历。结构体里嵌套映射时，记得先初始化再赋值，否则会报错。

bytes和string的选择也有讲究。string用于文本，bytes用于原始字节数据。如果只需要处理二进制数据，用bytes更省gas，因为string的编码解码有额外开销。固定大小的字节数组bytes1到bytes32比动态bytes更便宜，能用固定长度就别用动态。