智能合约变量定义规范，看这篇就够了

智能合约的变量定义看似基础，却直接影响合约的安全性、Gas消耗和可维护性。很多开发者因为变量定义不规范，导致合约漏洞或部署成本飙升。理解变量定义的核心规则，是写出健壮合约的第一步。

变量状态可见性怎么选

Solidity中变量可见性分为public、internal、private和external四种，但只有状态变量才涉及前三种。public变量会自动生成getter函数，方便外部查询，但会略微增加部署成本。internal变量只允许当前合约和子合约访问，是内部逻辑的默认选择。private变量则彻底限制访问，连子合约都无法读取。

实际开发中，很多人习惯把所有变量都设为public，这其实是个坏习惯。比如一个记录用户积分的变量，如果只用于合约内部计算，设为internal就足够。公开不必要的变量不仅暴露了内部状态，还增加了攻击面。更关键的是，public变量会占用更多存储槽，导致Gas消耗上升。

还有一种常见错误是把public变量和external函数混淆。external只能用于函数，不能用于状态变量。如果你看到有人把变量声明为external，基本可以判定是新手。

存储位置和Gas消耗怎么平衡

变量定义时必须明确存储位置：storage、memory还是calldata。storage变量永久存储在链上，读写成本最高。memory变量只在函数执行期间存在，成本适中。calldata变量是只读的，成本最低，主要用于函数参数。

很多开发者喜欢把大数组或结构体直接定义为storage变量，然后在函数内部频繁修改。这种做法会让Gas账单飙升。正确的做法是：对于临时计算的数据，尽量用memory或calldata；只有需要永久保存的数据才用storage。

举个例子，如果你要处理一个包含1000个地址的数组，在函数内部遍历时，应该先把这个数组从storage复制到memory。虽然复制本身有成本，但后续的每次读取都会比直接操作storage便宜得多。这个技巧在NFT批量铸造或DeFi流动性管理场景中特别实用。

变量命名和类型选择有什么讲究

变量命名不是随便起的。Solidity社区约定：私有变量用下划线开头，比如_balance；常量用全大写，比如MAX_SUPPLY。这样做的好处是，别人读代码时一眼就能看出变量的用途和权限。

类型选择更关键。uint8、uint256虽然都是无符号整数，但占用存储空间不同。Solidity会尽量压缩存储，但如果变量定义不连续，会导致存储槽浪费。比如把uint128和uint256交替定义，每个变量都会占用独立槽位。正确做法是把相同类型的变量挨着放，让Solidity自动打包。

地址类型要特别注意。address payable和普通address的区别在于能否接收以太币。如果你在合约中向用户转账，必须用address payable，否则编译会报错。很多合约漏洞就是因为忘记转换地址类型导致的。

映射类型不能作为函数参数或返回值。如果你需要把映射数据传出合约，必须手动遍历成数组。这个限制让一些开发者踩坑，比如在公共查询函数中直接返回映射，结果编译失败。

结构体定义要避免循环引用。比如结构体A包含结构体B，结构体B又包含结构体A，这种定义会让Solidity编译器崩溃。实际开发中，可以用映射或数组来打破循环依赖。

变量定义规范不是死板的教条，而是无数开发者用真金白银换来的经验。遵循这些规则，你的合约会更安全、更省Gas，也更易维护。