其实 ctx 少了什么东西，第一想的不就该是有没有调用中间件么...

没有用 webpack 吗....定义 publicPath 就好了啊

然后源代码里用相对路径去引用对应资源

还行，zeit 牛逼

系统性学习 Java/Python/Go...
Python 和 Go 我都想不太出怎么像 Java 那样“系统性”学习😂

我觉得 StackOverflow 对回答的质量要求更高，而现在很多人早就忘了问答网站一开始出现的时候，对答案的质量是怎么精益求精的。在 StackOverflow 答题，觉得不透彻了解都根本不敢答，顶多在问题评论区发表下看法，给个链接什么的。

@yc8332 这个只能说不同前端水平确实不同，我这边这种请求中禁用按钮的逻辑都是写在组件里的，不可能出现这种情况，否则后台同学也会很难处理

利益相关，目前在鹅厂用 React，并且我所在的事业群大部分都在用 React。

认真回答一下这个问题，楼主提出 React 是否适合大数据量的、高频率的 DOM 变换场景，我觉得依然适合。并且 Vue 不见得就能解决这个问题。

大数据量、高频率的 DOM 变换的确是前端的难点，React 其实是用框架和语法去简化这种操作，提高可读性，这才是所谓前端框架最大的好处，用 Jquery 甚至原生 JS 实现行不行？当然行，但是你要耗费的时间和精力，以及后人维护的成本，都会变得很大。

那么为什么会出现这种点击一个 button 卡顿几秒钟的情况？先分析一下你们 React 代码中的生命周期钩子，有没有什么耗费时间的操作，有没有使用 shouldComponentUpdate 去判断不需要重新渲染的情况，点击一个 button 想必出发了 state 的更新，是小组件的 state 还是不小心触发了外层？这些都要去分析一下。

另外就算这些都优化到，也确实可能出现卡顿的情况，这是因为 React 目前还没完全支持异步渲染，也就是 React 16 强推的 Fiber 算法，Fiber 算法的强大在于 render 过程可以异步，可以允许中断 render 过程优先响应用户操作，目前 React 16 还未完全放开，但这对这种大数据量的计算渲染性能提升很有帮助。

不过说真的，只有 1000 个列表组件还优化不到这个地步。

@deadEgg 我面的企业微信是广州的团队，不过走的也比较晚

忘了说钱的问题，微软比我目前年薪多差不多 5w 吧，差距不是很大。

英文环境自己还是 OK 的，谈不上喜欢或者不喜欢，都能适应。

1000 人能有 500 人做到 T4 应该都过高了。
其他人？我觉得没升上去的有一半，出去做其他公司总监的有一半吧。

To C 赚的快，但是确实不稳定。
在 To C 还能赚钱的时候，自然是都在瞄准 To C 做。
To B 其实是很累很累的

Airpods 真没什么音质...但是确实方便
打电话、听电台都没什么问题

接近 2 年的稳定 vultr 今天跪了，猝不及防

真正的程序员，不会舍不得钱买 mac，贷款都要买

笑死了

首先恭喜楼主去了阿里，阿里的 Node 技术及应用是公认的成熟，这在鹅肠的前端看来是非常羡慕的。

对于二次元这个话题，能在 B 站一起成长本身就已经十分幸福，君不见多少瞄准钱的二次元产品从本质上就已经坏掉，但是由于大多数青少年的启蒙阀值实在太低，所以照样有市场，B 站只要不是彻底抛弃二次元的核心，就依然是国内二次元的代表，依然会起到引领的作用，不然正版番剧谁去买。

一定要为了真正喜欢的内容做互联网工作的话，必然遇到目标用户少，所以技术没有多少挑战性，工资也相对低的问题，这些牺牲不能无视吧。

也在经历这种开发，P0 P1 P 几这种定级本身就是很多精力的内耗和扯皮，我不想做我把它定 P4，几乎就是默认不做...因为 P1 的永远做不完，怎么说呢..可能还是因为赶

用的是什么库分析的？

python 还是 pycharm 吧...
除了 js 和 ts 用 vscode 好用，其他都可以 jetbrain