@rodrick 补充一下对你的认可的感谢，刚刚那个回答提到配合一套文章，文章地址补上： https://react.iamkasong.com/ 不是广告，这篇文章虽然内容不是很多，但是对于 React 的心智模型讲解对我帮助很大，以供参考

@jishu541464750 不好意思哈，暂时都只考虑在杭州呢，谢谢邀请哈

@rodrick 源码陆陆续续看了好几遍，前面几遍都是半途而废因为太难啃，最近把之前零碎的知识点串起来了。看源码的方法主要依赖于 debug 调试和配合一套文章进行验证。然后其实我个人对于源码框架的观点是：先知道某个模块是为了什么功能，然后再去看具体实现。我自己是根据下面这个脉络来阅读源码的：
1. React 是怎么表示应用的？然后去找 Fiber 的相关心智模型了解一下
2. React 是怎么表示应用的更新的？
3. React 是怎么调度应用更新的？
4. React 是怎么对比更新的？这个是属于 diff 的流程
5. React 是怎么将 DOM 渲染到屏幕上的？

这几块内容我前几遍看的时候都是因为太抓细节，总想什么都明白所以导致太庞杂看不下去，后面慢慢先理清楚流程，比如先知道 React 其实就是在不停地去 workLoop 处理渲染流程，然后在细节深入中了解具体的实现比如：不同类型的 React Component 是怎么开启一次调度的？再会看见关于优先级模型就会去了解 Scheduler 、lane 模型。如此细节下来关注自己感兴趣的内容。但是现在我也只是对部分源码有个认知，能知道为什么会表现出一些特性。

还有包括说 webpack 源码，其实我没有全部阅读完源码，我只阅读了 tapable 和 webpack 的主干流程：就是用各种 plugin 去响应 hook ，然后了解一下整个 webpack 编译流程中会有哪些 hook 分别对应什么阶段，其实我认为这些表都没必要记，debug 或者做需求的时候我能够知道在哪个 hook 中去做插件实现就可以了。

我自己的博客里面写了一些关于我阅读源码学习源码的理解： https://www.alanderpro.com/blogs/React%E6%BA%90%E7%A0%81%E7%AC%94%E8%AE%B0%E2%80%94%E2%80%94Scheduler%E5%A6%82%E4%BD%95%E4%BB%8B%E5%85%A5React%E7%9A%84%E6%9B%B4%E6%96%B0/

ps：虽然我在我的文章中都在强调我不会过多去解释和贴源码，但是看到这里的人如果在自己学习过程中还是需要去自习阅读源码并知道实现的代码的，只有知道了具体细节才能帮助自己更好地抽象。

@jguo 这样吗，我这样写主要是感觉 React 、Redux 都是在使用函数式编程的思想指导代码开发，然后业务代码中实践挺多才写上去，也有点想引导面试官聊一聊函数式编程在具体编码中的应用和有点来着。

@66beta 大家似乎也都在关注薪资。这个薪资在杭州其实都不用双一流，本科毕业三年内面试发挥好一点其实这个区间还是很多的，越年轻的越多。杭州的大厂愿意给钱的太多了，后悔年中没上滴滴的车。

似乎都对简历其他内容不太关心，挂一会要是没有更多其他讨论我就把帖子沉了吧

@houshiduo 不好意思哈，还是意向在杭州


@yanzhiling2001 这模板从实习就开始用了三年多了，哈哈哈

@imchenlong 啊，那就是没有缘分了，如果简历打不开了就算了，佛系等机会吧哈哈哈

@eycode 具体不便透露，只能说涨幅我是对比了同学的涨幅，属于中上涨幅吧


@wszgrcy 在杭州当程序员在我看来就是不当人啊，我觉着对我来说，这两年能多赚点钱无所谓

至于大家似乎对期望薪资有问题，我觉得这个点确实是符合这个主题，因为期望薪资也是简历的一部分。我想声明的是：这个薪资范围和 hr 的薪资范围差不多？ hr 薪资范围写 20 ～ 30 一般也给不到这么高吧，所以薪资范围的下限对我来说是一个跳槽期望的最低涨幅，至于上限无非讨价还价。

期望薪资确实是简历的一部分，这个点我记录下来了，但是我更想知道简历其他地方可优化的空间在哪里。看了很多同学同事的简历对比找不准定位。

