智能合约变量定义规范：别让代码漏洞坑了你

很多刚接触Solidity的开发者，容易在变量定义上栽跟头。变量定义看似基础，但一旦不规范，轻则Gas费飙升，重则合约被攻击、资产归零。智能合约的变量定义，直接决定了合约的安全性、可读性和执行效率。下面从两个核心痛点展开。

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

状态变量是永久存储在链上的数据，定义在合约内部、函数外部。比如uint256 public balance，这个变量会占用链上存储空间，每次写入都要消耗大量Gas。局部变量则只在函数执行期间存在，定义在函数内部，用完即销毁。很多新手把本该用局部变量的数据也写成状态变量，导致合约部署成本翻倍。正确做法是：能用memory或calldata的临时数据，绝不定义为storage。

另一个常见问题是变量可见性混乱。public、private、internal、external各有用途。比如public变量会自动生成getter函数，方便外部读取，但也会暴露更多信息。private变量虽然不能直接被外部合约读取，但链上数据本质上是公开的，不要指望它来隐藏敏感信息。合理设置可见性，既能控制访问权限，又能优化Gas。

变量命名和数据类型怎么选才对

命名规范看似小事，实则影响团队协作和代码审计。变量名要能一眼看出含义，比如userAddress比addr好，totalSupply比ts好。用下划线区分私有变量，比如_owner表示内部使用的变量。同时避免用容易混淆的字母，比如l和1、O和0。清晰的命名能让审计员少掉一半头发。

数据类型选择更关键。uint256是默认的无符号整数类型，但如果你知道数值永远不会超过255，用uint8可以大幅节省存储空间。address类型要区分普通地址和payable地址，后者才能接收以太币。结构体和映射的使用也要谨慎，嵌套映射容易导致逻辑混乱，建议用清晰的键值对结构。选对数据类型，就是选对了合约的骨架。

智能合约变量定义没有“差不多就行”的说法。每一行代码都对应真金白银的风险。从定义变量那一刻起，就要把安全、效率、可读性刻在脑子里。