幸幸苦苦工作半年，就因为周末没接一个电话被白嫖厂打了 A2绩效，老子躺平了

刚刷到个贴子，说有个程序员因为周末没接电话，结果被白嫖厂直接打了 A2 绩效，气得选择躺平不干了。

从程序员的角度看，这事真挺离谱。写代码本来就已经强度很大，还得时刻 standby，这不是当人用，是当工具人用。网友里有人觉得“应该职业化，电话要接”，但我不太认同。毕竟程序员不是 7*24 小时的运维机器，公司要的是人，不是机器人。

我觉得关键在于制度问题：如果真有紧急电话，那应该有合理的值班轮换和补偿机制，而不是强行让大家无条件背锅。说白了，这种“电话不接=不敬业”的逻辑，本质就是转嫁成本。

程序员的价值在于解决问题和创造功能，而不是无限透支自己的生活。公司只会利用你可替代的部分，但你自己得守住底线，别把健康和尊严搭进去。【备注:文末可领最新资料】

面试题：生成斐波那契数列

昨天晚上快十二点，我还在调bug，结果脑子有点炸，就随手写了个斐波那契玩。其实这个东西吧，大家都知道，就是兔子繁殖那个故事，一个月大兔子生小兔子，两个月后又能继续生，数来数去就是那个经典的数列：1, 1, 2, 3, 5, 8, 13... 越看越像个玄学，但其实背后就是个挺朴素的算法。

我最开始写的时候，直接就是个递归，简单粗暴：

deffib(n):
if n <= 1:
return n
return fib(n-1) + fib(n-2)

print([fib(i) for i in range(10)])

这个写法吧，你要是生成个十来个数还行，打印出来 0 到 9 的斐波那契数列挺快的。但要是面试官让你算个 40、50，电脑风扇直接起飞，因为它不停在重复算相同的子问题。

在公司茶水间跟小李聊，他说直接用循环就行，省得递归那堆开销。于是我就改了：

deffib_loop(n):
    a, b = 0, 1
    seq = []
for _ in range(n):
        seq.append(a)
        a, b = b, a + b
return seq

print(fib_loop(10))

这种写法，你要多少项就来多少项，时间复杂度是 O(n)，空间复杂度也比较可控。一般业务里如果只是要个前100项之类的，完全没压力。

那天晚上又闲得无聊，我还写了个用生成器的，感觉挺优雅的：

deffib_gen(n):
    a, b = 0, 1
for _ in range(n):
yield a
        a, b = b, a + b

print(list(fib_gen(10)))

用 yield 的好处就是你不用一次性把整个序列放内存里，要多少拿多少，很适合流式处理。比如说我只想遍历前 100 万个斐波那契数，但其实只在意最后一个，那这种写法就比存数组强多了。

要是真的要算到特别大的数字，比如上百万项，那 Python 的 int 可以自动扩容没问题，但速度就慢了。这个时候大家一般会用矩阵快速幂法，把复杂度优化到 O(log n)。不过说实话，我自己实际场景里几乎没用过，大多数业务需求用不到那么极限的优化。

说到底，斐波那契数列就是个“最朴素的递推”，写法从递归到循环，再到生成器，最后到数学公式（黄金分割数那个），基本就是一个学习编程的必经之路。昨天写完我还笑了下，感觉就像从菜鸟到老鸟的一条小小的进化史。