@leoknight 漫天要价，坐地还钱 哈哈

@juzisang 哈哈哈，忘记附上了

分母来了

@czfy 很有想法的一段话，赞

@lanten 太难沟通了，包括后面举的例子，这种业务真的存在吗，如果真的存在样式还不统一，那我确实没什么好说的，产品和研发肯定有一个有问题。
你也没理解我说的意思：vue 完全可以选择用 jsx 去写代码，而它采用了 template 。你还在揪着“可以写，写的难看”，vue 都不采用还争辩什么呢。根本不需要 jsx ，因为本身就是糟糕的形式。
对此我不会再进行回复了，你认为的是对的，我认为的也是对的。

@murmur haha

@lanten

“只有新手才会在 jsx 中添加大量业务代码。” 是反驳 @murmur 在 15 楼的观点。我就是在替 15 楼反驳你的观点，你说 react 不会有上千行代码，vue 也不会有，你说 vue 会有上千行代码，react 也会有

依赖库中存在大篇幅代码和业务代码中的上千行是两码事，你在日常开发中根本不需要阅读和维护库中的代码，而业务代码不同，篇幅越大越难以理解。React 本身就是个业务框架啊，写 React 就是一种业务啊，其中 reconcilation 的代码也就是普通业务，其理解难度本身也很大，代码行数上千行。所以你的“上千行的代码就是糟糕的代码”这个观点肯定是不敢苟同。

“你似乎不太理解插入元素的含义，插入的不是原生 dom ，而是 jsx 虚拟 dom ，我真的不太明白你是怎么理解到那上面的，这让我感觉你似乎不是很懂。” show me the code ，让我看看到底是什么场景，我确实没理解你说的 jsx 虚拟 dom 是什么场景，如果你说的是可以用 js 写 React.crateElement ，那用 babel 替换 React.createElement ，完全可以用 jsx 写 vue ，vue 没有用 jsx 而是用 template 的考量普通业务程序员有思考过吗？

“逐句对线你似乎怒气很大，就像炸了毛的刺猬，有点好笑。”我怒气并不大，只是实在是在技术上看见你说的一大堆文字里面没几句话是正确的，摘出来提醒后续人看的时候注意一下别带偏了。

反倒是我想问你个问题，你理解的 jsx 到底是什么？你理解的虚拟 dom 到底是什么？你知道为什么你只需要写 jsx 却可以最后生成了 dom 元素？如果理解了那你理解 vue 是怎么生成的 dom 元素？如果理解了这两个差异是不是用现有工具完全可以用 jsx 写 vue 代码？

不懂可以，在指出来问题的时候不要避重就轻，理性回复就可以了。

@lanten

“只有新手才会在 jsx 中添加大量业务代码。” 新手解决这个的问题不就是拆分函数吗？

“上千行的代码难道不是糟糕的代码吗？” React 、webpack 、vue 的源码中均存在大量上千行的代码，它们也都是糟糕的代码吗？

“vue 的 template 类 UI 描述方案饱受诟病的核心原因是在 js 代码中无法插入元素，只能手动创建 VNode ”，都不讨论什么业务场景下驱使开发者即使在使用了 Vue 或者 React 框架后仍需要在 js 中插入元素了，你说的 Vue 只能手动创建 VNode ，那同样的需求场景下 React 不也是只能手动创建 ReactElement 吗？

“以及没有 TS 类型提示，这将导致功能性、灵活性丢失。” 这句话居然没有人反驳也是很奇怪。

React 和 Vue 的优劣势明显的很。但是抓着说 React 写出来的 jsx 优美，我用了这几年 React 真不觉得，虽然 Vue2.x 中连最基本的 @click 事件传参都做不到统一，但是 Vue 的 template 就是 template ，js 就是 js ，这一点来对比，说 jsx 优美的话应该很多人都不服气吧。

楼上吹的理念、坚持听着就想笑，React 设计的初衷是什么我不得而知，但是给了开发者更多的对应用和代码控制权限的同时写出来的代码必不可能优雅到哪里去。

@akaxiaok339 感谢感谢

@zhibi boss 上搜了一圈感觉不是很多，可能主要我想在苍南一带吧