为何数组求和伪代码各语句为Big O常数时间O(1)？数组、total会影响复杂度吗？

很多刚学Big O的人都会被这种标注误导，这里把逻辑拆得明明白白：

为什么单步操作都算O(1)？ #

所有被标注为O(1)的操作，本质是执行成本完全不依赖输入规模变化的固定动作：

• total = 0：就是在内存里申请一个存整数的位置，写入初始值0，不管你传入的数组是3个元素还是3亿个元素，这一步的耗时不会有任何变化，所以是O(1)。
• for each i in given array 这行旁边的O(1)标注，指的是单次循环迭代时的操作成本：也就是从数组里按顺序取出一个元素、把循环指针挪到下一个位置的这一个动作，耗时是固定的；别被注释位置骗了，这根本不是说整个循环的总耗时是O(1)。
• total += i：单步动作是把当前取出的数组元素和total存的值做一次加法，再把结果写回total的内存位置，单次动作的耗时固定，不随数组规模变化，所以单步是O(1)。
• return total：把内存里存的total值作为函数输出返回，动作固定，耗时不随输入规模变化，所以是O(1)。

针对你两个疑问的具体解答 #

疑问1：数组规模变大，时间复杂度会不会随之升高？ #

会，但这和“单步是O(1)”的结论完全不冲突。
数组规模变大，本质是让那行for循环的执行次数变多：原来数组是10个元素，循环跑10次；数组变成1000万个元素，循环跑1000万次。虽然单次循环里的每一步都是固定成本的O(1)操作，但累计的总耗时会和数组长度成正比增长，所以这个函数的整体时间复杂度是O(n)，不是O(1)。
原注释的问题在于把循环的单步O(1)标注得太靠前，容易让人误以为整个循环的成本是O(1)，这是很多入门示例最常见的标注误导。

疑问2：total累加的数值越来越大，会不会影响时间复杂度？ #

在常规的算法复杂度分析语境下，不会。
Big O的分析默认把基础的算术运算、内存读写当做无差别的固定成本：你加的是个位数，还是百万级的大数，都算一次标准的加法操作，不把数值大小带来的微小成本波动算进复杂度变化里。
如果真的严格抠硬件层面的差异：当total的数值大到超出CPU单次可以处理的整数范围（比如64位整数的上限），确实需要多几个指令来拼接处理大整数，会带来非常微小的耗时增加，但这种变化属于常量级别的固定开销波动，不会随着输入规模的增长呈现出线性、平方级别的上升趋势，在Big O的分析里会被直接忽略——毕竟Big O的核心是衡量「成本随输入规模变化的增长趋势」，不是抠硬件层面的毫秒级差异。

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