@3dwelcome 我好像有点思维定势了，节流第一反应就是定时器，那样确实是没有直接对比时间优雅。

你说的按钮钩子不清楚是不是要封装成按钮组件。
如果是指封装函数的话我觉得楼上那位提的 promise 的情况是要考虑的，一刀切定两秒感觉有点久。
如果是指封装成按钮组件，还是用定时器好一点，像延时两秒的场景，按钮上最好加一个逻辑显示数字过点点点倒计时和按钮的禁用 /loading 样式，两秒后或者 promise 结束后清除掉这个状态。用户体验上更好一些。

@wukongkong 哈哈，是的，就是有时候接口请求返回得很快，用户还是容易点好几下。最好是判断下传进来的函数的返回类型，如果是普通函数就直接按指定的 timeout 时间做节流。如果是 instance of Promise ，就等它的 pending 状态结束掉，然后和 timeout 时间做对比，按时间最长的那个等待时间来做节流，这里如果具体实现用 await Promise.all 来对业务函数的 promise 和 timeout 的 promise 做等待的话，需要对业务的 promise 再包一层 promise 保证业务 promise 不管是被 resolved 还是 rejected ，最后包的那层 promise 一定会被 resolved ，因为 promise.all 当一个 reject 就直接 reject 不等另外一个了。

@gouflv
我预期自己能带的团队里主力会是初中级开发。在这个前提下，很多公司的技术 Leader 还是要写业务代码的，在业务上有直接体现。除此之外，及时响应产线问题也很重要，因为初中级开发定位问题有时候可能没那么快，如果产线问题大部分都是你处理的，对领导来说你就是不可随意裁掉的人。其实很多时候，你的领导觉得某一块事情安排给你之后，他就不用担心了，你的价值（可能不算业务价值）就体现出来了。其他方面，就是基建、UI 库之类的，重点是尽量将其量化，要能有数据表示前后的提升之类的，不然在领导眼里可能就不会被重视，会有点像是技术人的自娱自乐。

具体到业务上的价值，感觉是管理好团队提高团队的业务产出，减少团队的产品 bug （组织团队的 code review ，不要流于形式），及时解决出现的 bug （并非要全部亲力亲为，但是也尽量要一起关注）。我曾呆过的一家公司，专题活动页这块的开发一直要占用一定的人力资源，但其实很多专题活动都是类似的东西，完全可以搞个简单的在线编辑器让业务自己开发的，不过那个公司前端团队地位太低了，我想要台服务器一直要不到，搞不了这块。

@yikyo 嗯嗯。

@imchenlong 谢谢。先不用。互联网一线公司全年都在招人，什么时候都不急。我想先看看其他机会，能在非互联网企业捡漏拿个 leader 岗位长呆是最好的。

@yikyo 好建议，我以为写的是以前的经历就不算减分了，但是陆续好多人提到这个了，感觉是得删掉。

@hly9469 在这里能碰到同校的，真难得。我是药学（食品药学方向），没你那个专业好。

@LiuJiang 一直在裁员，没有归属感

自创的，应该算专有名词

换服务器应该要备案的吧？备案主要就是备的服务器，因为你内容是放服务器上的

jar 的服务器部署真香，比 npm 的方便多了。

普及度这么高的吗，我们项目框架版本轻易不更改，还没到可以用 hook 的版本

给产品点个赞，很好用

文中前端是指浏览器客户端，不是 web 对吧

@hahaayaoyaoyao 好吧，右上角那个 navigation 跟背景混在一起，没看到。。