同样的接口返回不同的数据结构就得这么做，这样的设计不是很常见吗

说实话很多人喷过早焦虑

但是我现在 31 ，我发现没有在 20 多出头那会进行积累的人，到了 30 多基本没起色，也没有动力和能力去改变自己了

我还是比较庆幸几年前焦虑的工作，焦虑的提升自己过了

啥几把玩意总监？

没想到框架中包含了快 2000 张表，数百万的历史代码。

这你还能没想到？这不该立项的时候就得整清楚？最核心的要做的地方你都不知道大概怎么做，这项目就能定时间开始？

看完了我可以说项目失败这总监基本全锅

另外更不用说有可能是三方甚至多方参与的讨论了，每人复制一遍问题再写自己答案你会疯的

相反，大家按顺序编辑正文，可以把所有回复列在问题下面，一目了然

编辑邮件来进行 Q&A 回答是非常常见的邮件办公模式

考虑你说的情况，实际的邮件 loop 会是：

userB: 请看补充标注
userA: 请看补充问题
userB: 请看标注
userA: 请回答问题?
Q1: XXX
A1: YYY
Q2: ZZZ
A2: CCC
Q3: VVV

如果基于这种模式，大家只要找到这一个块就能迅速得到讨论过程和最终结论，而如果按你的想法，通过正文不断回复
那实际上邮件的 loop 会变成这样：

userB： 补充回答
Q1
A1
Q2
A2
Q3
A3

userA：补充问题？
Q1
A1
Q2
A2
Q3
userB: 回答
Q1
A1
Q2
A2
userA：问题？
Q1
Q2


整个邮件的可读性才会变得极差，容易误读，也难以追溯讨论过程。

type 的虚拟节点下的真实数据，也需要按父子关系把树构建出来，并且当前节点在树上到根节点也连带出来（向上时，如果节点数据不属于此 type ，也需要展示，此时加一个 readonly 标记）

==> 没太明白，如果节点 type 不属于这个 type 也要展示而不是裁剪，那岂不是 type 的树就和原始树一样吗？

B 既然依赖 A 的结果，那你定义 useFetchB 的时候给个入参就行了，这样所有用到 fetchB 的地方就必须传入 A 的结果

如果 A 的查询和每个页面内容无关，那直接把 A 写到 useFetchB 里面去

102

@kxxoling 有拜登因为感冒去隔离的新闻吗？没有搜到

太简单了，学拜登就行了

作为蓝星第一强国的总统，以他作为行为准则肯定没错

拜登会因为感冒去隔离，天天做核酸吗？

@ijrou 都要润的人了还需要考虑机翻吗？或者说做这一行还要考虑机翻吗？

Java 的 stream 不用也罢，根本起不到和 C#一样的从便利性、可读性上有飞跃提升的效果
根本原因是 Java 的类型设计就很差，没有 IEnumerable 这样的基础，让 stream 做不出管道式的效果，任何操作之后都得 collect 创建新对象

至于在这贬低 lambda 本身的就很搞笑了，没写过 lambda 总写过前端吧，能说出 lambda 鸡肋？