公司一个已婚男同事，跟一个已婚女同事一起了，要不要告诉她老公呀?

刚看到个贴子，说公司里两个已婚同事搞在一起了，有人想匿名告诉女方老公。这事吧，说实话有点像“办公室里的狗血连续剧”。

我觉得这事的关键，不在于“要不要说”，而是你说了图什么？图正义？图解气？还是图热闹？说了，可能挽回婚姻，也可能你变成风暴中心；不说，心里不舒服，但最起码全身而退。网友们的回复我看了看，有支持实名爆料的，也有建议别多管闲事的。

从我的角度看，职场不是道德法庭，尤其当事人都不是你的亲密关系，贸然插手，风险大、收益小。职场已经够复杂了，别轻易让自己变成剧里的人。

总的来说还是：能避是福，别把别人的戏演成自己的事故。【备注:文末可领最新资料】

面试题：嵌套数组生成器

你说嵌套数组生成器？这个题目乍一听有点像“手搓yield生成器”的那种脑筋急转弯，其实细想一下，八成是考察你对递归和生成器这两个东西的理解是不是扎实。用 Python 写的话，不上递归都不好意思开口。

假设我们要实现一个生成器，它接受一个嵌套的数组，比如 [[1, 2], [3, [4, 5]], 6]，然后能一个一个地吐出 1, 2, 3, 4, 5, 6，不管这个嵌套有多深。

说实话，这题乍一看简单，其实坑点还不少。比如你怎么判断一个元素是可迭代的？你怎么避免把字符串当成可迭代类型给拆了？你递归的时候怎么接着用 yield 传回来？这些小细节不搞清楚，十有八九要掉坑。

我先给个比较正宗的实现：

from collections.abc import Iterable

defnested_generator(data):
for item in data:
if isinstance(item, Iterable) andnot isinstance(item, (str, bytes)):
yieldfrom nested_generator(item)
else:
yield item

讲真的，这段代码虽然短，但细节真不少：

1. 用 isinstance(item, Iterable) 来判断是不是可迭代的；
2. 但是字符串也属于 Iterable，所以得排除掉 str 和 bytes；
3. yield from 是关键，递归地生成子结果比手动一层层遍历高效太多。

有的兄弟可能会说，这不就是递归 flatten 嘛？对，但用生成器的方式处理更节省内存，因为不会一次性展开整个数组，而是按需一个个来。要知道，数据一旦大起来，整个 flatten 成一个 list 可就炸内存了。

而且这玩意儿在一些场景下特别好用，比如处理嵌套的 JSON 数据，或者解析 XML 树结构时做遍历。你不能预知嵌套有多深，但你又不能全展开，生成器就成了救命稻草。

当然，也不是说这种写法没有缺点。比如你如果想“反向”操作，或者需要知道每一层的嵌套结构，那就得做额外的处理。再比如你要处理的是不规则结构，还混着 dict，那就得加判断逻辑了。

我曾经在一个日志解析的项目里搞过类似的玩意儿，日志是一堆嵌套 JSON，每条记录动不动就嵌三四层，那时候没用 yield from，一层层 if-else 写得我头都大了。后来换了这个结构，代码立马清爽了，跑起来也稳。

所以说这个嵌套数组生成器表面看是个玩具题，其实是检验你“会不会递归+生成器”的典型。用得好能救命，用不好就变成一坨递归的屎山。

要不我再加点彩蛋？比如你想支持 dict 类型：

defnested_generator_v2(data):
if isinstance(data, dict):
        data = data.values()
for item in data:
if isinstance(item, (list, tuple, dict)) andnot isinstance(item, (str, bytes)):
yieldfrom nested_generator_v2(item)
else:
yield item

这样就能搞定形如 {'a': [1, 2], 'b': {'c': [3, 4]}} 的结构，输出还是 1, 2, 3, 4，牛不牛？👊

最后，给个忠告：别小看这种题，很多时候写代码不是在秀操作，而是在保证后续维护不头秃。写得清爽的递归，胜过万行嵌套的祖传代码。你说是不是？