好问题！我会分两个部分帮你理清这些问题：

一、未使用循环时，Array的尺寸是否存在问题？ #

如果你的合约从未对数组执行循环遍历操作，那么数组本身的尺寸（比如长度很大）不会直接引发问题：

• Solidity中动态数组的存储结构是：第一个存储槽（slot）保存数组长度，后续槽连续存储数组元素。不管数组多长，通过索引直接访问单个元素（比如myArray[index]）的操作都是O(1)复杂度，gas成本固定，不会因为数组长度增加而上升。
• 你不需要担心数组过长导致合约执行效率下降或额外gas消耗——只要不遍历，数组的“大尺寸”本身不会成为合约的负担。

二、存储仅含Addresses的Array（无循环）的Gas与限制问题 #

Gas费用方面 #

每次向数组添加地址（比如myAddressArray.push(newAddr)）的gas成本是固定的，和数组当前长度无关：

• 新增元素的gas主要来自SSTORE操作：第一次存储某个存储槽时（数组末尾的新槽），gas成本约为20000；push是纯新增操作，不会涉及已有槽的修改，所以每次push的gas消耗基本一致。
• 因为你不执行循环，每次push只会操作数组末尾的新位置，不会遍历前面的元素，所以无论数组已有1个还是1000个元素，单次push的gas消耗不会随数组长度变化。

存储限制方面 #

你需要注意几个实际限制：

• 区块Gas上限：如果在单个交易中多次执行push操作（比如一次添加1000个地址），累加的gas可能超过当前区块的gas上限，导致交易失败。建议拆分到多个交易中执行，或者控制单次交易的push数量。
• 理论长度限制：Solidity数组的最大长度是2^256 - 1，但这只是理论值——实际中存储这么多元素需要的ETH成本（gas费用）是天文数字，完全不具备可行性。
• Public数组的隐式风险：如果你的数组是public修饰的，Solidity会自动生成一个getter函数。如果外部调用者不带索引参数调用这个getter，会返回整个数组，此时会触发遍历操作，导致极高的gas消耗甚至交易失败。但这是调用者的问题，只要你的合约内部不执行循环，就不会影响合约自身的逻辑执行。

内容的提问来源于stack exchange，提问作者un4given